Skip to content

Extracting invoices and purchase orders

Line items, tax lines, currencies and PO matching — the highest-volume extraction problem there is, and the one with the most edge cases per field.

An invoice looks like a solved problem because everybody has seen one. It is a table of goods, a total, and a name at the top. That impression survives about four hundred documents. Then a supplier sends an invoice priced in dollars with the tax stated in euros, because the law requires it; a reissued copy arrives with a new number and the same economic content; a freight charge shows up as a line item and quietly enters inventory cost; and a purchase order arrives as revision 3 before revision 2 does.

None of that is a model problem. It is the document being genuinely harder than it looks, and almost all of it is checkable: totals foot, tax lines follow a published article, Incoterms come from a fixed vocabulary in a dated revision, and money has a defined number of decimal places per currency. These pages work through the specific failures one field at a time, and lean on arithmetic wherever arithmetic is available — because a check the document performs on itself is worth more than any confidence score.

Extracting Vendor Names From Invoices When Every Invoice Formats Them Differently

An invoice carries several entity names that are all correct, and which one you want depends on whether you are paying, reporting tax, or reporting spend.

9 min read

Extracting Due Dates From Invoices That Don't State One

How to derive a payment due date from terms text and a base date, including the cases where the base date is not the invoice date.

9 min read

Extracting Multi-Currency Line Items From an Invoice

Why a single currency field is the wrong schema, and how ISO 4217 minor units keep a model from silently converting or rounding money.

10 min read

Extracting Tax and VAT Lines From Invoices Across Countries

VAT, GST and US sales tax are printed in structurally different ways, and a single tax_amount field silently merges three incompatible things.

10 min read

Extracting Purchase Order Numbers Buried in Invoice Headers

When the PO number sits in a free-text reference blob with four other codes, the fix is constrained matching against your own open-PO list, not a better regex.

9 min read

Detecting a Duplicate Invoice by Content, Not Filename

Why filename, file hash and invoice-number matching all miss the reissued duplicate, and which combination of extracted fields actually identifies one.

10 min read

Extracting Line-Item Discounts and Rebates From an Invoice

Discounts appear at three levels with three different meanings, and one of them must never be subtracted from the invoice total at all.

9 min read

Extracting Freight and Handling Charges Separately From Goods on an Invoice

Freight is a document charge, not a goods line, and the arithmetic on the invoice will tell you when it has been miscoded as one.

9 min read

Extracting Payment Terms Text Into a Structured Field

A deterministic parser for the common payment-terms forms, an LLM fallback for the tail, and a re-rendering check that tells you which one to trust.

10 min read

Reconciling an Invoice Total Against Its Own Line Items

The calculation chain an invoice must satisfy, done in integer minor units with a rounding budget rather than a floating-point tolerance.

10 min read

Extracting Line Items From a Handwritten Purchase Order

Handwritten quantities and prices have no spell-check, and the language prior that helps a model read words actively hurts it on digits.

9 min read

Matching a Purchase Order to Its Amendments

An amendment is a full reprint, so a naive diff says everything changed; the work is identifying which fields actually moved and applying only those.

9 min read

Extracting Delivery Terms (Incoterms) From a Purchase Order

Eleven codes from a dated revision, each requiring a named place — extracting the code without the revision and the place extracts almost nothing.

9 min read

Other topics