Invoice data extraction

Parsing, capture, extraction: the same job under three names

The vocabulary in this category is inconsistent, and it is worth defusing before it costs you a procurement decision. "Invoice parsing" comes from the developer side and usually implies a document in, structured data out, with no interface. "Invoice data capture" comes from the enterprise document-management side and often implies a review screen and an operator. "Invoice data extraction" is the neutral term and is what most current products mean.

None of these words denote a technical distinction any more. What varies between products is not the noun on the homepage but three concrete things: whether line items are extracted or only header totals, whether unfamiliar layouts need configuring first, and what the output can be handed to.

When comparing tools, translate every marketing term back into those three questions. The answers differ substantially between products that use identical language.

Header fields

Header fields describe the invoice as a whole. There are roughly twenty of them that matter, and most invoices carry most of them somewhere on page one.

• Supplier name, trading address and, where present, registration or tax identification numbers.
• Buyer name and billing address, which is how you confirm the bill is addressed to the right legal entity.
• Invoice number, and separately any credit-note or reference number the document carries.
• Invoice date, due date, and any explicitly stated payment terms such as net 30 or a discount for early settlement.
• Currency, which must be read rather than assumed: a supplier billing in a second currency is a routine source of posting errors.
• Subtotal, tax amount, tax rate and total due, plus any prepayment or credit already applied.
• Purchase order reference, where the supplier quotes one.
• Payment details: bank account, sort code or routing number, IBAN, and payment reference.

Why line items are much harder than header fields

A header field appears once, in a bounded region, usually near a recognisable label. A line-item table has a variable number of rows, columns that differ per supplier, and no guarantee that a visual row corresponds to a single logical item.

The specific difficulties are structural. A description can wrap onto two or three physical lines, so a naive row reader produces phantom items with no quantity or price. Some suppliers insert subtotal rows, section headings or discount lines inside the table, which look like items and are not. Tables continue across page breaks, sometimes repeating the column header and sometimes not. Columns can be right-aligned numbers with no ruling lines, so the boundary between quantity and unit price is inferred from spacing alone.

The arithmetic check is what makes line-item extraction trustworthy. If the extracted quantities multiplied by their unit prices sum to the stated subtotal, the table was almost certainly read correctly. If they do not, something is wrong and the document belongs in review, whether a row was missed, a wrapped description was split, or a discount line was treated as an item.

This matters commercially because line items are what let you code spend properly. Header-only extraction gives you a total to post against one account. Line items let you allocate the same bill across departments, projects or expense categories, which is the difference between bookkeeping and cost visibility.

Validation: making sure the data is not merely confident

Extraction produces values. Validation asks whether the set of values is internally coherent, and it catches a category of error that confidence scores do not.

• Arithmetic: line totals sum to subtotal; subtotal plus tax equals the stated total; each line quantity times unit price equals the line total.
• Tax consistency: the tax amount matches the stated rate applied to the taxable base, allowing for rounding.
• Date logic: invoice date is not after the due date, and neither is implausibly far from today.
• Currency consistency: one currency across amounts, with any conversion stated rather than assumed.
• Duplicate checks: vendor plus invoice number against what you already hold, and a secondary check on vendor, amount and date for suppliers who reuse numbers.
• Reference validation: a quoted purchase order number exists and is open.

Structured output

Extracted data is only useful in a shape something else can consume. In practice that means JSON when a system is going to read it, CSV or XLSX when a person is, and a specific ledger-shaped file when an accounting system is the destination.

Two structural decisions come up every time. First, whether one record represents one invoice with a nested list of lines, or one record per line item with the header fields repeated. The first is natural for APIs, the second for spreadsheets. Second, how empty fields are represented: a missing purchase order reference should be explicitly null rather than an empty string, so that "the supplier did not quote a PO" is distinguishable from "we could not read it".

It is worth confirming the destination format early. Extraction that is perfect in the interface and produces a file your accounting system rejects on import has not finished the job.