A purchase order is the buyer's side of a transaction — it says what was ordered, from whom, where it should ship, and on what terms. Docyield reads a PO from a PDF or an image and returns it as structured data: the PO number, the buyer and supplier, the delivery address, the order and delivery dates, payment terms, currency, every ordered line item, and the subtotal, tax, and total. The default export here is Excel, but JSON, CSV, and XML come from the same result.
Purchase orders are the backbone of three-way matching, and that is where structured extraction pays off most. Once a PO's line items sit in named fields, you can line them up against the supplier's invoice and the goods-received note to confirm that what was ordered, what arrived, and what was billed all agree. Docyield reads the document in context, so the supplier is never mistaken for the buyer and a quantity is always tied to the right item.
What a purchase order parser extracts
The parser converts a PO into the fields a procurement or finance system expects. That starts with the order's identity — the PO number that everything downstream references — and the two parties: the buyer placing the order and the supplier fulfilling it. It captures where the goods should go via the delivery address, when they were ordered and are expected, and the payment terms agreed, such as Net 30.
The detail lives in the line items. Each ordered row is returned with its description, the quantity, the unit price, and the line amount, so the full order is reproduced rather than just its value. The financial footer — subtotal, tax, and grand total — is captured separately, giving you both the line-level breakdown and the headline figures a system needs to commit the spend.
Three-way matching and PO reconciliation
Three-way matching is the control that stops a business paying for things it did not order or did not receive. It compares the purchase order, the goods-received note, and the supplier invoice, and it only works if all three can be read as structured data. Extracting the PO's line items and totals into named fields is what makes the PO side of that comparison automatable rather than a manual line-by-line check.
With the PO in structured form, a matching engine can confirm that the invoiced quantities and prices fall within tolerance of what was ordered, flag a line that does not appear on the order, and catch an invoice that exceeds the committed total. The PO number ties the whole chain together, which is why capturing it cleanly is the first step in any reconciliation workflow.
Who uses purchase order parsing
- Procurement teams logging orders and tracking commitments against budget.
- Accounts payable teams matching supplier invoices to the originating PO.
- Suppliers turning inbound customer POs into sales orders without re-keying.
- Finance teams capturing committed spend and expected delivery dates for forecasting.
- Operations and warehouse staff reconciling deliveries against what was ordered.
- Developers adding PO intake to procurement, ERP, or AP-automation software.
Why structured extraction beats manual entry
Typing a purchase order into a system is repetitive and error-prone, and the errors are costly: a mis-keyed quantity or price breaks the very match the PO exists to support. Reading the data straight from the document removes that transcription step and the mistakes that come with it, while turning a slow task into a few seconds of processing.
The consistency of a fixed schema is what lets this scale. Suppliers send POs in countless layouts, and a template-based reader breaks the moment one of them moves a column. Because Docyield returns the same fields regardless of layout, a downstream system can rely on the field names — buyer, supplier, line items, total — instead of parsing each vendor's format afresh.
Accuracy, validation, and review
No parser is right every time, and pretending otherwise would be a disservice in a financial control like PO matching. Docyield reads clean orders reliably, and where a field is genuinely missing — a PO without a stated delivery date, for example — it leaves the field empty rather than inventing one. A blank that triggers a check is far safer than a confident wrong number flowing into a match.
A built-in arithmetic check helps you trust the result: the line amounts should sum to the subtotal, and the subtotal plus tax should equal the total. When those reconcile, the line items are almost certainly complete; when they do not, that points you to the row to review. Faint scans, multi-page line-item tables, and unusual layouts are the cases most worth a quick look against the original.
Turning inbound POs into sales orders
Purchase orders are not only received by procurement — they arrive constantly on the supplier side too, as customers place orders that have to be turned into sales orders and fulfilled. For a supplier, re-keying every inbound PO into the order system is a daily chore, and a mistake there ships the wrong quantity or the wrong item to a customer.
Extracting the PO into structured fields lets a supplier create the matching sales order automatically, with the buyer, delivery address, requested date, and every line item already populated. Because the same schema comes back regardless of which customer sent the order or how they formatted it, the supplier can accept POs from a diverse customer base without maintaining a separate template for each one.
Output formats, API, and batch
Excel is the default export because procurement and AP teams live in spreadsheets — the header fields form a summary and the line items become rows you can sort, filter, and match. The same result is also available as CSV, JSON, or XML, so you can push the order into an ERP, a custom application, or an older system without re-uploading.
The free tool processes one PO at a time, which suits occasional orders. For steady procurement flow, the Docyield API and batch dashboard run the same extraction at scale with webhooks and your own validation rules — so you can require, say, a PO number and a non-empty line-item list before a record is accepted. The schema is identical between the free page and the API.
What the purchase order parser extracts
Each purchase order is returned against a fixed schema. Fields not present on the document come back empty rather than guessed.
- PO number
- The purchase order number or identifier that downstream documents reference.
- Buyer
- The company placing the order — the 'bill to' party.
- Supplier
- The company the order is sent to — the supplier or vendor.
- Delivery address
- Where the goods should be delivered — the 'ship to' address.
- Order date
- The date the purchase order was issued.
- Delivery date
- The requested or expected delivery date.
- Payment terms
- The agreed payment terms, such as Net 30.
- Currency
- The ISO currency code or symbol used.
- Line items
- Each ordered row, with description, quantity, unit price, and line amount.
- Subtotal
- The sum of all line items before tax.
- Tax
- The total tax amount on the order.
- Total
- The grand total of the order.
How to convert a purchase order to Excel, CSV, or JSON
- 1Upload the purchase order — drop a PDF, PNG, JPG, or WEBP onto the box above, or click to choose a file.
- 2Wait a few seconds while Docyield reads the order and extracts the parties, line items, and totals.
- 3Check that the line amounts sum to the subtotal and that subtotal plus tax equals the total.
- 4Choose your output tab — Excel, CSV, JSON, or XML.
- 5Download the file or copy the data into your procurement, ERP, or accounts payable system.
Frequently asked questions
Processing documents at scale?
Batch upload, an extraction API, and webhooks for 100+ documents a month.