The CFO in Blockchain

Section IA New Kind of Balance Sheet

The finance function is trained on certainty. A bank balance has a timestamp. A receivable has a counterparty, a due date, an agreed currency. A fixed asset depreciates on a schedule. The ledger, at its best, is a picture of the world that a reasonable person can verify.

Crypto assets complicate this picture — not because they are inherently unverifiable, but because the verification machinery is new, the accounting standards are catching up, and the risk profile is genuinely different from anything in the traditional treasury playbook.

When a company holds a native token on its balance sheet — whether issued by the company itself or held as a reserve asset — the CFO must answer several questions simultaneously. What is it? Where does it sit in the accounting hierarchy? How is it valued? What are the tax consequences of holding, receiving, paying, or retiring it? Who audits it and against what standard? And, critically, what controls prevent the asset from becoming a liability of a different kind — reputational, regulatory, or operational?

These are not hypothetical questions for companies operating at the intersection of digital commerce, global travel, and on-chain sustainability. They are live accounting problems, and they require precise answers.

Section IITreasury When the Balance Sheet Holds a Token

A token held as a treasury asset is, under current IFRS and US GAAP treatment, classified as an indefinite-lived intangible asset unless it meets the definition of cash, a financial instrument, or an inventory item. In most cases, it does not meet those definitions. The consequence is measurement at cost, with impairment testing but no upward revaluation — a treatment that understates a rising asset and faithfully records a falling one. This asymmetry is not trivial. It affects reported earnings, covenant calculations, and the narrative an auditor must give a reader.

IFRS 9 provides a partial route for certain crypto assets that behave more like financial instruments, and IAS 2 applies in cases where tokens are held for sale in the ordinary course of business. Neither framework was written with digital assets in mind, and the resulting patchwork creates legitimate room for accounting judgement that must be documented, disclosed, and defended.

The practical treasury implications are significant:

• Custody and control. Unlike a bank deposit, a token is controlled by whoever holds the private key. Custody risk is therefore a treasury risk, not merely an IT risk. The CFO must understand the custody model — proprietary key management, qualified custodian, multi-signature arrangements — and ensure it is reflected in the control environment. An asset that can be lost, transferred, or compromised without a counterparty fails the most basic internal control test.
• Concentration and liquidity. A treasury holding a native token is, by definition, concentrated in a single asset that may have limited liquidity on secondary markets. Liquidity risk management must account for the spread between mark-to-market and realisable value, particularly in conditions of market stress when bid-ask spreads widen and on-chain settlement may not match the urgency of the need.
• Valuation cadence. Daily or even intraday price movement in crypto assets creates a disclosure challenge that quarterly or annual valuation cycles were not built to handle. The CFO must decide at what cadence to mark the treasury position, what source of pricing is authoritative, and how to disclose the sensitivity of reported figures to price movement.
• Quantum-resistant considerations. This is a longer horizon issue, but not an academic one. The cryptographic assumptions underlying current blockchain networks — elliptic curve cryptography primarily — are theoretically vulnerable to a sufficiently powerful quantum computer. Custody infrastructure and signing protocols that are not post-quantum resistant carry a tail risk that prudent treasury management should at minimum document and monitor.

Section IIIOn-Chain Settlement and What It Does to the Close

The traditional monthly close is a reconciliation exercise. Transactions accumulate in source systems; journals are posted; intercompany balances are eliminated; cut-off is enforced by closing sub-ledgers. The process is designed for a world where settlement is deferred — where there is always a gap between economic event and financial finality.

On-chain settlement collapses that gap. A transaction recorded on a public blockchain is, in most cases, final within seconds to minutes. There is no clearing house delay. There is no correspondent banking chain to unwind. There is no counterparty dispute about whether payment was received. The ledger is the record.

This changes the close in ways that are simultaneously an opportunity and a control challenge.

The opportunity is obvious: a company that settles a material portion of its transactions on-chain can, in principle, know its cash position in real time. The traditional close cycle — the days of frantic reconciliation that consume finance teams at every month-end — compresses for those transaction streams. A carbon credit retirement executed on-chain at 14:37 on the 31st is recorded, immutably, at 14:37. There is no ambiguity about the period in which it falls.

The control challenge is less obvious but equally important. When settlement is final and fast, errors are also final and fast. A traditional bank transfer gone to the wrong account can be recalled, with friction, through the banking system. An on-chain transfer gone to the wrong address is, in almost all cases, permanent. The control environment must therefore shift upstream: verification before execution, not reconciliation after the fact. Smart contract logic must be audited before it is deployed, not after it has processed ten thousand transactions.

