Invoice extraction needs an arithmetic check

Several correct numbers can produce the wrong record

Consider a synthetic invoice showing a subtotal of AUD 1,000, tax of AUD 100, a credit of AUD 50 and an amount payable of AUD 1,050. An extraction model reads every number correctly but selects AUD 1,100 as the payable total. The character recognition is accurate. The business record is wrong.

Document processing has at least three distinct questions: what text is present, which field it represents and whether the resulting record is consistent enough for the intended workflow. A high confidence score for reading a number does not settle all three.

Keep the original field text and its location beside the normalised value. This makes it possible to inspect whether the error came from recognition, field selection or later conversion.

Validate relationships without inventing a universal formula

For the example document, the displayed relationship is subtotal plus tax minus credit equals amount payable. The application can check that relationship because those components and their meaning are explicit. It should not assume every supplier uses exactly the same layout or calculation.

Invoices may include deposits, rounding, freight, discounts or amounts already paid. The validator needs a supported document model and an exception state when the relationship cannot be established. Forcing an unfamiliar invoice into a familiar formula can create a confident but incorrect correction.

Use decimal or integer minor-unit arithmetic according to the application's amount model. Binary floating-point comparisons can introduce small discrepancies that are unrelated to extraction quality. Define rounding tolerance from the business contract rather than choosing a large tolerance merely to reduce review volume.

Keep acceptance separate from extraction confidence

Use confidence as one signal, calibrated on the documents the application receives. A threshold that works for clean digital invoices may behave differently on scans or unfamiliar layouts. Measure actual field correctness and false acceptance for each important class.

Business checks can catch some high-confidence errors, but they are not complete proof. Two wrong fields can still add up. Matching a supplier and invoice identifier to trusted records may be just as important as checking totals.

Do not automatically overwrite an extracted value with a calculated one unless the workflow explicitly permits that transformation. A contradiction is often a reason to review the source, not a licence to decide which number must be wrong.

Make the exception easy to resolve

Show the reviewer the conflicting fields and their source locations. Explain the failed relationship in plain language, such as "the selected payable amount does not include the displayed credit". Keep the original document available for context.

Test a correct invoice, a wrong field selection and an unfamiliar adjustment. The system should accept supported cases and route unresolved contradictions without losing the evidence. That is more dependable than treating successful JSON output as permission to post a financial record.