Where is the Bitcoin network fee stored?

Nowhere. For an ordinary transaction it is derived as total inputs minus total outputs, and there is no separate universal fee field inside the transaction, which is how the Bitcoin Developer Guide describes it under Transactions.

Does paying a network fee dispose of BTC?

Yes. The fee units leave the entity out of an existing accounting lot, so the entity recognises both the classified fee cost and any gain or loss on those units. For US federal tax, the IRS treats digital assets used or withheld to pay transaction fees as a disposition. Relief for the cost is a separate question: where the fee only effects a transfer between wallets the same entity controls, the IRS treats the amount paid as not a digital asset transaction cost, so it neither adds to basis nor reduces amount realised (FAQ 53).

How many confirmations are required for accounting recognition?

Bitcoin prescribes none. Confirmations evidence active-chain acceptance and reversal risk, and finality is probabilistic rather than absolute, so recognition depends on the applicable framework and the transaction facts.

Bitcoin for Accountants: The Technical Concepts You Actually Need

Bitcoin for accountants comes down to a handful of protocol facts, and most engagements go wrong in the import step. A wallet export arrives, it looks near enough to a bank statement to be treated like one, and an hour later the general ledger holds a sale that never happened and a cost that has vanished.

A movement between two wallets the same entity owns is imported as a disposal; a change output is booked as income; the network fee disappears, because Bitcoin stores no line item for it; a mining-pool payout is recorded as revenue although the revenue arose earlier, in the pool's private ledger.

None of that is bad accounting judgement. It is four or five protocol facts nobody thought to explain, too obvious for a Bitcoin engineer to mention, invisible to an accountant reading a spreadsheet of transaction hashes. So this guide to Bitcoin for accountants is deliberately narrow: what the unit is, where the fee hides, what a confirmation proves, and which economically significant events never touch the chain.

Scope. Native BTC on the Bitcoin mainnet, the live production network on which real BTC moves, as distinct from developers' test networks. Wrapped BTC, exchange-traded funds, futures and exchange-issued claims may use the word “Bitcoin” while creating a different asset; they are outside this article.

What one Bitcoin transaction actually does

A transfer to cold storage, seen the way the protocol records it and the way the ledger must record it.

Inputs are spent in fullTwo UTXOs totalling 0.42907543 BTC are consumed. A UTXO cannot be partly spent.
Outputs are created0.40000000 BTC to cold storage, 0.02904401 BTC returned to the entity as change.
The fee is not a fieldInputs minus outputs = 0.00003142 BTC. Bitcoin stores no separate fee amount.
The accounting viewNo sale occurred: 0.42904401 BTC is still controlled. Only the fee units left the entity.

Change is not income and a self-transfer is not a disposal, but the fee units are disposed of, so basis is relieved and a gain or loss arises on them.

Bitcoin for accountants: the unit, and what native BTC is not

Bitcoin is a digital asset recorded on its own network, and its unit is bitcoin, written BTC. Native BTC means the asset on that network itself rather than something that merely references it. The design goal was narrow: let one party send digital value to another without a financial institution in the middle to stop the same value being spent twice (Bitcoin white paper). The accounting consequence is immediate. Native BTC has no corporate issuer promising redemption, no reserve behind one BTC, and no protocol rule that pays interest because the holder waits. Nor does it accrue: nothing rewrites a holder's quantity over time.

One BTC is divisible into 100,000,000 satoshis; Bitcoin Core's consensus code defines the constant exactly that way, as inline constexpr CAmount COIN{100'000'000} (Bitcoin Core, amount.h). Preserve that precision: 0.00000001 BTC is one satoshi, not a rounding residue for a suspense account. Market value can move violently while the number of satoshis stays exactly the same, so separate two ideas immediately: protocol quantity, how much BTC is controlled, and functional-currency value, what it is worth for the accounting event or reporting date.

A wallet holds keys, not coins

