Epicor Kinetic loads purchase orders through the Data Management Tool, which reads CSV and Excel files, or through the POSvc REST endpoint, which reads JSON. Both want structured rows with the right columns. Neither one reads a PDF. PurchaseOrders reads the purchase order PDF, scan, or photo and returns the header fields and the full line-item table as Excel, CSV, or JSON, so the file you hand to DMT is typed by a machine instead of a person. Upload a real purchase order below.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
Epicor gives you serious bulk-load machinery. DMT ships with more than 60 prebuilt templates, applies the same validation the UI does, honors your BPMs, and writes a clear error log when a row fails. None of that helps with the step before it. DMT takes a spreadsheet, and the orders arrive as documents.
The Data Management Tool imports from .csv and .xlsx files. When the source is a customer PO emailed as a PDF or a scan of a mailed order, somebody has to read one window and type into another before DMT ever gets involved.
A purchase order does not load as a single row. Teams typically run PO Header, then PO Detail for the lines, then PO Release for the delivery schedule, in that order, or use the combined template. Keying one order by hand means keeping those sheets consistent with each other.
Epicor assigns PO numbers, line numbers, and release numbers itself, and DMT often will not respect values you supply for new auto-numbered records. If your source document skips a line number, you end up padding the file with placeholder rows and deleting them afterward.
Because DMT enforces the same business logic as the screen, a date in the wrong format, a quantity with a stray character, or a part number that does not match your part master all bounce. You find out from the error log after the run, not while you are typing.
A cutover from a legacy system, a quarter of accumulated customer POs, or a newly acquired division all arrive at once. The DMT side of that load takes minutes. The data-entry side takes weeks of somebody's time.
Posting to Erp.BO.POSvc needs a JSON body with real POHeader and PODetail values. If the integration is fed by a mailbox full of attachments, the API does not help until something has turned those documents into fields.
PurchaseOrders is the capture step in front of DMT or the REST API. It is not an Epicor connector and it does not run inside Kinetic. You give it a purchase order document. It gives back clean, field-level data that you map to the template columns Epicor already expects, then you load it with the tooling you use today.
A digital PDF from a customer ERP, a scan of a mailed order, or a phone photo of a paper PO. All go through the same extraction, with no per-supplier template to build first and nothing to configure per layout.
PO number, buyer and supplier, bill-to and ship-to, order date, promise date, payment terms, currency, and the line grid: part number, supplier part number, description, quantity, unit of measure, unit price, and line total, captured across page breaks.
Output is one row per line item with consistent headers, which is the shape the DMT sheets want. Map your columns once to PO Header and PO Detail, and every later batch drops into the same mapping.
Pull the same extraction as JSON through our API and feed whatever already talks to Kinetic, whether that is an Epicor Function, a custom service, or a script that posts to POSvc. Clean fields in, no document parsing on your side.
Upload a stack of orders at once rather than one at a time. That is what turns an initial load from a legacy purchasing system into a same-day job instead of a staffing problem.
Captured fields are shown on screen so you can correct an odd value before you export. Catching it here is a great deal cheaper than reading it out of a DMT error log after the run.
Two routes cover almost everyone. The first is the Data Management Tool: you build a CSV or Excel file, point DMT at the PO Header template, then PO Detail, then PO Release, and let it validate and load. DMT tells you which fields are required, estimates how long the import will take, and writes an error log naming the rows that failed. The second is the REST API, where Kinetic exposes its business objects as OData v4 services and integrations post POHeader and PODetail payloads to Erp.BO.POSvc. Either way the question is the same: where does the structured data come from? If the answer today is a person reading a PDF, this tool replaces that step.
Epicor already generates suggested purchase orders from demand, and people sometimes assume that covers inbound documents too. It does not. Purchase Order Suggestions come out of MRP and reorder logic inside your own data, so they answer the question of what you should buy. They say nothing about the purchase order a customer just emailed you. That document still has to be read and keyed, which is the gap this page is about.
To be plain about the boundary: PurchaseOrders extracts purchase order data from documents into a structured file. It is not an Epicor connector, it does not run DMT for you, it does not call POSvc on your behalf, it does not write to Epicor tables, and it does not create, approve, receive, or match purchase orders. Those all stay in Kinetic. We remove the typing that happens before the load, and nothing else.
Epicor shops running a cutover from a legacy purchasing system use it to build the migration file. Manufacturers and distributors whose customers send POs as PDFs use it so those orders reach Kinetic the same day they arrive. Integration teams wiring an orders mailbox to an Epicor Function use the purchase order API so the middleware gets JSON rather than an attachment. The purchase order PDF to Excel converter is the quickest way to see the output shape, and row-level accuracy on long orders is covered in purchase order line item extraction. A backlog clears through bulk purchase order upload, the general load path is in how to import purchase orders to an ERP, and teams on other systems can compare purchase order to SAP, Oracle purchase order import, and purchase order to Business Central.
All three end at the same place, an order sitting in Epicor Kinetic. They differ in what happens before the load.
| What matters | Manual keying into DMT | Template OCR tools | PurchaseOrders AI |
|---|---|---|---|
| Setup per supplier layout | None, but slow forever | Build a template each | None, any layout |
| Mixed PDF, scan, photo | Handled by a person | Often breaks | Handled automatically |
| Line-item capture | Error-prone by hand | Varies by template | Full line-item tables |
| Time per purchase order | 5 to 10 minutes | 1 to 3 minutes | Under 10 seconds |
| Output shape | Typed straight into sheets | Needs cleanup | Row per line, ready to map |
| Rejected rows to chase | Typos drive most of them | Some | Fewer, data is reviewed first |
| Cost per PO at volume | High manual labor | Per-page plus setup | Under $2 |
PurchaseOrders.io extracts purchase order data into Excel, CSV, JSON, or an API response that you map to Epicor's template columns. It is not an Epicor connector, does not run the Data Management Tool, does not call POSvc for you, does not write to Epicor tables, and does not create, approve, receive, or match purchase orders. Epicor and Epicor Kinetic are trademarks of Epicor Software Corporation; this page is not affiliated with or endorsed by Epicor. Manual cost reflects published estimates of $15 to $40 to fully process a purchase order by hand.
No templates to build, no changes inside Kinetic.
Drag in PDFs, scans, or photos, one at a time or a whole batch pulled from the orders mailbox.
Tip: Mixed suppliers and file types in the same upload are fine.
The AI reads each order and returns the header fields and the complete line-item table in seconds.
Tip: Check the captured values on screen before you export, not after DMT writes an error log.
Download Excel or CSV, map the columns to your PO Header and PO Detail templates, and run DMT, or pull JSON via the API and post it from your own integration.
Most teams use the Data Management Tool. You build a CSV or Excel file, load the PO Header template first, then PO Detail for the lines, then PO Release for the delivery schedule, or use the combined template that handles all three. DMT validates each row against the same business logic the screen uses and logs the ones that fail.
DMT is the Data Management Tool, Epicor's bulk load utility. It imports from .csv and .xlsx files, supports create, update, and delete, ships with more than 60 prebuilt templates, and can also be driven from the command line for scheduled loads. Because it runs through the same business objects as the UI, your customizations and BPMs still apply.
Yes, and updates need far fewer columns than creates. A release date change, for example, can be as small as Company, PONum, POLine, PORelNum, and PromiseDt. That is worth knowing before you rebuild a full-width spreadsheet for what is really a narrow edit.
Because Epicor auto-assigns them. PO numbers, line numbers, and release numbers are generated by the system, and DMT frequently will not honor values you supply on new auto-numbered records. Plan on Epicor owning the numbering and keep your own reference in a user-defined field if you need to trace back to the source document.
Line numbers are assigned sequentially as rows load, so a gap in your source will not survive the import on its own. The usual workaround is to pad the file with placeholder rows against a dummy part number so the real lines land on the numbers you want, then delete the placeholders afterward.
Yes. Kinetic exposes its business objects as OData v4 REST services, and integrations commonly post to Erp.BO.POSvc with a JSON payload containing POHeader and PODetail. The API still needs real field values, so if your orders arrive as PDFs you need extraction first. Our API returns that JSON.
No, and we would rather say so plainly. It reads purchase order documents and returns structured data. It does not install in Kinetic, does not run DMT, does not call POSvc, does not write to Epicor tables, and does not create, approve, receive, or match orders. You keep using Epicor's own load tooling; we just remove the typing in front of it.
No. Purchase Order Suggestions is an Epicor feature that proposes orders from MRP and reorder logic using demand already inside your system. It answers what you should buy. This page is about inbound purchase order documents that arrive from customers or that you are migrating in, which Epicor cannot see until the data is keyed or loaded.
Usually the data, not the tool. DMT enforces the same validation as the UI, so dates in the wrong format, quantities with stray characters, part numbers that do not match the part master, and supplier IDs that do not exist all reject. Reviewing extracted fields before export catches most of the typing-driven failures.
Yes. The AI handles scans and phone photos, not only digital PDFs, and returns the same structured fields. That matters for Epicor shops because manufacturing and distribution customers still send a meaningful share of orders as scans, which template-based OCR tools tend to miss or mangle.
The same capture step for SAP.
PO data shaped for Business Central.
The general ERP load path.
Extract PO data to JSON via REST API.
How the line-item table is captured.
Clear a migration backlog in batches.
