SHARED

Purchase Order OCR and AI PO Parser

Convert purchase order PDFs and images into structured header and line-item data. Capture supplier, delivery, quantity, price, currency and Incoterm evidence for invoice and goods-receipt matching.

Purchase orders establish what was authorized: supplier, product, quantity, price, currency and delivery terms. GainingDocx captures header and line-level evidence so invoices are never approved from a total-only comparison.

The parsed PO becomes the commercial baseline for matching against transport or receipt evidence and the supplier or freight invoice. Missing evidence stays incomplete; exact contradictions are blocked instead of averaged away.

Parse a document free See pricing

No sign-up for your first document · 15–30 seconds per page

Short answer

Updated August 4, 2026

What a purchase order parser extracts

Header and line-level data: PO number and date, buyer and supplier, delivery and payment terms, currency, requested dates, and per line the item, description, quantity, unit of measure, unit price, line amount and delivery date. The result is the baseline that invoices and goods receipts are matched against in a three-way check.

Line items with price and quantity per row
Delivery terms, dates and ship-to captured
Arithmetic recomputed against printed totals
The reference point for three-way matching

Purchase Order Fields and Lines Extracted

PO number, issue date, buyer and supplier addresses
Ship-to, bill-to, requested delivery date and transport terms
Product code, description, quantity, UOM, unit price and line amount
Currency, subtotal, discount, tax, freight and total
Incoterm, payment terms and referenced contracts

PO Validation and Three-Way Matching Checks

Computed in code — the AI never does the math.

Line quantity × unit price versus printed line amount
Line sums and charges versus printed PO total
Exact PO-reference matching across invoices and transport documents
Supplier, currency, quantity and line-level tolerance checks

How to Extract Purchase Order Data

01
Upload or photograph the document — pages are compressed on your device.
02
Review the extracted fields; deterministic checks flag anything suspicious.
03
Export to Excel, CSV or JSON, or generate the counterpart document.

The purchase order is the baseline everything is judged against

In a three-way match, the purchase order is the authority: it records what was agreed, at what price, in what quantity, on what terms. The invoice asserts what is owed and the goods receipt records what arrived. Where the three disagree, the purchase order is what the disagreement is measured from.

That makes PO extraction quality disproportionately important. An invoice line extracted imperfectly produces one wrong comparison. A PO line extracted imperfectly produces a wrong baseline against which every subsequent invoice and receipt is judged.

Field inventory

Purchase order extraction

Group	Fields
Order	PO number, PO date, revision number, buyer's internal reference, contract or agreement reference
Parties	Buyer or ordering entity, supplier or vendor, ship-to address, bill-to address, requester and approver where named
Terms	Currency, payment terms, Incoterm and named place, delivery terms, shipping method, freight payment responsibility
Dates	Order date, requested delivery date, ship-by or window dates, expiry or validity
Line items	Line number, item code, description, quantity, unit of measure, unit price, line amount, per-line delivery date, and any tax or discount
Totals	Subtotal, tax, freight, discounts, order total
Instructions	Packing, marking, documentation and quality requirements stated on the order

Checks applied

Line amount recomputed as quantity × unit price and compared with the printed amount
Line amounts summed against the printed subtotal, and subtotal plus charges against the order total
Currency checked for consistency across lines and totals
Delivery dates checked for plausible ordering against the order date
Duplicate line numbers and repeated item codes flagged
Incoterm validated against the published rule set
Revision indicators captured, so an amended PO is not silently treated as the original

Revisions are where three-way matching quietly breaks

A revised purchase order that changes a quantity or a price, matched against an invoice raised on the original, produces a variance that is nobody's error. Capturing the revision number and date is what lets the match run against the version that was actually in force when the goods shipped.

Three-way matching in practice

The classic three-way match compares the purchase order, the supplier invoice and the goods receipt. It answers three questions: was this ordered, was it received, and is the price what we agreed. Any of those failing should stop payment.

In international trade there is a fourth question that the classic model misses: does the transport evidence support it. A shipment can match perfectly on paper while the Bill of Lading shows a different quantity or a different consignee, and that is precisely the situation where a payment goes out against goods that never arrived as described.

What each document contributes

Document	Answers	Typical variance found
Purchase order	What was agreed	The baseline — variances are measured against it
Commercial invoice	What is being charged	Price variance, quantity billed above received, unauthorised charges
Goods receipt	What arrived	Short delivery, damaged or rejected quantity, wrong item
Packing list	What was declared as packed	Discrepancy between packed and invoiced quantity
Bill of Lading or AWB	What the carrier received	Weight or package differences, consignee mismatch