The word wallet sets the first conceptual trap. A Bitcoin wallet is software or hardware that creates and protects cryptographic keys and uses them to sign transactions. The Bitcoin Developer Guide puts it plainly: wallet programs “create public keys to receive satoshis and use the corresponding private keys to spend those satoshis” (Bitcoin Developer Guide, Wallets). Nothing is deposited into it. It holds private keys, the secrets that sign a spend without being revealed; addresses, each a destination carrying spending conditions; and descriptors, compact machine-readable statements of the rules by which a wallet derives its addresses, which is what lets an accountant tie an output to a wallet.

That decides what your audit evidence is worth. Seeing an address on a public block explorer, a website presenting chain data in readable form, does not prove who legally owns it. Bitcoin Core's own remote procedure call (RPC) interface makes the point from the other side: getaddressinfo warns that “some of the information will only be present if the address is in the active wallet” (Bitcoin Core RPC, getaddressinfo). The chain knows the spending conditions; only the holder's own records connect them to the entity.

Bitcoin has no account balances, only UTXOs

A bank ledger shows a named balance, Cash: $42,000, and reduces it when money is paid. Bitcoin has no such row. It tracks discrete pieces of spendable value called unspent transaction outputs, or UTXOs, each created by an earlier transaction. A wallet displays one total, but underneath it sit separate outputs, and an output is always spent whole. A normal transaction therefore consumes one or more existing UTXOs as inputs, creates one or more new UTXOs as outputs, and leaves the difference between total inputs and total outputs as the network fee (Bitcoin Developer Guide, Transactions).

A self-transfer, worked

An entity controls two UTXOs, of 0.38174625 BTC and 0.04732918 BTC: 0.42907543 BTC in all. It moves 0.40000000 BTC to a new cold-storage address it also controls (cold storage means the spending keys are kept offline in ordinary use). Neither output is large enough alone and neither can be partly spent, so both are consumed in full:

inputs                                             0.42907543 BTC

cold-storage output                                0.40000000 BTC
change back to the entity                          0.02904401 BTC
                                                     ----------
total outputs                                      0.42904401 BTC

network fee                                        0.00003142 BTC
                                                     ----------
total outputs + fee                                0.42907543 BTC

The blockchain sees two old outputs spent and two new outputs created. The accounting event is much smaller and stranger:

0.42904401 BTC remains the entity's property;
there is no sale of the 0.40000000 BTC, and the new outputs do not create new acquisition dates;
the 0.02904401 BTC change is not revenue: it is the entity's own value returning to it under a new output;
the 0.00003142 BTC fee is a disposal. Those units leave the entity permanently, and they leave out of an existing accounting lot;
so the transfer produces one derecognition event rather than none, and its size is 0.00003142 BTC, not 0.42907543 BTC.

Importers get that last pair wrong in both directions: they book the big number that did not move and miss the small number that did.

A UTXO is not an accounting lot

A UTXO answers which pieces of Bitcoin value a wallet can spend next; an accounting lot answers when particular units were acquired, through what event, and at what basis or carrying history. The boundaries need not match, and after ordinary activity they usually do not: combine one purchased UTXO with one mined UTXO and send change back to the wallet, and that change output carries history from more than one lot. Nothing in the protocol tags a satoshi with a cost basis.

UTXO selection is not an accounting-lot method.

A wallet choosing which outputs to spend is constructing a transaction: its objective is to assemble enough input value at an acceptable fee. That is not a financial-reporting objective: it selects neither first-in, first-out (FIFO), nor specific identification, nor weighted-average tax basis, nor anything else your lot policy requires.

Change carries the same warning: because inputs are consumed whole, most payments need a change output, since “few people will have UTXOs that exactly match the amount they want to pay” (Bitcoin Developer Guide, Transactions), and to a naive importer that looks like an incoming receipt from an unfamiliar address, though nothing was earned. Establish wallet ownership and identify change before classifying transactions, not after.

Network fees are hidden in arithmetic

