Purchase order extraction

A purchase order is the document a buyer issues to a supplier to formally commit to a purchase: quantities, prices, delivery terms, and a PO number that becomes the thread running through everything that follows. Procurement teams create them, suppliers acknowledge them, and finance later matches them against invoices and goods receipts before releasing payment. When extraction is automated, that matching happens in seconds rather than through someone manually keying data from a PDF into an ERP. Done well, it also catches mismatches (wrong price, wrong quantity) before they become disputed invoices.

Fields to extract

Why this document is hard to process

Purchase orders look simple until you see enough of them. Every buyer designs its own template, and large enterprises run several templates at once, one per business unit or ERP instance. Line-item tables vary wildly: some list unit price and total, some only total, some bury tax and freight in footnotes rather than the table itself. Multi-page orders split tables across page breaks, and the header information (PO number, buyer details) often doesn't repeat on later pages, so a naive page-by-page parser loses context.

Scanned and faxed POs still show up in industries with long-tail supplier relationships, and these bring skew, low resolution, and stamps overlapping printed text. Amendments and revisions add another layer: a "PO-2024-08841 Rev 2" needs to be linked back to the original, not treated as a new order. Currency and unit conventions shift by region (comma versus period as decimal separator), and free-text fields like "special instructions" sometimes contain the only mention of a critical delivery constraint.

Fraud is a smaller but real concern: altered totals or fabricated approver names on POs used to justify payments. None of this is exotic on its own, but the combination of template diversity, table irregularity, and multi-page structure is exactly where rigid, rule-based extraction tools break down.

How Sygnet processes it

Sygnet starts by classifying the document as a purchase order and identifying which template family it belongs to, without needing a pre-built template for every buyer. It infers the schema from the document's own structure (document layout analysis) rather than forcing every PO into one fixed layout, which matters given how much buyer-to-buyer variation exists.

Each extracted field carries a confidence score and field-level provenance: a bounding box tying the value back to its exact location on the page, so a reviewer can check "order total: 18,940.00 EUR" against the source in one glance rather than re-reading the whole document. Validation rules run automatically: arithmetic checks on line totals, date logic on delivery windows, registry lookups for tax IDs. Where Sygnet has access to related documents (contracts, prior POs from the same supplier), it runs cross-document validation to catch price or term drift.

Output arrives as clean structured output (JSON) ready for the ERP, with a webhook firing once processing completes. Human review is routed only to fields below a confidence threshold, not to entire documents, which keeps review workload proportional to actual risk rather than document volume.

Validation rules worth applying

• Verify line total equals quantity multiplied by unit price, within rounding tolerance.
• Confirm order total equals the sum of line totals plus stated tax and freight.
• Check delivery date falls after issue date and within a plausible lead-time range.
• Validate supplier tax ID format and cross-check against a business registry.
• Compare unit prices against the last agreed price list for that supplier.
• Flag any PO number that duplicates an existing, already-fulfilled order.
• Confirm currency matches the contract or default currency for that buyer-supplier pair.
• Check that the approver name appears on the current authorized signatory list.

FAQ

Can Sygnet handle purchase orders that arrive as scanned faxes?

Yes. Sygnet is built on models that read documents visually rather than relying only on embedded text layers, which matters for scans and faxes. See OCR vs VLM for why this distinction affects accuracy on degraded documents. Confidence scoring flags illegible fields for review rather than guessing.

How does Sygnet match a purchase order to its corresponding invoice?

It uses cross-document validation, comparing PO number, line items, quantities, and totals against the invoice fields. See invoice data extraction for the matching fields on that side. Mismatches (wrong quantity, price drift) get flagged before payment rather than after.

Is it better to build this in-house or buy a platform?

That depends on volume, template diversity, and how much engineering time you can dedicate to maintaining extraction logic as templates change. Our build vs buy IDP page walks through the tradeoffs in more depth, and the ROI calculator can help estimate payback time for your volume.