Does a wallet balance matching the general ledger prove the books are right?

No. It proves that two systems hold the same quantity. It proves nothing about who beneficially owned the coins, why they moved, which lot was consumed, or what tax basis follows the units into a return, and each of those is a separate conclusion resting on separate evidence.

Do book lots and tax basis have to be kept as separate ledgers?

Yes. Canada pools identical capital-property units into an adjusted cost base, the United States applies specific identification and otherwise earliest-acquired-first within each wallet or account, and UK individuals match same-day acquisitions, then the 30-day rule, then the section 104 pool. None of those is the FIFO convention a subledger may use for book purposes.

Bitcoin Accounting Reconciliation: Records and Controls

Q: Can a UTXO be treated as an accounting lot?

No. Consolidate BTC bought in two purchases months apart at different prices into one new output, and the chain shows one output with one creation date while the ledger still needs two lots, two dates and two costs. UTXO selection must not become the book-lot or tax-lot method by default.

Q: How should a Bitcoin network fee be recomputed at the close?

A Bitcoin transaction contains no fee field, so the fee is total input value less total output value. A node does the arithmetic at verbosity 2, but omits the fee and spent-output detail when block undo data is unavailable, so for material transactions that subtraction is the fallback.

Q: Why does a chain-only reconciliation miss economic events?

Because the public chain is incomplete. A pool reward accrues on a private ledger before payout, a custodian trades internally without touching the chain, Lightning settles off-chain through cross-signed commitment transactions, and a borrower defaults without a satoshi moving.

A Bitcoin accounting reconciliation can tie out to the satoshi and still be wrong. When a wallet balance agrees with the general ledger, one thing has been proved: two systems hold the same quantity. Nothing has yet been proved about who beneficially owned the coins, why they moved, or which lot was consumed.

Nor has anything been proved about what tax basis follows the units into a return. The chain is genuinely good evidence and should be used. For a confirmed transaction it shows the outputs consumed and created and the block it sits in; at verbosity 2, where block undo data is available, it adds the derived fee and the value of each output spent, and with the block hash supplied explicitly Bitcoin Core reports whether that block is on the active chain, the evidence a period-end reorganisation check needs (Bitcoin Core, getrawtransaction). What it cannot supply is business context: purpose, counterparty, contract terms, ownership, functional-currency value or accounting classification.

It is also incomplete: a pool reward accrues on a private ledger before payout, a custodian trades internally without touching the chain, Lightning settles off-chain, and a borrower defaults without a satoshi moving.

Five records that must agree before you can close

Each layer holds something the layer beside it does not. Reconciliation is the control, not the chain.

On-chain recordsConfirmed transactions, outputs and fees. Public and verifiable.
Wallet and custodian recordsWhich addresses and outputs belong to the entity.
Crypto subledgerLots, basis, holding periods and the valuation policy applied.
General ledgerRecognised amounts in the functional currency.
Financial statementsPresentation, disclosure and the judgements behind them.

A chain-only reconciliation can tie out perfectly and still be wrong, because it never sees the economic events that never touched the chain.

Scope. Records, controls and reconciliation for a Bitcoin close under IFRS or US GAAP, with pointers to the jurisdiction-specific tax articles in the series. It is educational research, not accounting, tax, legal, valuation or investment advice.

Everything below assumes the bookings themselves are already settled. Our crypto accounting guide covers the wider workflow, how to account for Bitcoin transactions covers the event-by-event entries, and a full worked year of Bitcoin journal entries puts them in sequence. A Bitcoin accounting reconciliation asks a later question: whether what those entries assert is still supportable at the reporting date, on evidence a reviewer can reach without taking a preparer's word for it.

The five layers a Bitcoin close has to reconcile

The layers in the figure run in one direction, and each holds something the next does not. On-chain records show confirmed transactions, outputs and derived fees; wallet and custodian records say which of those belong to this entity, which the network never publishes; the crypto subledger holds lots, basis, holding periods and the valuation policy applied; the general ledger holds recognised functional-currency amounts; the financial statements hold presentation, disclosure and the judgements behind them.

Two further ledgers run alongside all five rather than inside any one: rights and control evidence (custody terms, segregation, reuse rights, pledges, insolvency provisions), which decides what asset the entity has, and tax history, which decides how units are identified in a return.

