Finance and the Reconciliation Wall

Two customers pay the same amount in the same week. An AI system matching bank deposits to open invoices attaches each payment to the other customer's invoice. The amounts agree to the cent. The bank balance agrees with the books. Every automatic check in the finance system passes.

A careful reviewer might catch it. If not, it surfaces weeks later, when a customer asks why a paid invoice is still marked overdue.

That small error explains most of what you need to know about AI in finance. Accounting is built so that numbers can be checked against other numbers, which makes it far better suited to AI than its conservative reputation suggests. But the checks only catch numbers that disagree. AI goes first in finance wherever a number has an independent second record to agree with, and it stops where judgment starts. The design that follows is simple: the model proposes, the ledger supplies the numbers, and a named person signs.

The error detector finance already owns

Accountants built their work so that mistakes would show up on their own.

Every entry posts to at least two accounts, and the debits must equal the credits. That's double entry. The customer balances in the receivables detail must add up to the receivables line in the general ledger. And every month, the cash in the books must agree with the cash the bank says it holds, to the cent. Proving that is called a bank reconciliation.

These checks come in three strengths, and the difference matters for AI.

A record agreeing with itself. An entry that doesn't balance can't post, which catches a mistyped amount on one side. It doesn't catch a balanced entry to the wrong account: book a laptop as office supplies instead of equipment and the books still balance.

Two internal records agreeing. A detail ledger tying to the general ledger, or two subsidiaries' balances with each other netting to zero. These catch postings that were dropped or duplicated, and miss an error made the same way in both places.

Your record agreeing with someone else's. The bank keeps its own record of your cash and has no interest in making your books look right. Supplier statements work the same way. This is the strongest check, because the second record was produced independently.

So when an AI proposes that a bank line matches three invoices, checking the proposal takes a few milliseconds of arithmetic: the amounts tie out or they don't. That's the property that let code move first too, with tests in place of the bank (Why Progress Arrives Unevenly). Few business functions have it built in. Finance does.

The wall catches numbers that disagree. It doesn't catch numbers that agree and are wrong.

The hole is classification: which customer, which account, which period a transaction belongs to. Two records can agree on an amount and both be silent about what the money was for. That's where the swapped payments in the opening slipped through.

Where the wall stops

Sort finance work by two questions. How cheaply can the output be checked automatically? And how much judgment and personal accountability does the task carry?

Scroll sideways to see the whole figure

Matching work sits where checks are cheap. Rules already do most of it: software pairs transactions by amount, reference and date. What rules leave behind is the messy remainder. One transfer covering three invoices. A card-processor deposit that arrives net of fees. A reference the bank cut to eight characters. Reading that text and proposing which ledger items a bank line covers is language work that models do well, and the proposal is cheap to check.

Estimates sit where judgment is heavy. How much to accrue for consulting work done but not yet invoiced. What reserve a doubtful receivable deserves. When a new contract's revenue can be recognized. There's no second record at month end, and the person who decides carries legal accountability. AI can gather the evidence (contracts, time sheets, delivery emails) and propose an amount with every input linked. The estimate stays a judgment.

There's a useful subtlety here. The SEC requires management to keep "reasonable support" for its assessment of internal controls. A contract the model found can be that support. The model's conclusion can't, for the same reason an unnamed colleague's opinion can't: nobody can examine how it was reached or hold it to account.

Even estimates get a second record eventually: the supplier's invoice arrives, and the gap between accrual and invoice measures the estimate. That gives you a way to judge an AI that proposes estimates: run it on past months whose outcomes are already known (Build an Evaluation From Your Own Work). It won't make this month's estimate checkable, but it tells you how far to trust the proposals.

Forecasts are their own case. Internal plans carry no audit opinion, so AI can draft scenarios with fewer gates, as long as the assumptions are explicit and someone later compares forecasts with actuals.

A month-end reconciliation, traced

Here's what this looks like in one month for one bank account at a mid-size company. Every number is an illustrative assumption, chosen to be plausible.

