AI in Finance: Analysis, Reporting and Compliance

Finance has one property that no other vertical in this cluster has: almost every number has an independent total it is supposed to agree with. That single fact should decide the architecture, because it converts “is the model right” from a judgement into an equality check. This page is not financial, accounting or legal advice.

Everything ties to something

Line items sum to an invoice total. Debits equal credits. A bank statement’s opening balance plus its movements equals its closing balance. A subledger agrees to the general ledger. Finance is a system of redundant statements about the same money, and that redundancy is the whole point of double-entry bookkeeping — it exists so errors announce themselves.

A language model extracting from a document is a source of exactly the errors that system was designed to catch. It will read 1,240.00 as 1,24.00 on a bad scan, take a figure from the wrong column when OCR merges two, or silently drop the last of eleven line items. Every one of those breaks a tie-out. So the correct posture is not to make the model more reliable and hope; it is to check every extraction against the total the document already contains, and treat a mismatch as a routing event rather than an exception to be logged and ignored.

Extract, reconcile, route

The pipeline that survives contact with an audit has three stages and the model is only in the first.

document ──▶ extract (model)        ──▶ {lines[], stated_total, currency, dates}
          ──▶ reconcile (plain code) ──▶ sum(lines) == stated_total ?
                                        tax lines consistent ?
                                        currency single-valued ?
                                        dates within period ?
          ──▶ route                  ──▶ pass  → post with full provenance
                                        fail  → human queue, with the delta shown

Two things about that middle stage matter more than they look. First, the model never does the arithmetic. Asking it to sum eleven numbers introduces an error source in the one place you have a free check, and arithmetic is a known weak point. Extract the figures as strings, parse them deterministically, sum them in integer minor units — the reasoning is in money in integers — and compare.

Second, the failure output should show the delta, not just the word failed. “Extracted lines sum to 4,182.60; document states 4,192.60; difference 10.00” tells a clerk where to look in seconds. A round difference usually means a missing line; a difference of exactly one line’s value means a duplicate; a difference that is a multiple of nine means transposed digits. That is decades-old accounting folk knowledge and it makes the human queue fast.

The formats, and what they do to you

• Bank statements as PDFs. Column layout is positional, not tagged. A debit column and a credit column frequently merge in text extraction, so a payment becomes a receipt with the sign lost. Negative numbers appear as (1,240.00) in accounting convention and as a minus sign elsewhere, in the same document.
• Structured statements. Where MT940 or CAMT.053 is available, use it and do not put a model near it. It is a parsing job with a specification. The model belongs on the free-text remittance line inside it, which is where a human wrote “inv 4471 + 4472 less credit” and which no parser will ever handle.
• Dates that are not one date. Trade date, value date, invoice date, posting date, due date. Extracting “the date” from a document that contains four of them produces a field that is right most of the time, which is the worst possible outcome. Name each one in the schema; see schema design.
• Scale words. Financial statements say “in thousands” once, in small type above the table. A model that misses it is out by three orders of magnitude and every figure still ties out internally, so reconciliation will not save you. Extract the scale as an explicit field and require it.

Materiality is the threshold you already have

Every automated extraction pipeline eventually asks: above what confidence does a result post without a human. Most teams guess by tuning a constant until it feels right. Finance does not have to, because the profession already has a concept for how large an error has to be before it matters — materiality — and it is set for the entity, per period, by people whose job that is.

That gives a review policy with a defensible basis rather than a tuned constant: anything whose value exceeds the working threshold gets human review regardless of model confidence; anything below it is sampled, at a rate chosen so that the expected aggregate error stays under the threshold. It also gives the answer to the question an auditor will ask, which is not “how accurate is the model” but “what control detects an error, and what evidence exists that the control operated”. The reconciliation is the control. The logged pass or fail with the extracted values, the model version and the reviewer is the evidence — and it needs to be immutable and queryable, which is a logging design decision made on day one or never.

Where the model is genuinely good

Nothing above is an argument that finance is a bad fit. It is an argument about which half of the work to point it at. The half that fits well is the language half, and it is substantial: drafting the management commentary that explains a variance the numbers already establish, summarising a hundred pages of audit correspondence, normalising vendor names across three systems that spell the same entity four ways, classifying transactions to a chart of accounts, answering “which contracts contain a CPI-linked escalation” across the contract archive.

Note what those have in common. The output is either prose whose factual claims are checkable against a number the system already computed, or a classification a person can overturn in one click, or a shortlist whose false positives cost a glance. None of them is the model deciding what a number is. Keep that line and finance becomes one of the more tractable verticals rather than one of the riskiest.