Control failures begin when one layer is silently substituted for another: a block explorer used as the subledger, an exchange statement as proof of ownership, a tax lot inferred from whichever output the wallet spent. Each substitution destroys a different assertion.

The minimum transaction-level record

A reviewer working only from the file should be able to answer four questions about a material Bitcoin event: what happened, what proves it, how much BTC changed economically, and how the functional-currency amount was calculated.

Group	Fields to retain
Identification	Asset and network (native BTC, or a wrapped, bridged or custodial representation); transaction ID; input and output UTXOs; wallet or descriptor
Quantity and timing	Quantity before and after; acquisition, disposal and fee quantity; derived network fee; block and confirmation status; protocol and accounting recognition timestamps where they differ; timezone
Purpose	Counterparty; economic purpose; self-transfer flag; change-output classification; fee purpose and allocation
Measurement	Functional-currency price; price source and valuation timestamp; functional-currency amount
Rights and links	Ownership and control conclusion; custody status (self-custody, segregated custody property or a claim); accounting-lot and tax-lot references; linked private-ledger event; supporting document

Tax authorities ask for a similar list: the Canada Revenue Agency's crypto-asset records guidance calls for units and asset type, date and time, Canadian-dollar value, transaction nature and counterparty, wallet addresses, annual opening and closing balances and exchange ledgers, generally kept for at least six years from the end of the relevant taxation year (CRA).

UTXOs are evidence, not accounting lots

Bitcoin maintains no account balances. It maintains unspent transaction outputs, or UTXOs: discrete chunks of BTC, each locked to a spending condition. A wallet balance is only the sum of the UTXOs the software believes it can spend. In Bitcoin's developer guide, a displayed 10,000 satoshi balance "really means that you have 10,000 satoshis waiting in one or more UTXOs." A UTXO is spent only once and in full, so the whole input value must be paid out or given to the miner as the fee, and most transactions include a change output returning the surplus to the spender (Bitcoin developer guide).

Hence the trap. Consolidate 0.4 BTC bought in two purchases months apart at different prices into one new UTXO, and the chain shows one output with one creation date while the ledger still needs two lots, two dates and two costs. The opposite happens as often, one lot split across several outputs.

UTXO selection must not become the book-lot or tax-lot method by default.

The subledger therefore needs a lot history that survives consolidations, splits, address rotation and change. No reporting or tax framework identifies units the way a coin-selection algorithm does.

Control 1: prove the quantity the entity actually controls

Start with quantity, before valuation: a precisely valued wrong quantity is still wrong.

For self-custody, reconstruct the outputs the entity concludes it controls from wallet exports, output descriptors, raw transaction data and node or explorer output. The chain cannot do this for you: it publishes addresses and amounts, but whether an address belongs to your wallet is local information held by the wallet. Bitcoin Core notes that some of what getaddressinfo returns "will only be present if the address is in the active wallet" (Bitcoin Core, getaddressinfo). An address list, a descriptor and evidence of the signing arrangement are part of the evidence package, and so is evidence that the entity actually controls the keys: a message signed from a sampled address, a controlled test spend, or equivalent. A descriptor proves what the addresses are, not that anyone can sign for them.

Then work the exceptions: outputs in a portfolio tool but not in the controlled set, spent outputs still carried as assets, unknown addresses, wallets omitted from the close, watch-only addresses the entity can observe but not spend, and multisignature arrangements where control depends on an outside party. A balance screenshot shows a number without showing who can sign or which network is involved.

Control 2: match internal transfers before classifying disposals

A transfer between an entity's own wallets changes location, not beneficial ownership. On-chain it looks like an outgoing payment followed by new outputs, and a naive import books it as a disposal and a fresh acquisition.

A robust importer identifies own-wallet destinations, change outputs, consolidations, splits and cold-storage movements before anything is classified as a sale. Where the movement is internal, the record carries basis and acquisition date forward unchanged, and only the fee (or another quantity that economically leaves the entity) is removed. A system that gets this wrong manufactures hundreds of false acquisitions and disposals out of housekeeping, then values every one.

Control 3: recompute network fees

A Bitcoin transaction contains no fee field. The fee is whatever the sender left on the table:

total input value - total output value = network fee