Many accounting systems expect a fee field. Bitcoin transactions have none: for an ordinary transaction the fee is derived as total input value minus total output value, because the full value of the inputs must either be spent or given to the miner as a fee (Bitcoin Developer Guide, Transactions). In the self-transfer above, 0.42907543 − 0.42904401 = 0.00003142 BTC; a system that sums only the explicit outputs never sees it.

Two consequences follow, and the second routinely gets dropped. First, the fee is a real BTC outflow whose functional-currency amount needs a classification: an expense, part of the cost of an acquired asset, a selling cost or another appropriate classification, depending on the transaction. Second, the fee units are themselves disposed of: they come out of an accounting lot and stop being the entity's asset.

Under IFRS, where the holding is an IAS 38 intangible rather than IAS 2 inventory (“if IAS 2 is not applicable, an entity applies IAS 38 to holdings of cryptocurrencies”, IFRIC, Holdings of Cryptocurrencies), paying the fee derecognises part of the BTC holding. Under IAS 38.113 the gain or loss is the difference between the net disposal proceeds and the carrying amount derecognised, it goes to profit or loss, and a gain shall not be classified as revenue (IAS 38). Treating the transaction-date value of the fee units as those proceeds is the ordinary reading, but label it interpretation: no IFRS paragraph names a Bitcoin network fee.

Under US GAAP the route differs and the outcome is the same in kind. For an entity whose BTC meets the scope criteria of ASC 350-60-15-1, derecognition still falls outside that Subtopic: ASC 350-60-05-2 states that it “does not address the initial measurement, recognition, and derecognition of crypto assets” (FASB ASU 2023-08). Disposal therefore follows ASC 350-10-40-1, which routes a nonfinancial asset to Subtopic 610-20, or to Topic 606 where the disposal is a contract with a customer (FASB Codification).

So one fee of 0.00003142 BTC produces two amounts, not one: the classified cost, and the gain or loss on the units used to pay it. Tax asks a third question, and the answers diverge by jurisdiction. For US federal tax the IRS treats digital assets used or withheld to pay transaction fees as a disposition (IRS FAQs on digital-asset transactions), while for UK capital gains HMRC treats a qualifying fee paid to have a transaction included on the ledger as an allowable acquisition or disposal cost (HMRC CRYPTO22150) and, where the fee is satisfied in tokens, also as “a disposal in its own right” at market value under TCGA92/S17(1)(b) (HMRC CRYPTO22280). The IRS answer has a second half that decides the self-transfer above: where a fee merely effects a transfer between wallets the same entity controls, rather than a purchase, sale or disposition, the amount paid is expressly not a digital asset transaction cost, so it neither adds to basis nor reduces amount realised (FAQ 53). But the mechanical point comes first: the fee quantity must be identified separately from the retained BTC, because neither consequence can be computed until it is.

Confirmations, reorganisations and block time

A signed transaction is broadcast to the peer-to-peer network, where each node, a computer that independently validates transactions and blocks against the network's rules, holds it in its mempool, the pool of valid transactions not yet in a block. When miners include it in a block on the active chain, the transaction has one confirmation, and every later block adds another. A confirmation is evidence that a transaction was accepted into the active chain, and a node can be asked whether the block containing it is still there (Bitcoin Core RPC, getrawtransaction). By itself it does not prove who legally owned the BTC, when a customer accepted delivery, which invoice was settled or the tax recognition date. Those are facts that live outside the protocol, in records it has never seen.

Nor is “confirmed” absolute. Nodes follow the valid chain with the most accumulated proof of work, so when a competing branch becomes the most-work chain a previously accepted block is displaced (a blockchain reorganisation, Bitcoin Developer Guide, Block chain), and its transaction may be mined again later, return to the mempool, or conflict with a competing spend that won instead. Bitcoin finality is probabilistic, not absolute: confirmations make reversal progressively more expensive rather than switching a transaction from reversible to irreversible, so material transactions near cutoff should be re-checked against a node or explorer before the number is used. A reorganisation is also not a permanent hard fork, where the chain splits into two networks and holders end up controlling units on each.

