Agentic Arithmetic Validation for Financial Transaction Documents

Abstract 

The core of a financial transactional document is a set of numerical claims that must agree with one another. Invoices, credit notes and account statements include line amounts, subtotals, taxes, discounts, charges and balances, and each number on that document is implicitly assumed to follow from the others. Document extraction successfully tags the information in the document. But, does not establish whether they hold. One needs to explicitely observe and run a check to ensure the math adds up – i.e. someone needs to validate the correctness and the completeness of the information in the system.  

Here, we describe agentic arithmetic validation: where every extracted document as an overdetermined system of arithmetic relations, independently reconstructs each relation from its constituent parts, localizes any disagreement to the field most likely responsible, attributes the residual to a probable cause, and records the evidence behind every conclusion. 

We study the approach frameworks of arithmetic checking, from double-entry trial balances and casting out nines to mechanical calculators, check digits and modern research on spreadsheet and model error. We formalise the invariant families that govern invoice-like and statement-like documents, discuss tolerance and representation, and present design principles that distinguish an agentic validator from a rule list: separation of reading from computing, competing-hypothesis evaluation, constraint-based localisation, bounded autonomy with provenance, and abstention. Worked examples on synthetic invoice and statement data illustrate each principle. Implementation-specific logic, thresholds and models are deliberately abstracted. 

1. Introduction: extraction is not validation 

An extracted invoice is a set of assertions, not a set of facts. When a supplier states that ten units at 50.00 cost 500.00, that the lines sum to a subtotal, and that tax and freight bring the payable to a given total, each figure is a claim about the others. Modern document AI recovers those claims with high fidelity. Faithful capture of a wrong total, however, is still a wrong total. 

A document goes through multiple functions and hence the propensity for incorrect information increases. The vendor may err: a mistyped price, a transposed subtotal, a tax applied twice. The channel may corrupt: scanning, OCR and layout parsing can misread digits, drop decimal points or attach a value to the wrong field. And the document may be correct by its own arithmetic but wrong in context: a self-consistent tax at a rate that does not apply to the ship-to jurisdiction. 

Arithmetic validation addresses the first two directly and creates the preconditions for the third. Its premise is simple: a figure is accepted only after it has been independently recomputed from the other figures that determine it, within a stated tolerance, with the working retained. 

2. Why arithmetic validation is critical 

Arithmetic validation is a financial control. Its value comes after capture and before posting or matching, the last point at which an error is still not to expensive to correct. Five properties make it critical. 

Note that errors compound: a wrong figure at the line level can lead to an error across every figure computed from it, so the document can remain internally consistent at the header while being wrong throughout (Example A, Section 6). Second, error is asymmetric in cost: a false negative moves money, while a false positive costs reviewer attention. A validator must therefore be judged on both detection and restraint. 

3. Historical context: from checking to computing 

Every era of commercial arithmetic has paired faster calculation with a way to check it. References below show that redundancy, independent re-computation and a durable record have been explored for several problems across several decades:  

To summarize, redundancy detects error: a document that states its own subtotal and total is a ledger with built-in cross-footing. The copy step is the weak link: Babbage's transcription problem is today's extraction problem. Computation should be delegated: from the Burroughs tape to tool-using models, trust follows from a check that can be replicated. 

4. Problem formulation: the document as a system of claims 

We model a validated document as a set of fields and a set of arithmetic relations among them. A relation holds when its two sides agree within a tolerance; validation is the evaluation of every relation, followed by the inference of which fields explain any that fail. 

For line i, let q, p, d and t denote quantity, unit price, line discount and line tax, and n the stated line amount. At the header, let N be the stated subtotal, T the total tax, C additional charges, D the header discount and G the stated total. A relation is satisfied when |lhs − rhs| ≤ τ, where τ is the tolerance that applies to that relation. 

4.1 Invariant families 

The system is overdetermined: most fields appear in more than one relation. This redundancy is what allows localisation. A field that breaks every relation it participates in, while its neighbours satisfy theirs, is the likely culprit. 

4.2 Tolerance and representation 

Tolerance is a first-class design parameter. It must reflect the currency's minor unit, the issuer's rounding convention (per line or on the total; half-up or half-even), and the number of rounded terms being combined, since rounding residue grows with term count. Too tight, and legitimate rounding produces false positives; too loose, and small material errors pass. Tolerances should be configurable per client and per relation, and the applied tolerance should be recorded with each finding. 

All monetary arithmetic should be performed in exact decimal representation. Binary floating point cannot represent most decimal fractions exactly, and comparisons made on derived binary ratios can fail or pass for reasons unrelated to the document. 

5. Agentic arithmetic validation

An agentic validator differs from a rule list in that it reasons over the whole document: it chooses among interpretations, decides which field to doubt, derives what can be derived, and knows when to stop and ask a human. Six principles define it. 

agentic arithmetic validation · read, compute, decide, localise, record 

Only a relation that no admissible reading can satisfy becomes a finding; everything else is recorded as verified, with its working. 

