GW
HomeWorkAboutNotesStackLab
Experience atOmnicom Group

Driving financial systems and automation across global teams.

Builder ofEnterprise AI Systems

AI agents, audit workflows, and decision intelligence at scale.

Based inNew York City

Building systems for enterprises around the world.

HomeNotesWorkAboutStackLabPartners
XLinkedInGitHubEmailllms.txt
© 2026 · New York City

Continuous Reconciliation Is an Agent Problem

Sep 15, 2026

Reconciliation is the most honest process in finance. Two records are supposed to agree. When they don't, someone has to find out why and prove it. Everything else in the close is downstream of that.

It is also the process most companies still run the way they did in 2005: a preparer pulls the ledger and the sub-ledger into a spreadsheet at month end, ties them out, explains the differences, and a reviewer signs. The evidence is the spreadsheet and an email thread. Internal audit samples a few. External assurance samples a few more.

That model breaks the moment you put an agent in the loop, and not for the reason people expect.

The batch assumption

Month-end reconciliation works because it is periodic. A break that appears on the 3rd and clears on the 9th never shows up, because nobody looked between the 3rd and the 9th. The process tolerates noise by not observing it.

An agent that reconciles continuously observes everything. It sees the timing difference on the 3rd, flags it, and now you have a break in the queue that a person would never have raised. Multiply that by every intercompany pair, every bank account, every sub-ledger, and the queue is unusable within a week.

Teams that try continuous reconciliation and give up usually give up here. The agent was accurate. The process was not designed for the accuracy.

What a break has to become

The fix is not a smarter agent. It is a stricter definition of a break.

A break needs four things attached before it is allowed to exist: a category (timing, mapping, data quality, genuine error), an owner, a materiality threshold, and an expected clearing window. Timing differences under threshold with a known clearing pattern auto-clear with a note. Everything else goes to a person.

That definition is what the agent enforces. It does not decide whether the books are right. It decides whether a difference is worth a human's attention, and it records why.

Evidence has to be a by-product

The second thing that changes is evidence. In the batch world, evidence is assembled after the fact for the auditor. In the continuous world, evidence has to be captured as the work happens, or it does not exist.

Every auto-clear needs the rule that cleared it. Every manual resolution needs the person, the reason, and the supporting record. Every sign-off needs a timestamp that an auditor can trace back through the chain. If the design does not produce that trail without anyone trying, it will fail its first control test.

This is the part the AI labs are now building toward. Anthropic ships a reference ledger reconciler. Apple's finance platform roadmap talks about continuous reconciliation and break management as platform primitives. The model is the easy part of both. The break taxonomy, the ownership, and the evidence trail are the product.

Where to start

Do not start with the agent. Start with one reconciliation that already hurts, usually intercompany or a high-volume bank account. Write down the break categories that actually occur, the thresholds finance would accept for auto-clearing, and who owns each category. That document is the specification. Build the agent to enforce it, run it in shadow mode against the manual process for two closes, and compare.

If the queue is manageable and the evidence pack exports cleanly, expand. If not, the taxonomy was wrong, and no amount of model quality would have saved it.

Ask a follow-up about this note
$