For the finance function specifically, on-chain settlement introduces several new requirements:

• Transaction tagging and categorisation. Blockchain explorers provide a complete transaction history, but they do not categorise transactions by accounting purpose. The finance team needs a mapping layer between on-chain addresses and entities, cost centres, and revenue lines. This is an integration challenge that must be solved at the architecture level, not retrofitted at month-end.
• Foreign exchange treatment. If on-chain settlement occurs in a cryptocurrency that is not the functional currency of the reporting entity, each settlement event is a foreign currency transaction for accounting purposes. The gain or loss crystallises at the moment of settlement, not when the proceeds are converted to fiat. In a high-volume environment, this creates a large number of small FX entries that must be captured and reported.
• Audit trail versus privacy. Public blockchains offer a complete, immutable audit trail — a property that auditors, in principle, appreciate. But the same transparency that makes the audit trail verifiable also makes every counterparty visible to anyone who looks. Companies need to decide, deliberately, what address structure and disclosure policy is appropriate, and ensure that the legal and privacy implications of on-chain transparency are understood by the board, not just the technology team.

Section IVCarbon Credits as an Accounting Question

The CFO of a company with a carbon offset programme confronts a question that most accounting standards bodies have not answered with any precision: what, exactly, is a carbon credit?

The answer is not settled. But the accounting consequences of the answer are significant, and they fall to the finance function to navigate.

A carbon credit represents a verified reduction in atmospheric carbon — typically one tonne of CO₂ equivalent. When an organisation purchases a carbon credit, it acquires a right. When it retires that credit — marking it as used and removing it from the registry — it extinguishes the right. The retirement is the act with environmental significance; the purchase alone accomplishes nothing material.

For the CFO, the accounting questions are layered:

• Recognition. Is a carbon credit held for future retirement an intangible asset (IAS 38), inventory (IAS 2), or neither? The answer depends on the business model. A company that purchases credits for its own sustainability programme and retires them in the ordinary course of its operations is likely holding inventory. A company that holds credits speculatively, intending to sell them into the secondary market, is holding a financial asset with different measurement and disclosure implications.
• Measurement. If credits are held at cost, the carrying value will diverge from market value as the voluntary carbon market moves. If credits are held at fair value through profit or loss — which may be appropriate for a trading book — the income statement will reflect mark-to-market movements that are unrelated to the company's core business. Neither treatment is obviously right; both require defensible documentation.
• Retirement. When a credit is retired on-chain — permanently and publicly recorded on a blockchain registry — the event is verifiable by any third party with access to the blockchain explorer. The retirement event has a timestamp, a transaction hash, and a verification record that cannot be altered. The audit process for carbon retirement, which historically depended on registry reports and third-party attestation, is simplified. The fact of retirement is self-evident.
• Disclosure. As sustainability reporting requirements tighten — CSRD in the EU, the ISSB climate standard globally — the accounting treatment of carbon credits is no longer merely a finance question. It is a disclosure question, with board-level implications. The CFO who treats carbon accounting as a back-office matter is already behind.

On-chain retirement, specifically, raises a further question: in whose name is the credit retired? At IMPT, retirement occurs in the customer's name, verifiably, on Ethereum. This is not merely a marketing claim; it is an auditable fact. The accounting implication is that the benefit of the retirement accrues to the customer, not to IMPT's own sustainability reporting. The company's carbon disclosure must be structured accordingly.

Section VMiCA and the Regulatory Perimeter

The Markets in Crypto-Assets Regulation — MiCA — entered into force in the European Union in stages through 2024. It represents the first comprehensive regulatory framework for digital assets in a major jurisdiction, and its implications for the finance function of any EU-based company touching crypto assets are substantial.

MiCA establishes, for the first time, a coherent licensing and disclosure regime for issuers of crypto-assets and for crypto-asset service providers. The key categories for a corporate CFO to understand are:

• Asset-referenced tokens (ARTs) and e-money tokens (EMTs). These are the two categories of "stablecoin" that MiCA regulates most heavily. An ART is backed by a basket of assets; an EMT is backed by a single fiat currency. Both require authorisation from a national competent authority. If an organisation is considering issuing, or even distributing, an ART or EMT to customers in the EU, the licensing requirement is unavoidable and the capital requirements are non-trivial.
• Utility tokens. A token that provides access to a service or product — and does not constitute a financial instrument under MiFID II — falls into MiCA's lighter utility token category. Issuers must publish a compliant white paper, notified to and not objected to by the relevant national regulator. The white paper requirements are specific and auditable; the CFO must ensure that the financial disclosures within it are accurate, consistent with other regulatory filings, and reviewed by the same rigour applied to any public disclosure.
• CASP authorisation. Any entity providing custody, exchange, or transfer services for crypto-assets on behalf of third parties in the EU requires authorisation as a crypto-asset service provider. If a company's business model involves holding or transferring tokens for customers — as opposed to merely accepting them as payment — CASP authorisation is likely required. The operational and compliance costs of authorisation are significant and must be built into any business case.

