Line items extract cleanly but they do not sum to the invoice total

The exception says invoice line items do not match total. Extraction is the usual suspect and is usually innocent: every field on the page was read correctly, and the arithmetic still fails because the document's own totals were never computed the way your validator computes them. Before opening the PDF, divide the difference by the extracted subtotal. That single ratio separates a tax convention problem from a missing charge line from a lost page, and it takes a second.

It helps to know that the chain is specified rather than conventional. The European semantic standard for electronic invoicing, as implemented in the Peppol BIS Billing 3.0 specification, defines the whole sequence — the sum of line net amounts, document-level allowances and charges, a tax breakdown per category and rate, the total with tax, prepaid amounts, and an explicit rounding adjustment on the amount due. Structured invoices carry those as separate values. A PDF prints some of them, implies others, and leaves your validator to reconstruct the rest.

Compute the chain, not the sum

1. Line net for every row. Quantity times unit price, adjusted by any line-level discount or charge. Where the row prints both a unit price and an extended amount, take the extended amount and use the multiplication as a check on it, not the other way round.
2. Sum the line nets to a document line total. Compare it against the printed subtotal before going any further; if these already disagree, the fault is in the table and nothing further down the chain will diagnose it.
3. Apply document-level allowances and charges. Settlement discounts, delivery, freight, insurance, surcharges and handling appear beneath the table on most layouts and outside it on all of them.
4. Compute tax per rate, not once. An invoice with lines at 2 different rates has 2 taxable bases, and a single rate applied to the whole subtotal will be wrong whenever the mix is not uniform.
5. Add tax to reach the gross, then subtract prepaid amounts and apply any stated rounding adjustment to reach the amount due. The amount due and the invoice total are different fields and a validator that treats them as one will fail every invoice carrying a deposit.
6. Record the residual at each step, not a single pass or fail. Knowing that the chain broke between the line total and the taxable total is most of the diagnosis.

Divide the difference by the subtotal before opening the page

One signature is not on that list because it is not really an arithmetic fault. A residual that is a factor of 1,000 out, or that turns 1.234,56 into something a hundred times larger, is a separator convention misread — the fault that only damages documents from particular sources, described in dates and amounts wrong for one client's suppliers. Check it first when the residual is absurd rather than merely wrong.

Tax-inclusive lines against a tax-exclusive total

This is the single most common cause and the one most often misdiagnosed as a reading error. Retail-facing suppliers print line amounts with tax included; business-facing suppliers usually do not; some print both and label neither clearly. A validator that assumes exclusive lines will fail every invoice from the first group by exactly the tax fraction, and a validator that assumes inclusive lines fails the second group the same way in the opposite direction.

The fix is not a smarter parser. It is a captured property: record on the supplier record whether that supplier's lines are tax-inclusive, default it to unknown, and let the arithmetic itself resolve unknown by testing both readings and accepting the one that closes exactly. That inference is only durable if the supplier record is stable, which is a real dependency — where one supplier arrives under six different names, a property learned on one name protects a sixth of their invoices.

The charge that never appears in the table

Table recognition finds tables. Freight, insurance, packaging, fuel surcharges, environmental levies, settlement discounts and deposit deductions are typically printed as loose label-and-amount pairs beneath the table, sometimes in a second column beside the totals block, occasionally in the footer. They are part of the arithmetic and outside the structure your extractor was looking at.

Extract the totals block as its own object with its own field set — subtotal, each named adjustment, taxable amount, tax per rate, gross, prepaid, amount due — rather than treating it as the last few rows of the table. That separation is what makes the residual interpretable: when the chain fails, you can say which of those fields is missing rather than only that something did not add up.

Rounding is the only difference you may accept

The standard's own rules are the right guide here. Peppol BIS Billing 3.0 requires document-level amounts to be rounded to 2 decimals and line net amounts likewise, and states that results of calculations involving already-rounded amounts are not themselves subject to further rounding. It also provides an explicit rounding adjustment on the amount due — an admission, in the specification itself, that the chain does not always close to the cent.

So set a tolerance that is bounded by structure rather than by taste: no more than 0.01 per line, and never a flat allowance that scales with the invoice value. A 40-line invoice may legitimately differ by 0.40 through per-line rounding; a 4-line invoice may not differ by 0.40 by any legitimate route. A tolerance expressed as a percentage of the total is the version of this rule that silently swallows real faults on large invoices.

A failed arithmetic check blocks; it does not lower a score

Confidence scores measure how sure the reader is about what a character was. Arithmetic measures whether the document is internally true. They are different quantities, and folding the second into the first is how invoices with impossible totals reach a ledger: a field read with 0.99 confidence in a document whose chain fails by 240.00 still averages into a healthy-looking score, and an approval threshold set on that average lets it through.

Keep them separate in the record and separate in the gate. Field confidence routes to review; a broken chain blocks posting outright and produces a reason naming the step that failed and the residual. That queue then needs an owner and a deadline, because an exception queue with neither becomes an archive — and the dates it has to be empty by come from the filing calendar, which is its own moving target, as a deadline calendar that survives rule changes sets out.

A confidence score says how well the page was read. The arithmetic says whether the page can be true. Only one of them should be allowed to stop a posting.

Sometimes the arithmetic is fine and the document is not an invoice

A recurring, unresolvable chain failure across documents from one source is often a routing fault rather than an extraction one. Statements of account list open invoices and total them without ever being an invoice; proforma invoices, delivery notes with prices, quotations and credit notes all present a table and a total, and none of them obeys the invoice chain. Applying invoice arithmetic to a statement of account produces a residual every time and no amount of parser work will close it.

So make the arithmetic result feed back to classification instead of only to review. A document that fails the chain by exactly the sum of its own lines is a strong signal it was never an invoice, which is the routing argument in routing an incoming client file to the right handler. Wiring validation results back into routing is a small piece of product build work and one of the higher-yield ones in extraction and classification of source documents, inside the accounting and tax systems we build.

• document extraction
• invoices
• validation
• data quality