For material transactions, recompute it from the raw transaction rather than accepting a third-party tool's figure. A node does the arithmetic at verbosity 2, but omits the fee and spent-output detail when block undo data is unavailable, so the subtraction above is the fallback (Bitcoin Core, getrawtransaction).

Then ask what the fee enabled, because one fee can relate to an internal transfer, an acquisition, a disposal, the settlement of a liability or an operating payment, and treatment follows that purpose and the applicable framework. A fee should not be swept into a generic "crypto fees" line when part of it is directly attributable to acquiring or disposing of an asset. Individually small and cumulatively large, fees deserve a documented allocation policy.

Control 4: reconcile the private ledgers

The public chain is incomplete for most significant Bitcoin arrangements, so private ledgers must be reconciled in their own right.

Exchanges and custodians. Retain the trade history, deposit and withdrawal ledgers, internal transfers, statements and balances, and the legal terms: custody agreement, segregation, rights of reuse or rehypothecation, transfer restrictions and insolvency provisions. A balance labelled "BTC" can mean native BTC beneficially owned by the customer, or a claim against the intermediary denominated in BTC; the statement quantity cannot decide which, and the answer changes the asset recognised.

Mining pools. Retain the pool agreement, payout method, share and reward exports, gross reward, operator fee, unpaid balance, payout threshold and payout transaction. A pool's economics live on its private ledger, not on the chain: Braiins Pool charges a 2.5 per cent fee, pays out once daily at 09:00 UTC and lets each account set its own withdrawal threshold (Braiins Academy). Reconcile accrual to payout, not payout to wallet, and for solo mining keep the block subsidy separate from transaction fees.

Lightning. A channel's balance sits in a cross-signed commitment transaction updated off-chain on every payment, and reaches the base chain only when the channel ends: by mutual close, by unilateral close publishing the latest commitment transaction, or by a revoked-transaction close (Lightning BOLT #5). A chain-only ledger sees the funding transaction and the close and nothing between, hiding the operating history of a payments business. Retain channel and node records (per-channel opening and closing balances, routing-fee records, forwarding and invoice history) sufficient to reconstruct off-chain receipts and payments. A Lightning node issues no statement, so this is the evidence, and it is what the reconciliation ties to.

Control 5: prove rights and beneficial ownership

Quantity is not ownership. For each material custodial, lending, collateral or escrow position, document who controls the keys, whether coins are segregated, whether the intermediary may reuse them, what happens in insolvency, and whether the entity can recall the BTC. That analysis can change the accounting asset without changing a number on the screen: a 10 BTC balance could be BTC held outright, a receivable, borrowed BTC with a return obligation, restricted collateral, or a frozen claim in an insolvency. Five different balance sheets.

Control 6: keep accounting lots independent of the chain

For each financial-reporting lot, preserve the acquisition date, quantity, functional-currency basis, source transaction, valuation evidence, subsequent disposals, any impairment or revaluation history, and the remaining quantity. When UTXOs are split, consolidated or recreated as change, that history continues untouched.

That holds even under US GAAP's ASC 350-60, where in-scope crypto assets are carried at fair value through net income, because the disclosures still run on cost. At interim and annual reporting periods an entity discloses name, cost basis, fair value and units for each significant crypto-asset holding, aggregated amounts for the rest, and annually the cost-basis method used (FASB ASU 2023-08, ASC 350-60-50-1 and 50-2). The annual roll-forward from opening to closing balances is required in the aggregate, not one reconciliation per crypto asset; only the gains and losses lines inside it are determined crypto-asset by crypto-asset (ASC 350-60-50-3). ASC 350-60-50-4(b) adds cumulative realised gains and losses from disposals in the period: disposal price less cost basis, the Board explained, not movement since the last balance sheet date (ASU 2023-08, BC67). Stop tracking cost and none of it can be produced.

Under IFRS the same discipline supports classification: holdings of cryptocurrencies fall under IAS 2 where held for sale in the ordinary course of business and under IAS 38 otherwise, a distinction turning on the entity's purpose rather than on anything visible on-chain (IFRS Interpretations Committee, June 2019). Lot records also carry the impairment evidence under the IAS 38 cost model, and one scoping decision must be documented when made: recoverable amount is determined for an individual asset unless it does not generate cash inflows largely independent of those from other assets or groups of assets, in which case it is determined for the cash-generating unit, or CGU, to which the asset belongs, unless fair value less costs of disposal is higher than carrying amount, or value in use can be estimated to be close to fair value less costs of disposal and that amount can be measured (IAS 36.22).