The account has 4,000 bank lines. Matching rules pair 3,120 of them automatically, 78 percent, with no AI involved. That leaves 880 lines for a person, at about six minutes each: 88 hours, roughly eleven working days of one accountant's month.

Now add a model. It reads each remaining bank line, its payment text and the open ledger items, and proposes matches for 640 of them, each with a stated reason. For a card deposit of 61,882.13, the reason might read: 412 card sales of 3 October totaling 63,401.90, less processing fees of 1,519.77. The proposal includes the fee as an entry to book.

Then code, not the model, checks every proposal. The tie-out, confirming a number agrees exactly with its record, requires the matched ledger items plus any adjustment to equal the bank amount exactly. The code computes the fee itself, as the difference, and checks it against the processor's contracted rate; the model's version of the fee is never trusted. No ledger item may already be matched elsewhere. Of 640 proposals, 598 pass. The 42 that fail sounded plausible and didn't add up.

In this example, 14. Each has perfect arithmetic and the wrong pairing, like the two customers in the opening. Suppose reviewers catch seven in ten such errors. Then about six wrong pairings get through each month, and they surface later, through a confused customer. The customer's own records form a second wall, slower and more embarrassing.

People now investigate 296 lines instead of 880: those with no proposal, those that failed the tie-out and those the reviewer rejected.

Scroll sideways to see the whole figure

The pile a person has to search falls by two-thirds. Total review time falls by less, 46 percent, because reviewing 598 proposals is new work, and the lines left over are the hard ones, taking eight minutes each instead of six.

The month still closes the same way. The bank balance, adjusted for deposits in transit and outstanding payments, must equal the book balance, adjusted for the fees, interest and corrections the reconciliation found. In the example both come to 4,754,849.62 and the unexplained difference is zero. Every figure in that proof comes from the bank statement or a ledger query. The model contributed pairings and reasons, and none of the numbers.

The model writes the sentence. The ledger writes the numbers.

That last point deserves to be a rule: in finance, a model should handle numbers only as references to values that a query or a calculation produced.

The reason is mechanical. A language model produces text one small chunk at a time by predicting what comes next, and a specific number recalled from memory or computed "in its head" is one of the places where fluent output is most likely to be wrong. Arithmetic is a known weak spot, partly because of how digits get split into those chunks (Confidently Wrong).

Finance benchmarks show the size of the problem, and where the fix lies. In 2023, GPT-4-Turbo, searching a shared index of company filings, answered wrongly or refused 81 percent of a reviewed sample of questions about those filings. Handed the right pages directly, the same model got 85 percent right. Most of the failure was in finding the evidence. Systems have improved since, but on a 2026 benchmark of questions an entry-level financial analyst might handle, the best system still scored about 64 percent, and the better-scoring systems were the ones that made more tool calls: looking things up and computing instead of recalling.

So the design is: the model drafts the commentary with placeholders bound to queries ("revenue rose {rev_change_pct} to {rev_q3}"), or a validator checks every figure in a draft against computed values and rejects any number without a source. And the reason a model offers for a variance is a hypothesis. "Revenue rose because of the price increase" gets tested by splitting the change into price and volume, or by asking the sales lead, before it reaches a board pack.

A model is not a control

Auditors like automated controls for one reason: a program, once tested and protected from unauthorized changes, does the same thing every time. SEC guidance from 2007 says so in plain terms, and lists automated matching among its examples.

A model doesn't meet that premise. The same input can produce different outputs, and a provider's update can change behavior without any change ticket in your own systems. My reading, until the SEC or the audit standard setters say otherwise, is that a model step can't be the control. It can be the preparer, like a junior accountant whose work gets checked. Three design rules follow.

Put the control after the model. The tie-out code and the balance proof are the controls. The same 2007 guidance describes a control where a person "manually investigates items contained in a computer generated exception report". AI changes what lands in that report and how much of the investigation arrives pre-drafted. It doesn't change who investigates or who signs.

Treat a model change like a program change. Pin the model version, record it on every proposal, and before switching versions rerun a set of past reconciliations whose answers are known.

