On-chain settlement changes the raw material of accounting — the transaction record — and the finance function that adapts to it earns advantages in speed, accuracy, and audit quality that the one clinging to the old workflow cannot match.
The month-end close has been the rhythm of the accounting function for as long as there have been accounting functions. The period closes, transactions are gathered, journals are posted, reconciliations are run, and — eventually — a set of financial statements emerges representing the company's position as at a date that is now two to six weeks in the past.
That lag was unavoidable when information had to be gathered from disparate sources, assembled by hand, checked, and corrected. The close was slow because the data was slow.
On-chain settlement changes one fundamental variable: the transaction record is instant, public, immutable, and does not need to be gathered from anywhere. It already exists. The question for the finance function is whether it has built the infrastructure to use that fact.
Section IWhat the blockchain changes about the transaction record
A conventional commercial transaction creates a trail of records across multiple systems: the seller's accounting system, the buyer's, the banks on both sides, potentially a payment processor. Reconciling these against each other is the core activity of the close. When they disagree — as they routinely do, for trivial reasons of timing, rounding, or categorisation — someone investigates, identifies the discrepancy, and posts a journal to correct it.
An on-chain transaction creates a single record. That record is the transaction. It is timestamped to the second, cryptographically signed by both parties, and permanently inscribed in the blockchain's ledger. It cannot be altered retroactively. It is, in principle, self-proving: an auditor who wants to verify that a payment was made can read the blockchain directly, without relying on a bank confirmation letter.
This does not eliminate the accounting work. Accounting is not simply recording that a transaction occurred — it is categorising what it means: which account, which period, which entity in a group structure, what the tax treatment is, what disclosures it triggers. None of that judgment is performed by the blockchain. What changes is the quality and accessibility of the raw input that accounting judgment is applied to.
Section IIThe close in an on-chain environment
A company settling a significant proportion of transactions on-chain has access to a ledger that is complete, ordered, and immutable in real time — not at month end. The architecture that unlocks this for the close is one where:
Blockchain data is ingested continuously via an API connection to a node or data provider. Every relevant transaction — those touching the company's wallet addresses — is captured and classified as it occurs.
Classification rules are applied automatically based on transaction pattern. Inbound transactions to the revenue wallet from known customer addresses are classified as revenue; outbound from the treasury wallet to known supplier addresses as cost of sales or operating expense; on-chain token transfers associated with carbon retirement events are classified according to the established policy.
Reconciliation runs continuously, not periodically. The accounting ledger and the on-chain ledger agree at all times because the accounting ledger is derived directly from the on-chain one. There is no reconciliation exercise at month end because the reconciliation has been running throughout the period.
Period-end journals are restricted to estimates and accruals — items that by their nature cannot be automated, because they require judgment about future events: accruals for uninvoiced costs, provisions, fair value measurements. These remain human work, but they represent a small fraction of the total journal volume when the underlying transactions are already classified and reconciled.
Audit evidence is prepared continuously. The auditor who wants to verify balances and transactions can do so against the blockchain record, without waiting for bank confirmations. The evidence assembly phase — historically one of the slowest parts of an audit — is largely pre-completed.
Section IIIThe carbon retirement case
IMPT's on-chain carbon credit retirement illustrates the practical effect concisely. When a booking is made on the platform, a carbon credit is purchased and retired on Ethereum in the customer's name. The retirement event — the permanent, irreversible removal of the credit from circulation — is recorded on-chain. That record is the service delivery confirmation: it proves the carbon offset has been executed, not merely promised.
For accounting purposes, the retirement event triggers: revenue recognition for the carbon offset component of the transaction (the performance obligation has been satisfied); and derecognition of the credit asset (consumed, not resold). Both events are timestamped and verifiable from the blockchain record. There is no ambiguity about when they occurred, no possibility of reversal, and no need to await third-party confirmation.
The accountant's work on carbon offset accounting is, in principle, fully automatable from this structure. The blockchain event is the trigger; the accounting entry follows deterministically from the event type. The residual judgment work — which acquisition cost to attach to the retired credit, using FIFO, weighted average, or specific identification — remains human, as does the period-end measurement of any credit inventory held.
Section IVWhat the finance team does differently
A finance function with continuous on-chain ingestion does not spend the first week of every month rebuilding the prior month's picture from scattered inputs. It starts the month with a complete, already-reconciled view. Close work is concentrated on the estimate and accrual layer, not the transaction layer.
Two significant consequences follow. The close timeline compresses: a business with a conventional close might take ten to fifteen working days to produce final management accounts; a business with continuous on-chain ingestion can, in principle, close the transaction layer in hours. And the quality of the output improves: fewer manual entries mean fewer manual errors, and the absence of the reconciliation grind removes the pressure that causes people to force a balance rather than investigate a genuine discrepancy.
Neither advantage arrives automatically. Both require investment in data architecture — the ingestion layer, the classification engine, the integration with the general ledger — and a willingness to redesign close workflows that have been in place for years.
For a business where on-chain settlement is part of the operating model, that investment is not optional. The data is being generated. The question is whether the finance function has built the infrastructure to use it.
Lorna Mason is CFO of IMPT, Dublin. Contact: lorna@impt.io