Why the tax amount is harder to extract than the total
The total is a single number in a predictable place. The tax figure may be a line, a table of several lines, a percentage with no amount, a code beside each item, or absent entirely because the prices already include it. Extraction has to handle all of those, and the last one cannot be read at all — only derived.
This post is about getting the figure off the paper reliably. What your books are required to do with it, and which tax figures you can reclaim or deduct, depends on your jurisdiction and your circumstances — that is a question for your accountant, not for a scanning tool.
Where the figure actually lives
A single labelled line. The easy case: one tax line above or below the total, with an amount. Extraction here is roughly as reliable as the total.
A per-rate breakdown table. Common on receipts from vendors selling mixed goods. Several rows, each with a rate, a net amount and a tax amount, then a summary row. The extractable “tax amount” is now a set, and flattening it to one number loses the structure your books may need.
A per-item code. Each line on the receipt carries a letter or symbol, with a key in the footer mapping the letters to rates. The tax total may appear only as a single figure, or not at all. Recovering per-item tax means reading the line items and the key and joining them — three extractions in a chain, each able to fail.
Nowhere. Prices are shown tax-inclusive and no tax line is printed. Nothing to read.
Inclusive pricing means deriving, not reading
When the tax is baked into the displayed prices, the only route to a tax amount is arithmetic from the total and a rate. That works, and it introduces two new failure points.
The first is that you need to know the rate, which is not on the document. A system that assumes one for you is making a guess wearing the costume of a data field.
The second is rounding. Derive tax from a total and you will frequently land a fraction of a unit away from what the vendor actually charged, because they rounded per line and you rounded once at the end. The two figures are both defensible and they do not agree.
The honest handling is to store the derived figure and mark it as derived, so a later reader can tell the difference between “the receipt said this” and “we calculated this”. A derived value that looks identical to a read one is a small lie in your records.
Mixed rates on one receipt
A single supermarket run can contain items at different rates and items at none. A grocery shop and a bottle of cleaner and a magazine may sit in three different buckets on the same slip.
This breaks the common shortcut of storing one tax figure per receipt, and it breaks vendor-keyed category rules, because the vendor is not what determines the treatment here — the item is. The receipt is not the unit the accounting cares about.
If a vendor’s receipts routinely carry mixed rates, that vendor is a candidate for line-item extraction even though most vendors are not.
Blank, zero, and exempt look the same
A receipt with no tax line might be tax-inclusive pricing, a zero-rated basket, an exempt supply, a vendor not registered for tax at all, or a printer that ran out of ribbon before the footer.
Extraction sees one thing in all five cases: nothing. And the worst available behaviour is to record a confident zero, because a zero asserts a fact — no tax was charged — that the document does not support.
Absent and zero must be distinguishable in your data. If your tool cannot represent “not stated”, it will manufacture zeros, and no later review will spot them because a zero looks like an answer.
The vendor’s tax identifier
Many receipts print a registration number. It is worth capturing, and worth being clear about what capturing it achieves: it records what the vendor claimed. It is a string on a slip, not a verification.
It is also a genuinely difficult field to extract, because the label varies by country and the number’s format does too, so a system tuned for one jurisdiction reads the wrong string in another. Expect this field to be noisy and check it if you rely on it.
Practical handling
Prefer the printed figure over the derived one, always. If the receipt states a tax amount, that is the evidence. Recalculate to check it, not to replace it.
Store the rate breakdown when there is one. Collapsing a per-rate table into a single sum is a one-directional loss; you cannot rebuild it later from the receipt image without redoing the work.
Reconcile, and route the failures. Net plus tax should equal the total. When it does not, the difference is usually rounding and occasionally a misread field — which is exactly the sort of item a review queue exists for, since arithmetic failures catch confident errors that no confidence score flags.
Watch tax on foreign receipts. The rate, the label and the inclusive-or-not convention all change at the border, on top of the currency questions that come with the same receipt.
Decide what happens when it is unreadable. Not stated, flagged for a human, or left for the bookkeeper — pick one and apply it consistently. Silently zero is the option to rule out.
The general lesson is the one that applies to the whole extraction problem: fields differ enormously in how reliably they can be read, and treating them as one undifferentiated blob of “receipt data” hides which parts of your records you can lean on.