Why line-item extraction is harder than reading the total

The total is the largest number near the word 'total', usually at the bottom of the page. That is a shape a parser can learn. A table of twenty lines with wrapped descriptions, a continuation onto page two and a running subtotal in the middle is not a shape — it is a structure that has to be rebuilt.

Tables without borders

Many invoice templates separate columns with whitespace rather than rules. Column boundaries then have to be inferred from the alignment of the values themselves, and a single description that wraps onto a second line can shift every value on that row into the wrong column.

Page breaks and phantom rows

When a table continues onto a second page, the header may or may not repeat, and a carried-forward subtotal often appears that is not a line item at all. Treating it as one silently inflates the parse — and because the arithmetic still nearly works, it is exactly the kind of error that survives a quick review.

Arithmetic as a safety net

Two checks catch most of this. Quantity multiplied by unit price should equal the line total, and the lines should sum to the subtotal. Where either fails, the affected rows are flagged for review rather than exported as though nothing happened.

This is why arithmetic validation matters more on line items than anywhere else on the document: it is the only place where the page contains enough redundancy to check itself.