Block times deserve the same scepticism. A block's timestamp is supplied by the miner, “a Unix epoch time when the miner started hashing the header (according to the miner)” (Bitcoin Developer Reference, Block chain), and the protocol requires only that it be later than the median timestamp of the preceding eleven blocks and no more than two hours ahead of network-adjusted time. Those bounds are asymmetric: the timestamp can run no more than about two hours ahead of network-adjusted time, but backwards it is constrained only by the median of the preceding eleven blocks, so it may lag real time by considerably more. That is technical evidence with an asymmetric tolerance, not a business timestamp: recognition may instead turn on contract acceptance, delivery, control or settlement terms, so a robust record carries both a protocol timestamp and an accounting recognition timestamp.

Mining, and what the coinbase transaction really is

Bitcoin has no corporate issuer creating new coins by journal entry; new BTC enters circulation through mining. Miners assemble valid transactions into candidate blocks and repeatedly perform a proof-of-work calculation, varying data in the block header and computing a hash, a fixed-length digital fingerprint of the input data, until one falls below the network's current target. A hash is unpredictable, so the only way to find one is to keep trying: hard to produce, trivial for any other node to verify (Bitcoin Developer Guide, Mining).

Two details here are routinely stated wrongly, and both matter for evidence. Every valid block must begin with a special first transaction called the coinbase transaction, unrelated to the company Coinbase, which should collect and spend the block reward (Bitcoin Developer Guide, Block chain); it is not an optional extra the winner may add afterwards. And it is built into the candidate block before the search begins, because the mining software “converts all the transactions into a merkle tree to derive a merkle root it can use in a block header” (Bitcoin Developer Guide, Mining), and that header is what the hardware hashes. The reward destination is committed before anyone knows whether the search will succeed.

The coinbase transaction carries two economically different components that behave nothing alike: the protocol-defined block subsidy, which halves on a fixed schedule every 210,000 blocks (Bitcoin Core, subsidy implementation), and the transaction fees paid by every other transaction in that block, which depend entirely on user demand. At block 840,000 (deliberately an extreme case, being both a halving block and unusually fee-heavy) the subsidy was 3.125 BTC and transaction fees were 37.62561499 BTC (mempool.space, Blockstream). One line called “mining reward” destroys information the accounting analysis needs.

A coinbase output also carries a spending restriction: it “cannot be spent (used as an input) for at least 100 blocks” (Bitcoin Developer Guide, Block chain). That coinbase maturity rule is not an accounting-recognition date. The question is when the asset and income criteria are satisfied under the applicable model; confirmations, maturity and payout answer three different questions, and are not three elective dates.

Solo mining and pool mining leave different records

A solo miner that wins a block receives the subsidy and that block's transaction fees through the coinbase transaction. Most commercial mining instead runs through a mining pool, which coordinates many miners and measures each participant's contribution with easier proofs called shares: “the information the miner sends to the pool is called a share because it proves the miner did a share of the work” (Bitcoin Developer Guide, Mining). Those shares are private pool records, not Bitcoin transactions, and appear nowhere on the chain.

The pool's payout method converts shares into an entitlement, and it decides when an amount becomes estimable: pay per share (PPS) pays a fixed amount per accepted share whether or not a block is found, full pay per share (FPPS) adds an estimated share of transaction fees, and a success-based method pays only out of blocks the pool wins, so the first two can often be estimated before any block succeeds and the third usually cannot. In a conventional custodial pool the operator accrues the reward on its own ledger, deducts a fee and pays out later. One pool describes a “Financial Account” as “a place where your mining rewards are stored once confirmed” (Braiins Pool documentation): a private balance, not a Bitcoin balance.

The earning event can therefore appear in the pool's private ledger before the payout appears on-chain, so a later wallet receipt may settle a receivable rather than being a second revenue event. Booking both as income duplicates revenue.

