Line item extraction from invoices

Every invoice has a handful of header fields — vendor, invoice number, date, due date, currency, total — that appear once and are easy to locate. Then it has a table. The table can be three lines or three hundred; it can span pages; it can have a different set of columns from every other supplier's table. Extracting the header tells you how much to pay. Extracting the lines tells you what you are paying for, which is the question every downstream process actually asks.

Spend analysis needs line categories. PO matching needs line quantities and prices. Inventory needs line SKUs. Tax needs line-level rates. An invoice extracted without its lines is a payment instruction with no content.

A total is a single value in a predictable neighbourhood of the page. A table is a structure, and the structure is different everywhere. Classic OCR reads characters and positions; it does not know that the number under "Qty" belongs to the description two cells to its left, or that the description wrapped onto a second line, or that the last three rows are subtotals rather than items.

• Column sets vary per supplier: some have SKU and description, some have only description, some split unit price into net and gross.
• Multi-line descriptions wrap, and the second line looks like a new row to a position-based parser.
• Tables span pages, with headers repeated or not, and running totals at the bottom of each.
• Non-item rows — subtotals, discounts, freight, tax, "continued" — sit inside the table and must be classified, not extracted as products.
• Merged cells, right-aligned numbers drifting into the next column, and scanned skew all break coordinate-based parsing.
• Units and pack sizes hide in the description ("per case of 12") rather than in their own column.

Template-based tools solve tables by having you draw the table region and columns for each supplier's layout. It works — for that supplier, until they change their invoice format, at which point it silently produces wrong rows until someone notices. The maintenance cost scales with your supplier count, which is why teams with hundreds of vendors abandon these tools.

Template-free extraction uses a model that understands what an invoice line is, in the same way a person does, and returns rows against a schema you define once — description, quantity, unit price, amount — regardless of the layout. The trade-off is that a model can misread, which is why the output should be verified rather than trusted: arithmetic checks on each row, and human review when a check fails.

The output should be a table, not text: one row per item, one typed column per field, with numbers as numbers and dates as dates. Each row should carry the fields your downstream process needs and nothing that belongs to the header. Non-item rows should be excluded or flagged, not mixed in. And the output should be verifiable: if unit price times quantity does not equal the line amount, that row is wrong and should say so.

• Description — verbatim, because it is what any later matching or categorisation is derived from.
• SKU or part number — the supplier's, plus your own if a lookup can resolve it.
• Quantity and unit of measure — as separate fields.
• Unit price and line amount — both, so the arithmetic can be checked.
• Tax rate or code per line, where the jurisdiction requires it.
• A row-level verification status: arithmetic passed, or flagged with the reason.