The Reconciliation Agent

Close is slow because of exceptions, not volume. An agent that matches what can be matched, and hands the accountant a documented explanation for everything that cannot.

Ask a controller what makes month-end close slow and they will not say the matching. Systems already match the easy stuff. They will say the exceptions: the several hundred items that did not match, each of which needs a human to work out what happened, find the counter-evidence, decide the treatment and document it.

That is the work. It is investigative, it is repetitive, and it is done under a deadline by the most expensive people in the department.

Why finance is an unusually demanding place for an agent

Finance has a property most domains do not: the answer has to reconcile. In support, a slightly imprecise answer is a slightly worse experience. In finance, a number that does not tie is not a lower-quality output — it is wrong, and it will be found, and it will undermine confidence in everything the system produced.

That has two consequences for how we build.

First, the agent never generates figures. It retrieves them, computes with them deterministically, and cites where each came from. Arithmetic happens in code, not in a language model. The model's job is to reason about what an exception means and where to look, not to add things up.

Second, controls survive intact. Segregation of duties, approval thresholds, and audit evidence are not obstacles the automation routes around. If a human had to approve something before, a human approves it now.

What the agent does

Rules match what rules can match — the model never touches those items. It works only the residue, and proposes treatments rather than posting them.

Ingest and normalise. Bank statements, sub-ledger detail, general ledger balances, intercompany positions, payment processor settlements, and whatever else is in scope — pulled and normalised into a common shape. This is dull and it is where a lot of reconciliation projects quietly die.

Match deterministically first. Exact and near-exact matching runs as rules, not as inference. Amount, date window, reference, counterparty. The model is not involved, because it does not need to be and every item it does not touch is an item it cannot get wrong.

Investigate what remains. This is where the agent works. For each unmatched item it forms hypotheses and tests them against the data: a timing difference across a period boundary, an FX revaluation, a bank fee posted gross where the ledger has it net, a partial payment against a larger invoice, a transposition, a duplicate, a payment applied to the wrong customer. It searches for corroborating evidence, and it can propose a many-to-one or one-to-many match where the individual amounts never would have matched alone.

Explain and propose. Each investigated exception comes back with a plain-language explanation, the supporting evidence, a proposed accounting treatment, and a confidence level. Not a verdict — a documented recommendation.

Route by materiality and confidence. High-confidence immaterial items with a standard treatment go to a batch-approval queue. Material or ambiguous items go to a named reviewer individually. Anything the agent could not form a view on goes up with the search it already performed, so the accountant does not start from zero.

Post on approval. Journal entries are drafted with full support attached and posted only after human approval, through the ERP's normal channels with its normal controls.

The reviewer's day changes shape

Before: a queue of 400 unmatched items, all equally opaque, worked one at a time.

After: 340 items pre-explained and grouped by cause with a proposed treatment, 45 flagged as needing judgement with the evidence already gathered, and 15 the agent could not resolve — which are usually the genuinely interesting ones, and are now the first thing seen rather than the last.

The time saved is real, but the better outcome is where attention goes. Investigative capacity moves to the items that actually warrant investigation.

Guardrails

No auto-posting above materiality thresholds the client sets. No write-offs without approval, ever. No agent-initiated changes to master data — a "reconciliation" that fixes itself by editing the customer record is not a reconciliation. Full audit trail on every proposal, approval and posting, with the evidence retained and linked.

And the agent is required to be honest about uncertainty. We would far rather it escalate a hundred items it could have resolved than confidently propose one wrong treatment, because the second failure mode destroys the credibility of the first ninety-nine correct answers.

The finance copilot sits on top

Once reconciliation data is structured and traceable, the conversational layer becomes genuinely useful rather than a party trick. "Why did the intercompany balance move this month?" is answerable — with the specific transactions, cited, not a generated narrative.

We build that layer only on top of grounded data. A copilot over a warehouse with no lineage produces answers that sound authoritative and cannot be defended, which in finance is the worst possible combination.

What we measure

Auto-match rate, and separately the agent-resolved rate on what the rules could not match. Exception explanation acceptance — how often the reviewer agrees with the proposed treatment. Days to close. Reviewer touch time per exception. Post-close adjustment rate, which is the real quality signal: if adjustments rise after automation, the agent is producing plausible answers rather than correct ones.

What it does not do

It does not close the books. It does not exercise accounting judgement. It does not sign anything. It does the search-and-assemble work that consumes the close, and it hands a qualified human a well-documented starting point instead of a spreadsheet full of unexplained differences.

Finance is one of the domains we build agentic workflows in — copilots, close acceleration, reconciliation, AP/AR, variance analysis. Describe yours in the console or run /estimate.