P1. Separate reading from computing. Learned models are used where judgement is needed: identifying which span is a subtotal, whether a line is tax-inclusive, what a free-text term means. All arithmetic is then executed by a deterministic engine in exact decimal. A model that both reads and computes yields an answer that cannot be replayed; a model that only reads yields inputs whose consequences can be checked. This mirrors the program-aided and tool-use findings in the language-model literature. 

P2. Evaluate competing hypotheses before flagging. Many apparent failures are representational. A line amount may be net or tax-inclusive; a discount may apply before or after tax; a total may be stated gross or net. The validator tests each admissible reading and flags a relation only when no reading satisfies it. This is the single most important control on false positives: a supplier who invoices tax-inclusive would otherwise trigger a flag on every line, and reviewers would learn to ignore them. 

P3. Localise through the constraint structure. Because fields participate in several relations, the pattern of passes and failures identifies the probable source. If every line reconstructs, and the header closes over the stated subtotal, but the lines do not sum to that subtotal, the subtotal is the suspect, not the lines or the total. 

P4. Quantify and attribute the residual. A finding states the discrepancy amount, not merely its existence. The residual's structure carries diagnostic information: a residual equal to one line amount suggests an omitted or duplicated line; one equal to a tax or charge component suggests double counting; one that is a power-of-ten multiple suggests a decimal shift; and a residual divisible by nine is the classical signature of a digit transposition. Different causes call for opposite corrections, so attribution is as useful to a reviewer as detection. 

P5. Act within bounded autonomy, with provenance. The validator may derive a missing value that is fully determined by others, such as a unit price from amount and quantity or a total tax from its components. Every such value is marked as system-supplied, names its source and working, and leaves the original intact. Human corrections are final: no later automated pass overwrites them. 

P6. Know the limits of arithmetic. Arithmetic proves consistency.. Once a tax is shown to be consistent with its base, its rate is compared against an authoritative jurisdiction reference; converted amounts are checked against the rate in force on the document date. Where the reference is unavailable, the finding says unverifiable rather than passing silently, and completeness is judged only after every derivation has run, so "missing" means genuinely missing. 

6. Examples 

All data below is synthetic; amounts are in a generic currency with two decimal places. 

Example A: a header that closes over a wrong subtotal 

Every line reconstructs, and the header closes: 3,716.00 + 297.28 + 135.00 = 4,148.28. A check that tests only header closure passes this invoice. Cross-footing does not: the lines sum to 3,176.00, a residual of 540.00. Because the lines and the header both hold, the constraint structure isolates the subtotal (P3). The residual is divisible by nine, consistent with the transposition of 3,176 into 3,716 (P4). The tax is consistent with the stated subtotal, so it inherits the error. Total exposure is 583.20: 540.00 of goods never supplied plus 43.20 of tax on them. 

Example B: consistent versus correct tax 

B1, inconsistent. A line states a taxable base of 12,500.00, a rate of 18% and a tax of 2,125.00. At 18% the tax is 2,250.00; the stated amount implies 17%. The rate relation fails with a residual of 125.00, and the finding reports both the stated and implied rates. 

B2, consistent but wrong. A line states a base of 2,400.00 and tax of 204.00 at 8.5%. The arithmetic is exact. The authoritative jurisdiction rate for the ship-to address is 7.25%, giving 174.00. Arithmetic alone cannot find this 30.00 over-collection; it is caught only because consistency is established first and the rate is then tested against a reference (P6). 

Example C: a false positive avoided 

A line shows 10 units at 50.00 with a line amount of 590.00. Under the net reading, q × p = 500.00 and the line fails. Under the tax-inclusive reading, 500.00 × 1.18 = 590.00 and the line holds. The validator records the line as tax-inclusive and raises no flag (P2). 

Example D: an account statement with a carry-forward error 

The summary relation fails: 48,250.00 + 18,000.00 − 14,162.75 = 52,087.25, not 51,817.25. The summary check alone says only that the statement is 270.00 short. Row-by-row continuity localises it: only the 12 October row fails against its predecessor, and every later row is consistent with the wrong figure it inherited. The error is a single carry-forward, and its residual of 270.00 is again divisible by nine, the signature of 47,634.50 transposed to 47,364.50. A period-continuity check against the prior statement's closing balance would additionally confirm the opening figure. 

7. Evidence, provenance and auditability

A validation result is only as useful as the evidence a reviewer or auditor can read from it. Each finding attaches to the specific field it concerns and carries six elements: a severity, a stable reason code, a plain-language headline, the assertion with the actual values compared, the reasoning that led to the conclusion, and, where possible, the discrepancy and a suggested resolution. Example A's subtotal finding would read as follows. 

Four further rules make the record auditable. Severity is graded into correct, suspect or unverifiable, wrong, and system-supplied, so reviewers triage rather than read. System-supplied values are never silent: each is marked, sourced and accompanied by the original. Human corrections are final and survive reprocessing. Degradation is visible: if an external reference times out or is unavailable, affected fields are marked unverifiable with the cause stated, and no check is skipped silently. 

The result is a document that carries its own working, in the spirit of the printed adding-machine tape. A reviewer goes to the flagged fields, and an auditor can replay every conclusion from the values recorded beside it. 

