Reconciliation: the AI use case nobody demos

It is unglamorous, it is everywhere in finance operations, and it is a better fit for a language model than most of what gets demonstrated on stage — provided the model never touches the arithmetic.

Share

Every finance team reconciles something. Bank lines against ledger entries, invoices against purchase orders, remittances against outstanding balances, supplier statements against what was actually received.

Rules handle the clean cases. What remains is a queue of near-matches that someone works through by hand, and that queue is where the month-end hours go. It is also an unusually good fit for a language model, for a reason worth being precise about.

Why the residue is hard for rules and easy for judgement

The unmatched items are unmatched because something is inconsistent in a way a rule cannot generalise. A reference number with a typo. A payment covering three invoices minus a credit note. A supplier name that changed after an acquisition. A payment 4p short because of an intermediary fee. A date recorded in the wrong timezone across a month boundary.

Each of these is obvious to a person with context and awkward to express as a rule. You can write a rule for any one of them; you cannot write rules for the general shape, which is "these two records are probably the same event despite superficial disagreement".

That is a judgement task on messy text, which is what the technology is genuinely good at.

The one rule that makes it safe

The model proposes the match. Code does every calculation.

The model's job is to say "this payment of 1,247.30 probably settles invoices A, B and C less credit note D, because of the reference fragment and the supplier name". Then code fetches those records, sums them independently, and compares. If the arithmetic does not reconcile exactly, the proposal is rejected regardless of how confident the explanation sounded.

This is not a small distinction. A model asked to verify its own totals will occasionally produce plausible arithmetic that is wrong, and in finance a plausible wrong number is the worst possible output. The model is a hypothesis generator; the ledger is the judge.

What the system needs to be trusted

An explanation in domain language. Not a score. "Reference 4471 appears in the payment narrative; supplier renamed in March; amount matches invoices 1102 and 1104 less credit 88." A reviewer can accept or reject that in seconds, which is the only way the queue actually shrinks.

A confidence band tied to an action. Exact arithmetic match plus strong reference evidence can auto-post within a threshold. Anything else goes to review. The threshold is a business decision and belongs in configuration, not in a prompt.

Every proposal recorded, accepted or not. Rejections are the most valuable data the system produces — they are expert labels on its errors. They belong in the evaluation set.

Reversibility. An auto-posted match must be traceable to the proposal and the evidence behind it, and it must be reversible in one action. Auto-posting without that is not automation, it is an unlogged write to the ledger.

Why it is worth doing despite being dull

Reconciliation has the properties that make AI projects succeed and that flashier use cases usually lack: the ground truth is unambiguous, the arithmetic check is exact, errors are caught by the check rather than by a customer, and there is an existing manual process to compare against.

It will not appear in a keynote. It closes the month faster, every month, and it is verifiable — which is a considerably better basis for the next project than a demo was.