In most systems, “reconciliation” names a job that runs at 2 a.m., compares two tables, and emails a count of differences that someone reads on Monday. In a system that moves money it is a control - the mechanism that decides whether the balance you are quoting to a customer, to a regulator, and to your own finance team matches reality at the counterparty. The difference between the two is not the query. It is that a control classifies every difference, gives it an owner, and puts a clock on it. A count of breaks is not a result. Eleven breaks, of which nine are timing differences that clear on the next cycle and two are real and cost this much, is a result.
The classification people skip is the first one: timing against true. Most differences are not errors at all. Your side recorded at instruction, the counterparty recorded at settlement, and the gap between them crosses your cut-off. A reconciliation that cannot separate a difference that has not settled yet from one that never will produces noise, and a control that produces noise is ignored inside a month - which is worse than having none, because now there is a green check nobody trusts. So the comparison has to know about the cycle: match on the identity of the business event and the state it is expected to be in at that point, not on two balances photographed at midnight.
This is where the argument for an event log stops being a matter of architectural taste. Comparing two mutable balances tells you that they differ and can never tell you why, because the history that would explain it was overwritten in place. An append-only log of the events that moved the balance - each with an identity, a cause, and an order within its account - turns the question into which event is missing or extra, and that one is answerable, by one person, in minutes. The balance becomes a value you recompute rather than a value you repair, so recovery is a replay instead of a manual adjustment with a note attached. Throughput is the usual reason given for an event-driven core in a money system. Being able to explain a discrepancy is the better one.
Once the log exists, reconciliation no longer has to be nightly. It runs continuously against the stream, and a break surfaces seconds after it appears rather than twelve hours later, after the wrong number has been quoted all day. We keep the periodic full pass anyway, and we keep its inputs independent - it reads the counterparty's own statement, not the stream it is checking, because a control that shares inputs with the thing under test is not a control. That independence is what makes a claim like “no order lost between a sales channel and the client's ERP” defensible. It does not come from an integration that reports its own errors. It comes from positively matching every order in the channel to a record in the system of record, and raising anything still unmatched past its expected window.
This is not only an accounting concern. On a trading platform, positions across brokers are reconciled into a single portfolio view, and that view is an input to the next order - a strategy acting on a stale position places trades it should not. Same control, shorter clock. The rule we hold to is to build the reconciliation before the feature that depends on it, because it is a week of work early and it is the only thing standing behind the answer when someone asks whether you are sure. There are two honest answers to that question: yes, with the check that ran four minutes ago attached, or no. A CFO or a regulator can work with either. Neither of them is a spreadsheet from Monday.