Dynamics 365 Finance and Operations loads purchase orders through the Data Management Framework, using the Purchase order headers V2 and Purchase order lines V2 entities, or through OData against the same entities. Both want structured rows. Neither 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 your data project picks up was 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...
The Data Management Framework is genuinely good. It stages data, validates it against the entity, sequences header before lines, and hands you an error file naming the exact row that failed. What it does not do is read the document the order arrived on, and that is where almost all of the labor sits.
A data project sources from CSV, Excel, XML, or a package. When the order is a customer PDF sitting in the purchasing mailbox or a scan of a mailed document, a person reads one window and types into another before any data project runs.
A purchase order does not load as one row. The header goes to Purchase order headers V2 and every line to Purchase order lines V2, and the header has to import first or the lines fail validation because the order they reference does not exist yet.
If you supply PurchaseOrderNumber in the file, the purchase order number sequence has to be set to Manual on the Number sequences page before the load, then set back afterward. Skip that and D365 either overrides your numbers or rejects the rows.
PurchPurchaseOrderHeaderV2Entity carries a range on purchase type of PURCH, so it handles regular purchase orders and not the other purchase types. Teams discover this when a subset of migrated documents quietly never appears.
D365 keeps inventory transactions, number sequences, and version records in step with the purchase order tables. Writing straight into PurchTable and PurchLine leaves orders the application will not process correctly, so every load has to go through a supported entity.
A cutover from AX 2012, a newly acquired division, or a quarter of accumulated emailed customer POs all land together. The DMF side of that load runs in minutes. The data-entry side in front of it takes weeks of somebody's time.
PurchaseOrders is the capture step in front of the Data Management Framework. It is not a Dynamics 365 connector and it does not run inside D365. You give it a purchase order document. It gives you back clean, field-level data that you map to the V2 entity columns your data project already uses, then you import it with the tooling you have 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, vendor account, buyer, ship-to and bill-to, order date, requested delivery date, payment terms, currency, and the line grid: item number, vendor item, description, quantity, unit, unit price, and net amount, captured across page breaks.
Output is one row per line item with consistent headers, which is exactly the shape a two-entity data project wants. Map your columns once to the V2 entities, and every later batch drops into the same mapping.
Pull the same extraction as JSON through our API and feed whatever already talks to D365, whether that is a Power Automate flow, a Logic App, an Azure Function posting to OData, or a script that builds the DMF package itself.
Upload a stack of orders at once rather than one at a time. That is what turns an AX 2012 cutover or a quarter of emailed POs 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. Fixing a quantity here costs seconds; fixing it after a posted product receipt costs a great deal more.
Every supported route ends at a data entity. The common one is a Data Management Framework data project with two entities sequenced header first: Purchase order headers V2 (PurchPurchaseOrderHeaderV2Entity) and Purchase order lines V2 (PurchPurchaseOrderLineV2Entity). If you would rather send one file, Purchase orders composite V3 bundles both. Integrations that push order by order usually post to the same entities over OData instead. Either way D365 validates the rows and writes them to PurchTable and PurchLine, whose structure, join keys, and status enums are laid out in PurchTable and PurchLine. The question is where the CSV comes from. If the answer today is a person reading a PDF, this tool replaces that step.
To be plain about the boundary: PurchaseOrders extracts purchase order data from documents into a structured file. It is not a Dynamics 365 connector, it does not install in D365, it does not run your data project or call OData for you, it does not write to PurchTable, and it does not create, approve, confirm, receive, or match purchase orders. Those all stay in D365. We remove the typing that happens before the load, and nothing else.
Teams migrating from AX 2012 use it to build the header and line files for the cutover load. Distributors whose customers send POs as PDFs use it so those orders reach D365 the same day they arrive. Teams wiring the purchasing mailbox to a Power Automate flow use the purchase order API so the integration receives JSON rather than an attachment. The purchase order PDF to Excel converter is the quickest way to see the output shape, row-level accuracy on long orders is covered in purchase order line item extraction, and a backlog clears through bulk purchase order upload. The general load path across systems is in how to import purchase orders to an ERP. Shops on the smaller Microsoft ERPs can compare purchase order to Business Central and purchase order to Dynamics GP.
All three end at the same place, an order sitting in Dynamics 365 procurement. They differ in what happens before the load.
| What matters | Manual keying into D365 | 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 D365 | Needs cleanup | Row per line, ready to map |
| Staged rows to fix afterward | 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 the Purchase order headers V2 and Purchase order lines V2 entities. It is not a Dynamics 365 connector, does not install in D365, does not run your data project or post to OData for you, does not write to PurchTable, and does not create, approve, confirm, receive, or match purchase orders. Microsoft, Dynamics 365, and Dynamics AX are trademarks of Microsoft Corporation; this page is not affiliated with or endorsed by Microsoft. Manual cost reflects published estimates of $15 to $40 to fully process a purchase order by hand.
No templates to build, no changes inside D365.
Drag in PDFs, scans, or photos, one at a time or a whole batch pulled from the purchasing 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 DMF drops the rows into the error file.
Download Excel or CSV, map the columns to your Purchase order headers V2 and Purchase order lines V2 source, sequence the header entity first, and run the data project, or pull JSON via the API and post to OData from your own code.
Through data entities. Build a Data Management Framework data project with Purchase order headers V2 and Purchase order lines V2, sequence the header entity ahead of the lines, map your CSV columns, then import. Purchase orders composite V3 does the same job in a single file. Integrations that send one order at a time usually post to the same entities over OData instead.
No. A data project sources from CSV, Excel, XML, or a data package, not from documents. A PDF or scanned purchase order has to become rows first. That conversion is what PurchaseOrders does: it reads the document and returns the header fields and line items as a CSV or Excel file your data project can pick up.
Purchase order headers V2 (PurchPurchaseOrderHeaderV2Entity) holds the header, with fields including PurchaseOrderNumber, OrderVendorAccountNumber, InvoiceVendorAccountNumber, RequestedDeliveryDate, PurchaseOrderStatus, and DocumentApprovalStatus. Purchase order lines V2 (PurchPurchaseOrderLineV2Entity) holds the lines. Purchase orders composite V3 wraps both so one file loads a whole order.
Usually sequencing. The lines entity references a purchase order that has to exist already, so if the header entity is not sequenced ahead of the lines in the data project, every line row fails. The other common cause is supplying your own PurchaseOrderNumber without first setting the purchase order number sequence to Manual.
PurchTable holds the header and PurchLine holds the lines, joined on PurchId. Unlike some ERPs, D365 keeps a single PurchTable through the whole lifecycle rather than moving closed orders elsewhere, and tracks progress through the PurchStatus and DocumentState enums instead. Posted product receipts go to VendPackingSlipJour and VendPackingSlipTrans, posted invoices to VendInvoiceJour and VendInvoiceTrans.
They answer different questions. PurchStatus describes where the order is in the receiving and invoicing lifecycle: None, Backorder (shown as Open order), Received, Invoiced, or Canceled. DocumentState describes where it is in approval when change management is on: Draft, In review, Rejected, Approved, or Finalized. An order can be Approved and still sit at Backorder.
No, and we would rather say so plainly. It reads purchase order documents and returns structured data. It does not install in D365, does not run your data project, does not post to OData, does not write to PurchTable, and does not create, approve, confirm, receive, or match orders. You keep using the Data Management Framework; we just remove the typing in front of it.
Yes. The AI handles scans and phone photos, not only digital PDFs, and returns the same structured fields. That matters here because a good share of customer and supplier orders still arrive as scans or faxes, which template-based OCR tools tend to miss or mangle.
Yes. Extraction produces a plain CSV of header and line data, so the same file feeds the migration load and, afterward, the day-to-day intake of customer POs that arrive as PDFs. The document-reading step does not change when the target system does, which is also why the output works for Business Central or Dynamics GP shops.
Pricing is per document with volume tiers, and at volume the cost works out under $2 per purchase order. You can try it on a real order before paying anything. Compare that to published estimates of $15 to $40 to process a purchase order fully by hand, most of which is the keying this removes.
The same capture step for Business Central.
The same capture step for Dynamics GP.
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.
