On-chain settlement vs. traditional reconciliation

The monthly close is, at heart, a reconciliation exercise. Sub-ledgers are tied to the general ledger. Intercompany balances are eliminated. Bank statements are matched to cash records. Cut-off is enforced. The procedure exists because settlement, in the conventional financial system, is deferred. There is a gap between economic event and ledger finality, and the close closes that gap by inspection.

On-chain settlement closes the gap at the point of execution. The transaction is, in most cases, final within seconds. The ledger is the record. This is not an incremental improvement on existing settlement infrastructure. It is a different settlement model with different control requirements. The CFO who treats it as a faster bank wire will be surprised by what changes and what does not.

What reconciliation actually solves

Reconciliation does three things at once, which is part of why it is hard to design out of the close.

• It confirms that an economic event recorded internally also occurred at the counterparty or settlement layer. The bank statement is the external proof.
• It catches errors that the internal recording missed — a wire that did not clear, a chargeback, a fee that was not booked.
• It enforces a period-end position by acknowledging that some transactions are in flight, with a defined treatment for items that cross the period boundary.

Each of these functions has to be reproduced, in some form, in an on-chain settlement environment. The form changes. The function does not.

What changes when settlement is final at the point of execution

The biggest change is that the external proof and the internal record are, in principle, the same record. The blockchain transaction is itself the settlement evidence. There is no second source to match against — and there is no second source to disagree.

For transactions settled fully on-chain in a single currency, in a single entity, the reconciliation collapses into a verification: the on-chain record matches the entity's ledger. The period-end position is whatever the blockchain says it is at the closing block.

For carbon credit retirement, settled on Ethereum at a specific transaction hash, the cut-off question is unambiguous. A retirement at 23:59:43 on the 31st is in the period. A retirement at 00:00:07 on the 1st is not. There is no clearing house delay to litigate.

For an entity that uses the on-chain ledger as the system of record, the close cycle can be materially shorter. Not because the work happens faster but because some of the work has been designed out.

The new control problem: errors are also final and fast

If settlement is final at the point of execution, errors are also final at the point of execution. A transaction sent to the wrong address is not, in almost any case, recoverable. There is no clearing system to unwind. There is no fraud department to dispute the entry.

The control implication is significant: verification has to move upstream of the settlement event, not downstream. The conventional control environment relies on the ability to detect and remediate errors after they occur. The on-chain environment requires the controls to prevent errors before they occur, because remediation is unavailable.

What this looks like in practice:

• Multi-signature approval for transactions above defined thresholds, with the approval recorded before signing.
• Allow-listing of counterparty addresses, with a separate process for adding new ones that includes verification of the recipient.
• Smart contract logic audited before deployment, not after the first failed call.
• Simulation of complex transactions on a test environment with the same state as production.
• Limits on transaction size, frequency, and counterparties enforced at the wallet layer rather than at the manual-review layer.

The tagging and entity-mapping requirement

A blockchain explorer shows that a transaction occurred between two addresses for a given amount at a given time. It does not show why. The accounting purpose of the transaction — was this a customer payment, a supplier settlement, an intercompany transfer, a retirement, a fee — is not in the on-chain record.

That metadata has to exist in a layer above the blockchain, maintained by the finance function. The mapping is between addresses and entities, cost centres, revenue lines, and accounting purposes. It is an architecture problem to solve at the integration level, not a problem to solve at the close.

The entities that have built this layer well find their close compresses materially. The entities that have not built it find their close lengthens, because someone has to manually classify each on-chain transaction by inspection — and the volume of on-chain transactions can grow faster than the team available to inspect them.

What the close can become, what it cannot become

For finance functions that settle a meaningful proportion of activity on-chain, the close can become a verification rather than a reconstruction. The continuous record of on-chain activity, properly tagged, produces a near-real-time view of cash position and operating activity. Period-end becomes a snapshot, not a build.

That is the genuine prize. But two things the close cannot become:

First, it cannot become unaudited. The audit trail is on-chain and verifiable. The audit procedures still have to be performed — control verification, valuation, cut-off, off-chain liability matching, smart contract dependency review. The audit team's work changes; it does not disappear.

Second, it cannot become entirely automated. The judgement layer — the qualitative narrative, the variance explanation, the assessment of whether a flagged anomaly is a control failure or a business event — remains with humans. The compression is in the assembly and reconciliation, not in the analysis.

The CFO who manages this transition well ends up with a finance function that closes faster, reports more reliably, and spends less time on assembly and more time on insight. The CFO who treats on-chain settlement as a layer on top of an unchanged close ends up with neither the speed nor the insight.

This piece sits inside the CFO in blockchain framework. See also carbon credit accounting and smart contract risk. Lorna writes from practice at IMPT. The verified page records what is and isn't published here.