8. Evaluation methodology 

A validator should be judged on whether it catches material errors without crying wolf, and on whether its findings let a reviewer act. We propose five measures, reported per client on that client's own documents rather than as a vendor-wide figure. 

Real traffic is sparse in errors, so evaluation should combine labelled production samples with controlled perturbation: take verified-correct documents and inject known error types (digit transposition, decimal shift, omitted and duplicated lines, double-counted tax, a wrong but self-consistent rate) alongside rounding-only noise as negative controls. Detection should be reported per error type and weighted by monetary impact, since a validator that catches every one-cent rounding mismatch but misses a decimal shift is worse than useless. Any accuracy or savings figure quoted externally should come from such a measured pilot, never from an estimate. 

9. Limitations and scope 

Arithmetic validation is necessary, not sufficient. Its boundaries should be stated as plainly as its strengths. 

• Consistency is not legitimacy. A fraudulent invoice can be arithmetically perfect. Duplicate detection, vendor verification, forensic tests such as digit-distribution analysis (Nigrini, 1996) and approval workflows remain separate controls. 

  
  

• It cannot recover what was never captured. Where no other field or authoritative record determines a value, the validator flags it; it cannot read a figure back from an image the extractor missed. 

  
  

• Localisation can be ambiguous. When two fields each break the same pair of relations, the structure may not single one out. The correct behaviour is to name the candidates. 

  
  

• Reference data has its own error and latency. A jurisdiction rate or exchange rate is only as current as its source; findings that depend on it should say so. 

  
  

• Tolerance is a trade-off. No setting eliminates both missed errors and false alarms; tolerances must be set per client and revisited as document mix changes. 

  
  

• The validator produces evidence. Posting and payment decisions stay with the client's workflow and approvers. 

10. Conclusion 

Eight centuries of commercial arithmetic converge on one rule: a number is trusted after it has been checked by an independent route, and the check is recorded. Agentic arithmetic validation applies that rule to every extracted financial document. It treats the document as an overdetermined system, recomputes each relation exactly, tests competing interpretations before raising an alarm, localises and quantifies what fails, and leaves a record a reviewer or auditor can replay. Extraction tells you what a document says. Validation tells you whether it is right, and shows its working. 

References 

1. Fibonacci, L. (1202). Liber Abaci. Pisa. 

   
   

2. Pacioli, L. (1494). Summa de arithmetica, geometria, proportioni et proportionalità. Venice. 

   
   

3. Pascal, B. (1645). Lettre dédicatoire à Monseigneur le Chancelier sur le sujet de la machine nouvellement inventée. Paris. 

   
   

4. Leibniz, G. W. (1685). Machina arithmetica in qua non additio tantum et subtractio sed et multiplicatio nullo, divisio vero paene nullo animi labore peragantur. Manuscript. 

   
   

5. Babbage, C. (1822). A Letter to Sir Humphry Davy on the Application of Machinery to the Purpose of Calculating and Printing Mathematical Tables. London. 

   
   

6. Ritty, J., & Ritty, J. (1879). Cash register and indicator. US Patent 221,360. 

   
   

7. Burroughs, W. S. (1888). Calculating-machine. US Patent 388,116. 

   
   

8. Hamming, R. W. (1950). Error detecting and error correcting codes. Bell System Technical Journal, 29(2), 147–160. 

   
   

9. Luhn, H. P. (1960). Computer for verifying numbers. US Patent 2,950,048. 

   
   

10. IEEE (1985). IEEE Standard for Binary Floating-Point Arithmetic (IEEE 754-1985). 

    
    

11. Goldberg, D. (1991). What every computer scientist should know about floating-point arithmetic. ACM Computing Surveys, 23(1), 5–48. 

    
    

12. COSO (2013). Internal Control — Integrated Framework. Committee of Sponsoring Organizations of the Treadway Commission. 

    
    

13. Sarbanes-Oxley Act of 2002, Pub. L. 107-204, §404. 

    
    

14. Panko, R. R. (1998). What we know about spreadsheet errors. Journal of End User Computing, 10(2), 15–21. 

    
    

15. JPMorgan Chase & Co. (2013). Report of JPMorgan Chase & Co. Management Task Force Regarding 2012 CIO Losses. 

    
    

16. Herndon, T., Ash, M., & Pollin, R. (2014). Does high public debt consistently stifle economic growth? A critique of Reinhart and Rogoff. Cambridge Journal of Economics, 38(2), 257–279. 

    
    

17. Nigrini, M. J. (1996). A taxpayer compliance application of Benford's law. Journal of the American Taxation Association, 18(1), 72–91. 

    
    

18. Cobbe, K., et al. (2021). Training verifiers to solve math word problems. arXiv:2110.14168. 

    
    

19. Gao, L., et al. (2023). PAL: Program-aided language models. Proceedings of ICML 2023. 

    
    

20. Yao, S., et al. (2023). ReAct: Synergizing reasoning and acting in language models. Proceedings of ICLR 2023. 

    
    

21. Schick, T., et al. (2023). Toolformer: Language models can teach themselves to use tools. Advances in NeurIPS 36.