Maker checker controls break when agents reconcile

Maker checker controls exist for exactly one reason: the party that moves the money must not be the party that confirms it moved correctly. Every variant of the rule (four eyes, dual control, segregation of duties) is a bet that two parties fail in uncorrelated ways. Remove the independence and you still have two steps in a workflow, but you no longer have a control.

That is what agentic accounting is quietly doing, and it is shipping as a feature rather than as a controls change. When the same system proposes a match, scores its own confidence in that match, and writes the ledger entry, you have not automated the maker and the checker. You have automated the maker and deleted the checker.

What maker checker actually buys you

The textbook version says one person prepares and a second person approves. That description is about people, which is why it survives automation so badly. The property that matters is not headcount. It is that the second opinion is generated by a different mechanism, from different inputs, with a different failure mode.

A junior accountant keying an invoice and a senior reviewing it are not independent because there are two humans. They are independent because the reviewer works from the source document and the bank statement, not from the junior's keystrokes. When the reviewer instead works from the junior's output and just asks "does this look plausible", the control has already degraded, whether or not anyone notices. Automation does not create this failure. It industrialises it.

This is the same distinction we drew when writing about building a payment reconciliation engine that survives real settlement files: a match is only evidence if the two sides came from genuinely separate systems of record.

The concrete case: one system on both sides

At Xerocon US on 19 August 2026, Xero announced that JAX, its agentic platform, now handles unreconciled items, duplicate transactions, missing documents and anomalies while keeping the ledger current in real time. Xero describes the posture as "AI that takes initiative, adapts to context and executes, with full human oversight at every step".

Credit where it is due: the engineering is careful. Xero's own product notes say Auto Bank Reconciliation "only reconciles transactions when it has a high level of confidence" and otherwise leaves the line for you, that it exposes the method behind each reconciliation (match, rule, memory, prediction or manual), and that automated changes are visible and reversible. It reconciled more than 100 million transactions in beta. Accounting Today reports the same confidence gating, with the feature working "alongside the user" and giving full visibility into the automation.

Every one of those is a real feature. None of them is a checker. Provenance tells you what the system did. Reversibility tells you that you can undo it if you find out. Confidence gating tells you how sure the doer is about its own work. That is the doer's opinion of the doer, which is the precise thing the control was designed not to accept.

The tell is in how the benefit gets framed. Xero describes the shift as moving customers "from manually reconciling, to reviewing". That is an accurate description of the product, and it is also a description of a control being replaced by an inspection.

Self-attestation fails in a measurable way

This is not a philosophical objection. Huang et al. tested whether models can revise their own reasoning without external feedback and found that LLMs cannot reliably self-correct, with accuracy sometimes degrading after a self-correction pass (ICLR 2024). Intrinsic review does not add information. It adds a second sample from a distribution that already contained the error.

Sherif Kozman, who has spent 25 years in payments infrastructure, makes the operational version of the argument in The Checker Cannot Be the Doer: "an automated doer checking its own calculations creates compound exception risk". His team's rule is blunt and worth stealing: large language models never touch raw financial calculations. He also points out that a counterparty's audit log only ever proves that counterparty's view of the world, which is why a bank attesting to its own movement of funds is not neutral verification either.

His numbers are the useful part. A deterministic reconciliation run matched 2,322 of 2,893 transactions on first pass, 99.36% agreement. Read that carefully: roughly one in five transactions did not match on the first pass. A real independent check produces a queue of exceptions, and that queue is the product. A system that reports near total success is either genuinely better or is not checking independently.

The human reviewer is not the checker either

The standard rebuttal is that a person still approves. Two problems with that.

First, the volume is the point of the feature. If the reason to buy it is that most lines clear automatically, the reviewer is not re-performing the work. They are sampling a list that is already marked correct, which is confirmatory review, not independent verification. The same pattern shows up in payments when a close match gets a soft warning: we walked through why in how close match handling in Verification of Payee decides liability.

Second, this failure mode has a name and a regulator has already written it down. The EU AI Act requires that people assigned oversight duties be able "to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)". Your bookkeeping agent is almost certainly not a high-risk system under Annex III, so this is not a compliance obligation for most teams. It is better than that: it is drafters of AI regulation stating plainly that "a human approves it" is not a control unless the human is equipped to disagree.

COSO reached the same conclusion from the accounting side. Its February 2026 publication, Achieving Effective Internal Control Over Generative AI, maps GenAI into the existing five components rather than granting it an exemption, and its central message is that generative AI does not replace internal control. If you run a close on an agent today, expect your auditor to ask which control the agent performs and what independently tests it.

What an independent check has to look like

The rule we apply on client work is that the checker must differ from the doer in at least two of three dimensions: input, mechanism, and failure mode. One difference is not enough, because a second model reading the same bank feed differs only in mechanism and still inherits every error in the feed.

None of this is exotic. It is the control structure that a double-entry ledger already implies, applied to a new kind of maker. The deterministic side is boring, cheap to run and, once built, the part your auditor actually trusts.

Objections worth taking seriously

"The model is more accurate than the bookkeeper it replaced." Probably true, and irrelevant. Controls are not about the expected error rate, they are about the tail. A more accurate maker with no checker has a worse worst case than a sloppier maker with one, because nothing terminates a systematic error.

"Building a second engine doubles the work." It does add work, and it is the cheaper half. Deterministic matching over a bank feed is a well understood problem with no training loop, no drift and no eval suite. Most of the cost you are avoiding is exception triage, which the agent side genuinely reduces.

"We log everything, so we can always go back." Logs are forensics. A control changes the outcome before the payment leaves or the books close. If your answer to a mismatch is a query against history, you have monitoring, not maker checker.

Where we land

Put the agent on the maker side and let it be aggressive there. Extraction, matching, supplier resolution and anomaly triage are real wins, and the confidence gating and reversibility that vendors like Xero are shipping make that side safer. Then build the boring deterministic check, from a source the agent never touched, and judge it by the exceptions it raises rather than the ones it clears. The moment your checker is a second model call on the same data, write down honestly that you removed a control, and let someone with authority decide whether that trade is acceptable.

Agentic finance is not the problem here. Agentic finance with a self-signed audit trail is. If you are wiring agents into a close or a settlement flow and want a second opinion on where the independent check belongs, that is the kind of fintech engineering work we do, and you can tell us what you are building.