Tolerances and what to do with variances

Not every variance is a problem. Most organisations operate tolerances — a small percentage on price, a small quantity band on delivery — because chasing a rounding difference costs more than it recovers. What matters is that the tolerance is a deliberate policy rather than an accident of who reviewed the document.

Price variance above tolerance: hold payment and confirm against the contract or a documented price change
Quantity invoiced above quantity received: pay against the receipt, not the invoice
Quantity received above ordered: confirm whether over-delivery was authorised before accepting
Item on the invoice that is not on the PO: treat as unauthorised until confirmed
Currency or terms differing from the PO: escalate rather than absorb, since it changes the commercial deal
Freight or handling charges not provided for on the PO: check the Incoterm before paying
A revised PO in circulation: confirm which revision governed the shipment before judging any variance

Try it on your own document — free, no sign-up

Start parsing

Purchase Order OCR FAQ

What teams ask most often before putting purchase order parser output into a customs filing, a payment run or a downstream system.

What data is extracted from a purchase order?

PO number, date and revision, buyer and supplier, ship-to and bill-to, currency, payment terms, Incoterm and named place, requested delivery dates, and per line the item code, description, quantity, unit of measure, unit price, amount and any line-level delivery date — plus subtotals, charges and the order total.

What is three-way matching?

Comparing the purchase order, the supplier invoice and the goods receipt before approving payment, to confirm that what is being charged was ordered, was received, and is priced as agreed. Any of the three failing should stop payment. In international trade it is worth extending to a fourth check against the transport document, which records what the carrier actually received.

Are line items extracted individually?

Yes, as structured rows with their own quantity, price and amount. This matters because matching happens per line: an invoice that totals correctly can still bill a wrong quantity on one line and a compensating amount on another, and only a line-level comparison finds that.

How are purchase order revisions handled?

The revision number and date are captured where the document states them, so an amended PO is not silently treated as the original. This is important because an invoice raised against revision 2 and matched against revision 1 produces a variance that is nobody's error, and it is a common source of unnecessary payment holds.

Can it match a purchase order to an invoice automatically?

Yes. Grouping the PO, invoice and goods receipt as one record runs the comparison at header and line level, reporting price variances, quantity variances, unmatched lines and differences in currency or terms. Findings are prioritised by what actually blocks payment rather than listed in document order.

What if the invoice quantity is higher than what was received?

That is the classic over-billing case and the reason goods receipts exist in the process. The correct treatment is to pay against the receipt, not the invoice, and to raise the difference with the supplier. Extraction surfaces the variance with both figures and their sources so the conversation starts from evidence rather than from an assertion.

Does it handle blanket or open purchase orders?

It extracts what the document states, including validity periods and any call-off structure that is printed. Blanket orders drawn down over time need the release or call-off reference to match correctly, so where that reference is present it is captured. Where it is not, the ambiguity is surfaced rather than resolved by assumption.

Are tolerances applied automatically?

Variances are reported with their size and direction so a tolerance policy can be applied consistently. The tool's job is to make the variance visible and quantified; deciding what magnitude is acceptable is a commercial policy that belongs with the organisation rather than in the extraction.

What about purchase orders that arrive as email or spreadsheets?

All of these are normal inputs. Native spreadsheets extract more cleanly than scans because their structure survives, and email intake accepts an order sent as a message body rather than an attachment. Photographs and faxed copies are handled, with genuinely ambiguous rows flagged rather than guessed.

Does the parser check the Incoterm on a purchase order?

It validates the rule against the published set and flags a rule stated without a named place or edition. It also flags a maritime-only rule used where the shipment is containerised. Incoterm mismatches between the PO and the invoice are separately reported when the documents are matched, since they change who bears which cost.

Can I export purchase order data to my ERP?

Yes. Reviewed data exports to Excel, CSV or structured JSON with the line array preserved, and connector payloads are available for pushing reviewed records into a downstream system rather than re-keying them.

Does matching work when the supplier uses different item codes?

Matching compares on several signals rather than a single key — item code, description, quantity and price — so a supplier using its own part numbers can still be matched against your item lines. Where the correspondence is genuinely ambiguous, unmatched lines are reported for a human to resolve rather than paired on a weak similarity.

Does matching stop when the PO number disagrees?

Yes. A contradictory PO reference is blocking evidence. The shipment cannot be marked matched until it is corrected or reviewed.

Can descriptions match when product codes are missing?

Yes, but description-only matches are conservative and routed to review when the evidence is not strong enough for automatic approval.