Control 7: keep tax history independent of both

Tax identification rules differ from financial-reporting lot methods, and from each other. In Canada, identical capital-property units use a pooled adjusted cost base, described by the CRA as usually the weighted average cost of the crypto-asset (CRA). In the United States, Treas. Reg. §1.1012-1(j) applies specific identification, and where none is made defaults to earliest-acquired-first within each wallet or account (the date units were transferred in is disregarded), for digital-asset sales, dispositions and transfers on or after 1 January 2025, so a universal cross-wallet pool is no longer available (Treas. Reg. §1.1012-1(j)). For UK individuals, capital-gains matching applies same-day acquisitions first, then the 30-day rule, then the section 104 pool (HMRC, CRYPTO22200).

None of those is "whatever UTXO the wallet spent," and none is the FIFO convention a subledger may use for book purposes. Keep book lots and tax basis as independent ledgers, reconciled to the same quantity and no further; making one serve both is the commonest and costliest design error.

Third-party reporting now tells the authority much of this before the return arrives, making the client's own records a reconciliation target. US Form 1099-DA reports broker digital-asset dispositions: gross proceeds generally from 2025 sales (IRS 2025 instructions), and basis for covered digital assets from 2026, so BTC acquired before 2026 or transferred into a broker can be noncovered even when the sale is reported (IRS 2026 instructions). The UK's Cryptoasset Reporting Framework, or CARF, began on 1 January 2026 under SI 2025/744 and was widened by Finance Act 2026 (c. 11) s. 275, in force 18 March 2026, which applies the regulation 6 reporting duty and regulation 8 notification duty to "cryptoasset users resident in the United Kingdom, or who have controlling persons that are resident in the United Kingdom." The first reportable period, calendar 2026, sits entirely inside that duty, so UK CARF is not cross-border only, and the HMRC page, last updated 1 January 2026, does not reflect section 275 (HMRC). In the EU, DAC8 (the eighth amendment to the Directive on Administrative Cooperation) applies from 1 January 2026 (European Commission).

Control 8: make valuation reproducible

For every material valuation, retain the venue, product, price field, exact timestamp and timezone, the raw response or a reproducible reference, the retrieval date, the principal-market conclusion and the documented fallback. Both frameworks start from the market rather than the feed. Fair value is measured in the principal market (the one with the greatest volume and level of activity for the asset that the entity can access) or, in its absence, the most advantageous market (IFRS 13); ASC 820 states the same objective for US GAAP.

A spreadsheet cell showing $87,497.94 is not a valuation file; the evidence must let another reviewer reproduce why that number was used for that event. Fallbacks must be defined before an outage, because one written afterwards is indistinguishable from choosing the source that produces the preferred answer.

The period-end Bitcoin close, in order

A practical close runs in this sequence, because later steps depend on earlier conclusions:

prove controlled self-custody quantity;
reconcile exchange, custodian, pool and Lightning balances to statements;
identify internal transfers, change, consolidations and splits;
recompute material network fees;
reconcile UTXOs to accounting lots;
review confirmations, unconfirmed (mempool) items and reorganisations near cutoff, recording business-recognition time separately from block time: a transaction broadcast before the reporting date but unconfirmed at it has no block time at all and must be concluded on separately;
reconcile mining accruals, pool fees, unpaid balances and payouts;
reassess custody and title: segregation, reuse rights, freezes, insolvency;
review lent, borrowed, pledged, escrowed and multisignature BTC, gross unless offset criteria are met;
investigate lost keys, theft, inaccessible wallets, failed custodians, borrower defaults, and insurance or legal recovery rights;
apply the documented valuation policy;
book the IFRS or US GAAP closing measurement;
reconcile book and tax basis separately;
assess current and deferred tax;
review presentation, restrictions, cash flows and disclosures; and
freeze the evidence package.

Steps 1 to 5 come first because measuring the wrong quantity more precisely does not improve the close. One exception runs backwards: an unconfirmed item or a reorganisation identified at step 6 sends the close back to steps 1 to 5, because both change the quantity those steps have already settled. Wallet software excludes an output with a pending spend from the spendable set, so a quantity proved at step 1 may already have removed BTC that had not confirmed at the cutoff. Confirmation status belongs at step 6: each further confirmation makes reversal less likely without making it impossible, so a cutoff conclusion is a judgement about reorganisation risk, not a protocol certainty.