Separate the powers. Segregation of duties applies to agents exactly as it does to people. No single actor, person or agent, should hold two of these four: propose an entry, approve it, post it, change vendor or bank details. The matching agent reads the bank feed and the ledger and writes only proposals. A model misled by a malicious payment note, or simply wrong, can at worst create a bad proposal for the tie-out or the reviewer to stop. Large entries, and entries to accounts the agent hasn't used before, always go to a person. Each posting carries an idempotency key, a unique tag built from the statement line, account and period, so a retry after a timeout can't book the same fee twice (When the Tool Call Fails Halfway). And every proposal leaves a record of its inputs, model version, reason, tie-out result, reviewer and time, because an auditor will read it.

"Finance is too regulated to move fast"

The objection deserves a fair hearing. Public-company executives certify their reports personally, and a material weakness in controls gets disclosed to investors. A finance leader who brings an unproven tool into the close takes a personal risk with little upside if it works. Caution is a rational response.

But regulation constrains finance in three specific places: changes to key controls, which must be documented and tested and are best made early in the fiscal year; evidence and duties, meaning who prepared, who reviewed and who could change what; and certain decisions about people, such as credit scoring of individuals, which the EU AI Act treats as high-risk. Bookkeeping, reconciliation and the close are not on that list.

Regulation doesn't constrain drafting, proposing matches, explaining variances, preparing evidence or building forecasts. Nothing in the US rules on internal control names a tool or forbids one. A design where the model proposes and a control checks fits the existing framework precisely, because the framework already assumes preparers make mistakes and controls catch them.

What actually slows finance teams is designing the controls and the evidence in advance. My advice is to bring the auditor in while the system runs in shadow mode, producing proposals that nobody acts on. That turns the audit from a late veto into an early review.

Where the time goes

The example saves about 40 hours a month on one account. That shortens the monthly close only if reconciliation was the step everything else waited on. Often the close waits instead on the last detail ledger, the accrual estimates and sign-off, and then the saving frees staff time without moving the reporting date (Where the Saved Time Goes). The bigger change may be timing: matching that's cheap can run every day, moving the work out of the month-end crunch.

Two second-order effects are worth planning for. Reconciliations were where junior accountants learned how money moves, and automation removes the easy matches they learned on. And as payments carry richer structured data, rules will match more on their own and the messy remainder left for AI will shrink. AI's role in matching may contract while its role in gathering evidence for judgment grows. The controls around it, the tie-out, the separated duties, the keyed postings and the evidence log, will outlast whichever model does the matching.

What to do

Start where a number has an independent second record. Bank and card matching, the invoice-order-receipt check, intercompany balances. The check is already there; you're only adding a proposer.

Never let the model be the source of a number. Every figure comes from a query or a calculation. The model writes sentences around them.

Put code and a person after the model, and keep the powers apart. Proposals go to a staging area, code ties them out, a reviewer accepts or rejects, and a separate service posts. No actor holds two of propose, approve, post and change payment details.

Measure the hole. Each month, sample accepted matches and confirm them against customer statements or payment advice. That tells you how many wrong-but-tying pairings get through, which no vendor can tell you.

For estimates, use AI to gather evidence. Let it propose an amount with every source linked, test it on past months, and keep the signature with a person. And bring the auditor in early.

AI in finance will advance fastest where the profession's oldest habit already protects it: wherever a number has a second record, and a person signs when the two agree.

Check yourself

Why was the swapped-payment error invisible to every automatic check?

The amounts agreed to the cent and the bank balance agreed with the books. The checks catch numbers that disagree, not a wrong classification where the numbers agree.

Why should a model never be the source of a number in finance?

A model predicts text one chunk at a time, so a number recalled or computed in its head is a place where fluent output is likely to be wrong. Numbers should come from a query or a calculation, with the model writing the sentences around them.

Why can a model step not be the control, but still be the preparer?

A tested program does the same thing every time, while a model can give different outputs and a provider update can change its behavior. Like a junior accountant, it can prepare work as long as a control after it checks the result.