For the CFO, MiCA's most immediate practical consequence is the requirement for rigorous documentation of the token's legal status and the company's activities relative to the regulatory perimeter. The instinct to classify token activities as incidental to the core business — and therefore below the regulatory threshold — is understandable but risky. Regulators in multiple EU member states have demonstrated willingness to take a broad view of what constitutes a crypto-asset service.

MiCA also introduces reserve requirements for ART and EMT issuers that mirror, in structure if not in detail, the reserve requirements applied to banks. The CFO of an entity in scope must understand what assets constitute an eligible reserve, what custody arrangements are required for those reserves, and what disclosure must be made to token holders about the composition and valuation of the reserve. These are not questions for the legal team alone.

Section VIAudit, Proof-of-Reserves, and Verifiability

The audit of a business with material crypto-asset holdings presents challenges that the traditional audit methodology was not designed to address.

• Private key and custody verification. Standard audit confirmation procedures rely on third-party confirmation — a bank confirms a balance, a counterparty confirms a receivable. For crypto assets held in proprietary custody, there is no third-party custodian to confirm. The auditor must instead verify that the entity controls the private key associated with the claimed address, and that the balance visible on the blockchain corresponds to the entity's books. This requires technical procedures — cryptographic signing of a message with the private key — that most audit teams had to develop from scratch.
• Proof-of-reserves. In the exchange and custody space, proof-of-reserves has become a recognised, if imperfect, mechanism for demonstrating solvency. The entity publishes its on-chain addresses, a third party verifies the balances, and a Merkle tree structure allows individual users to verify that their balance is included in the aggregate. For a corporate treasury rather than an exchange, proof-of-reserves is less standard, but the underlying logic — that on-chain balances are verifiable without trusting a third party — is a genuine audit advantage.
• Smart contract risk. If any of the entity's assets or obligations are governed by smart contract logic — staking, liquidity pools, automated settlement — the auditor must assess the risk that the smart contract does not perform as intended. This is a code audit, not a financial audit, and the two disciplines rarely sit in the same engagement letter. The CFO must ensure that smart contract audits are conducted by competent technical reviewers, that findings are documented and remediated, and that the financial audit team understands the economic consequences of the contract logic.
• Disclosure standards. The IAASB and major standard-setters have issued guidance on the audit of crypto-assets, but the guidance is largely principles-based. In practice, audit procedures for crypto-asset holdings vary significantly across firms and engagements. The CFO should expect, and prepare for, detailed discussions with the audit team about what evidence is sufficient and what disclosures are required.

Section VIIStablecoin Treasury

The use of stablecoins as a treasury instrument — holding USDC or USDT rather than bank deposits for part of the working capital position — has moved from speculative to operational for a growing number of companies, particularly those with cross-border payments exposure.

The advantages are genuine: stablecoin settlement is 24/7, crosses borders without correspondent banking friction, and settles in seconds rather than days. For a company with global receivables and payables, the float advantage of faster settlement is a real working capital benefit.

The accounting treatment is, again, not straightforward. USDC, as a regulated e-money instrument backed one-for-one by US dollar deposits and short-duration Treasuries, can be argued to meet the definition of cash or cash equivalent under IAS 7, subject to the entity's specific facts and accounting policy. USDT, whose reserve composition has been a subject of regulatory and audit controversy, presents a more difficult case. The CFO must take a position, document the reasoning, and apply it consistently.

The tax treatment of stablecoin receipts and payments varies by jurisdiction and by the entity's classification of the instrument. In some cases, the acquisition and disposal of a stablecoin — even one pegged to fiat — is a taxable event.

Counterparty risk, often overlooked in stablecoin analysis, is real. A stablecoin is only as good as the issuer's reserve management and regulatory standing. The collapse of TerraUSD in 2022, and the subsequent regulatory scrutiny of the stablecoin sector, demonstrated that assets marketed as stable carry structural risks that do not appear in their name. Treasury policy for stablecoin holdings should specify eligible instruments, concentration limits, and contingency procedures.

Section VIIIA Framework for the Crypto-Era CFO

The finance function is not the last line of defence against bad decisions in digital assets — that is the board's role. But it is the function that must make the consequences of those decisions legible, auditable, and manageable. The following principles orient that work.