Step 15 carries two IFRS points. The gain or loss on derecognising an IAS 38 intangible goes to profit or loss, and paragraph 113 restricts only the gain ("Gains shall not be classified as revenue"), so a disposal gain does not belong on the revenue line even for a mining business (IAS 38.112-113). And IFRS 18 replaces IAS 1 for annual reporting periods beginning on or after 1 January 2027, earlier application permitted, and moves paragraphs from IAS 1 into IAS 8, retitled Basis of Preparation of Financial Statements; it also moves the indirect-method cash flow starting point from profit or loss to the new operating profit subtotal (IFRS Accounting Taxonomy 2024 Update 1). Because it applies retrospectively, a calendar-year entity restates its FY2026 comparatives on first application. BTC measurement does not change, but the FY2026 subledger must survive in a shape those comparatives can be rebuilt from.

When a Bitcoin accounting reconciliation breaks, and what a clean one proves

Classify the failure before adjusting the ledger. Each failure mode in a Bitcoin accounting reconciliation points somewhere different. A wrong wallet quantity points to missing wallets, spent UTXOs, change and fees; wrong lots on a right quantity point to self-transfers, lot continuity and imported change; a wrong economic position on right lots points to custodians, lending, pools and Lightning; a wrong carrying value points to the framework, principal-market policy and price source; a wrong tax result points to taxpayer classification, tax basis and the matching rules. Each layer inherits the errors of the one below.

A successful close therefore does not end at wallet BTC = accounting BTC. It establishes four conclusions, each on its own evidence: quantity is correct; rights are correctly identified; carrying value is supportable; tax history is independently supportable. A confirmed transaction supports the first and very little else, and that boundary belongs in the written control framework, not in a preparer's head. When all four hold, a reviewer can follow every assertion back to something that is not a screenshot. The technology is unusual. The control objective is not.

Sources and further reading

Every URL below is also attached inline to the sentence it supports.

Bitcoin Core, getrawtransaction: raw transaction detail; fee and prevout values at verbosity 2 where block undo data exists; in_active_chain only when a block hash is supplied.
Bitcoin Core, getaddressinfo: the boundary between public-chain data and local wallet ownership information.
Bitcoin developer guide, Transactions: UTXOs, change outputs and the fee as the unspent remainder.
Lightning BOLT #5, Recommendations for On-chain Transaction Handling: commitment transactions and the three ways a channel closes.
Braiins Academy, Rewards & Payouts: one published pool's fee, payout schedule and withdrawal threshold.
CRA, Keeping books and records of crypto-assets for tax filing
CRA, Reporting your capital gains as a crypto-asset user
Treas. Reg. §1.1012-1: paragraph (j), wallet-by-wallet and account-by-account identification.
IRS, 2025 Instructions for Form 1099-DA
IRS, 2026 Instructions for Form 1099-DA
HMRC, Cryptoassets Manual CRYPTO22200: pooling
SI 2025/744, Reporting Cryptoasset Service Providers (Due Diligence and Reporting Requirements) Regulations 2025: as modified by Finance Act 2026 s. 275.
Finance Act 2026 (c. 11) section 275: extends the CARF reporting and notification duties to UK-resident users and users with UK-resident controlling persons.
HMRC, Check if you'll need to report cryptoasset data to HMRC: last updated 1 January 2026; predates Finance Act 2026 s. 275 and does not reflect it.
European Commission, DAC8
FASB ASU 2023-08 (ASC 350-60): disclosure paragraphs 50-1 to 50-4 and Basis for Conclusions BC67.
IFRS Interpretations Committee, Holdings of Cryptocurrencies (June 2019)
IAS 36 Impairment of Assets: paragraph 22, individual asset versus cash-generating unit.
IAS 38 Intangible Assets: paragraphs 112-113, derecognition and the gains-not-revenue restriction.
IFRS 13 Fair Value Measurement
IFRS 18 Presentation and Disclosure in Financial Statements
IFRS Accounting Taxonomy 2024 - Update 1, IFRS 18

Educational research, not accounting, tax, legal, valuation or investment advice. Treatment depends on the entity type, jurisdiction, facts and current law.