Lightning: the on-chain legs do not label themselves

The Lightning Network lets two parties make many BTC-denominated payments without recording each one on the blockchain. They open a channel by locking BTC into a single on-chain output both control, then pay each other repeatedly by exchanging cross-signed commitment transactions describing the channel's current state (Lightning BOLT 5). Those updates are off-chain, so no Bitcoin transaction occurs, and a closing transaction later settles the final split on-chain.

The tempting summary is that the chain shows funding, then nothing, then settlement. It is wrong in a way that will cost you, because the on-chain legs are not annotated: an opening looks like an ordinary payment to a stranger, a close looks like an ordinary incoming receipt, neither says “Lightning,” and an importer will classify them as a disposal and an acquisition unless something outside the chain says otherwise. A channel can also be resized on-chain by splicing, which the Lightning specification defines as “replacing the funding transaction with a new one” (Lightning BOLT 2, channel splicing), so an unexplained on-chain transfer touching a channel is not necessarily an open or a close at all. Only the node's own channel records identify what happened between the visible transactions, including the intermediate payments and any routing fees earned for forwarding other people's payments.

That is not a niche technical detail. It proves a broader rule:

A complete Bitcoin accounting ledger cannot be reconstructed from public blockchain data alone.

The minimum Bitcoin data model

The chain proves protocol facts: the transaction identifier, the inputs consumed and outputs created, the amounts, the block placement, and the confirmation and active-chain status (Bitcoin Core RPC, getrawtransaction). It contains no owner's name, invoice, statement of purpose, functional-currency valuation or lot history. A subledger therefore has to keep these concepts separate rather than collapse them into one field called “wallet transaction”:

Concept	What it answers
Address / descriptor	Which wallet rules are associated with a destination?
UTXO	Which protocol output is currently spendable?
Transaction	Which inputs were consumed and outputs created?
Network fee	How much BTC actually left as transaction cost?
Accounting lot	What acquisition history belongs to the recognised BTC quantity?
Functional-currency value	What amount is recorded in the general ledger?
Business evidence	Why did the economic event occur?

The first four rows are protocol facts; the last three are not, and almost every error at the top of this article is a protocol fact read as an accounting conclusion. That division is what Bitcoin for accountants finally comes down to: the chain settles the first four rows, and the entity's own records have to settle the last three. Our crypto accounting guide covers the wider close workflow those records sit in.

Sources and further reading

Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System
Bitcoin Core source, amount.h
Bitcoin Core source, consensus.h
Bitcoin Core, block subsidy implementation
Bitcoin Developer Guide, Transactions
Bitcoin Developer Guide, Wallets
Bitcoin Developer Guide, Block chain
Bitcoin Developer Guide, Mining
Bitcoin Developer Reference, Block chain
Bitcoin Core 31.0 RPC, getrawtransaction
Bitcoin Core 31.0 RPC, getaddressinfo
Bitcoin block 840,000 on mempool.space and on Blockstream
Braiins Pool, rewards and payouts
Lightning BOLT #5, on-chain handling
Lightning BOLT #2, channel splicing
IFRS Interpretations Committee, Holdings of Cryptocurrencies, June 2019
IAS 38, Intangible Assets
FASB ASU 2023-08, Accounting for and Disclosure of Crypto Assets (ASC 350-60)
FASB ASC 350-10-40-1, derecognition
IRS, frequently asked questions on digital-asset transactions (page last updated 29 June 2026; its broker-custody identification answers were added 15 December 2025 and predate Notice 2026-20, and the fee-disposition point relied on here is unaffected)
HMRC Cryptoassets Manual, CRYPTO22150
HMRC Cryptoassets Manual, CRYPTO22280, fees satisfied in tokens

Note on the Bitcoin Developer Guide: it is a frozen 2020 snapshot and is no longer maintained. It remains accurate for the consensus rules cited here, each of which is also implemented in current Bitcoin Core.

Educational research, not accounting, tax, legal, valuation or investment advice.