Bitcoin Journal Entries: A Complete Worked Accounting Example
A full-year Bitcoin accounting example: purchase, mining-pool revenue, wallet transfers, network fees, a sale, a supplier payment, IFRS impairment and US GAAP.
Maksym Buhai
Accounting Engineer
August 20, 2026 · 16 min read

Every one of the Bitcoin journal entries below balances. Balancing is the easy part, and not the part that fails an audit. What fails is the layer underneath, where the evidence, the quantity, the lot and the framework are settled before a single debit is written.
That layer is where a wallet screen shows a large outgoing transaction when almost all of the BTC, the ticker for the bitcoin unit, merely moved between addresses the same company controls; where a pool payout looks like fresh income when the revenue was already recognised from the pool's private ledger; and where a supplier settled in BTC is at once a fixed-asset acquisition and a disposal. So this example runs one company through a full year in one direction: event, evidence, quantity, valuation, entry, remaining position.
How to read this, and what it is not. Every amount flows from the assumptions below: change the classification, the lot method, the reporting frequency or the price source and the entries change with it. Educational research, not accounting, tax, legal, valuation or investment advice.
The Bitcoin journal entries in this article assume the wider workflow is already in place. If it is not, our crypto accounting guide covers it, the glossary entries for journal entry and cost basis define the two records every posting touches, and Bitcoin accounting under US GAAP sets out the measurement model the bridge at the end of this article uses.
From on-chain event to a closed set of books
Every step must foot in two dimensions at once: BTC quantity and functional-currency amount.
- EventIdentify what happened commercially and which lots it touches.
- EvidenceTransaction id, wallet records, pool statements, price source and timestamp.
- MeasurementApply the framework and the entity's documented valuation policy.
- EntryDebits equal credits; basis is relieved from a specific lot.
- ReconciliationQuantity roll-forward and carrying-amount roll-forward must both close.
The company and the six assumptions behind these Bitcoin journal entries
Northstar Mining Ltd. has a US-dollar functional currency and supplies computing power to a mining pool under a written evergreen service contract. The operator is Northstar's customer under IFRS 15 and ASC 606, with one performance obligation: to provide computational power continuously. None of the six assumptions below is a rule of Bitcoin accounting; each is a conclusion Northstar reached on its own facts and documented before posting.
- Lot method. An illustrative first-in, first-out (FIFO) financial-reporting subledger. Book lots and tax lots stay separate: FIFO is not Canada's identical-property average cost (CRA), the United Kingdom's section 104 matching sequence (HMRC CRYPTO22200), or the United States wallet-by-wallet identification and default rules (Treas. Reg. §1.1012-1(j)).
- IFRS classification. BTC held after receipt is an IAS 38 intangible asset under the cost model, because treasury records show it is not held for sale in the ordinary course of business. Its life is indefinite, so IAS 38.107 bars amortisation and IAS 38.108 sends it to IAS 36 for testing at least annually.
- The IFRS alternative Northstar ruled out. The IFRS Interpretations Committee's June 2019 agenda decision routes a cryptocurrency holding to IAS 2 Inventories when it is held for sale in the ordinary course of business, and to IAS 38 only when IAS 2 does not apply. A commodity broker-trader acquiring inventories principally to sell in the near future and profit from price fluctuations or a broker-trader's margin may instead use IAS 2's fair-value-less-costs-to-sell measurement exception, with changes in profit or loss (IAS 2.3(b) and 2.5); the exception reaches measurement only, and IAS 2's other requirements still apply. Mining alone does not establish broker-trader status, and either route rewrites the IFRS half of this example.
- US GAAP classification. In-scope BTC is subsequently measured under ASC 350-60 after transaction-specific initial recognition, because native BTC meets all six scope criteria in ASC 350-60-15-1.
- Reporting frequency: Northstar reports annually only. No interim balance-sheet date falls anywhere in this example. That does no work under IFRS here and a great deal in the US GAAP bridge: see the precondition on the $1,985.00 remeasurement total.
- Price source. Each event uses the Coinbase Exchange BTC-USD one-minute candle close for the UTC minute beginning at the event time (endpoint documentation). That is an illustrative execution proxy, not an assertion that Coinbase is any entity's principal market under IFRS 13 or ASC 820. Document the principal-market and timing policy first, and never pick a source after seeing its result.
| UTC minute | Event | BTC-USD |
|---|---|---|
| 11 Feb 2025 15:30 | Purchase | $97,039.85 |
| 8 May 2025 18:45 | Pool reward | $101,321.82 |
| 16 Jul 2025 09:20 | Cold-storage fee | $119,077.69 |
| 22 Sep 2025 16:10 | Sale, supplier, fee | $112,830.75 |
| 31 Dec 2025 23:59 | Closing measurement | $87,497.94 |
The primary journal is the IFRS IAS 38 cost-model ledger; a bridge below explains how a US GAAP reporter's postings differ on the same facts under ASC 350-60.
The Bitcoin events these journal entries record, and the evidence behind them
| Date | Bitcoin event | Quantity | Evidence |
|---|---|---|---|
| 11 Feb | BTC purchased for cash | 0.38174625 BTC | Bank, wallet, price record |
| 8 May | Pool allocates, retains 2%, pays net | 0.04829508; 0.00096590; 0.04732918 BTC | Contract, pool ledger, payout |
| 16 Jul | BTC moved to cold storage | 0.00003142 BTC fee | Raw transaction, ownership evidence |
| 22 Sep | BTC sold for cash | 0.07563879 BTC | Exchange and cash records |
| 22 Sep | Supplier paid in BTC for cooling equipment | 0.05000000 BTC | Invoice, raw transaction |
| 22 Sep | Network fee on the batch transaction | 0.00002275 BTC | Raw transaction, allocation paper |
| 31 Dec | BTC remaining | 0.30338247 BTC | Node reconciliation, lot ledger |
Around those sit the ordinary non-Bitcoin facts, all supported by invoices and meter data: a $128,473.62 ASIC fleet invoiced on 6 January and available for use on 1 February with a 36-month life and $6,250 residual value, plus $18,742.63 of electricity and $4,318.27 of hosting, repair and maintenance from February to December. An ASIC, an application-specific integrated circuit, is a chip built to do one job, here the repeated hashing Bitcoin mining requires; for accounting it is ordinary property, plant and equipment (PPE). Depreciation begins when the fleet is available for use under IAS 16.55, not when management judges mining profitable, so 2025 carries eleven months: ($128,473.62 - $6,250.00) / 36 x 11 = $37,346.11. The 36-month life is Northstar's own estimate, not a life prescribed by IFRS, US GAAP or any tax code.
Entry 1: acquire the ASIC fleet
| Account | Debit | Credit |
|---|---|---|
| PPE - ASIC fleet | $128,473.62 | |
| Cash / accounts payable | $128,473.62 |
Not a Bitcoin entry, but the mining accounting cannot be followed once the hardware disappears.
Entry 2: buy Bitcoin for cash
On 11 February Northstar acquires 0.38174625 BTC for $37,044.60. Under IAS 38.24 a separately acquired intangible asset is measured initially at cost, so the debit is what was paid.
| Account | Debit | Credit |
|---|---|---|
| Digital assets - BTC | $37,044.60 | |
| Cash | $37,044.60 |
The lot record now carries 0.38174625 BTC acquired 11 February 2025 at 15:30 UTC, a basis of $37,044.60 and a unit price of $97,039.85/BTC. An unspent transaction output (UTXO) is the unit the Bitcoin network itself tracks: a discrete chunk of BTC locked to a spending condition, which a later transaction must consume whole, paying any surplus back as change (Bitcoin developer guide). A UTXO is not an accounting lot, because a self-transfer destroys and recreates UTXOs without creating an acquisition.
Entry 3: record mining operating costs
| Account | Debit | Credit |
|---|---|---|
| Mining electricity expense | $18,742.63 | |
| Hosting, repair and maintenance expense | $4,318.27 | |
| Cash / accounts payable | $23,060.90 |
This example uses a service-revenue model, so operating costs are expensed as the service is provided rather than capitalised into BTC inventory. A supportable IAS 2 production-inventory model could route eligible purchase and conversion costs into inventory instead, but the two cannot be mixed: one kilowatt-hour is either a service expense or an inventory cost.
Entry 4: recognise the mining-pool reward
On 8 May the pool's private ledger shows a gross allocation of 0.04829508 BTC, less a 2% retained charge rounded to 0.00096590 BTC, leaving 0.04732918 BTC. At $101,321.82/BTC that is $4,893.35 gross, $97.87 retained and a $4,795.48 net BTC basis. On the stated contract analysis the retained charge is consideration payable to a customer for no distinct service, so under IFRS 15 it reduces revenue rather than being expensed.
| Account | Debit | Credit |
|---|---|---|
| Digital assets - BTC, pool lot | $4,795.48 | |
| Mining revenue - pool fee, contra-revenue | $97.87 | |
| Mining service revenue - gross | $4,893.35 |
The control that matters is not the arithmetic but the avoidance of duplicate revenue. The private ledger evidences that the reward became enforceable and the later payout settles it; booking another $4,795.48 on wallet receipt counts the same economics twice, and the wallet, seeing only an incoming payment, supports the error.
The measurement-date trap that splits IFRS from US GAAP
When an amount becomes enforceable and which date prices it are two questions, and only IFRS lets them be answered together. IFRS 15 requires noncash consideration to be measured at fair value but sets no measurement date, so an entity adopts a policy and discloses it. ASC 606-10-32-21 sets one: contract inception. In a 2 February 2024 comment letter the staff of the US Securities and Exchange Commission (SEC) told a listed miner that measuring participant rewards at the block-success spot rate "does not comply with the requirement in ASC 606-10-32-21 to measure noncash consideration at contract inception." The staff accepted that an operator mining its own block may treat validation as inception; a pool participant cannot. This example therefore assumes the evergreen contract is a series of daily contracts, so inception and block success fall on the same day, and that Northstar has elected a consistent inception-date convention which its 8 May observation represents. The daily-contract analysis aligns the day, not the minute: a US GAAP reporter still needs a stated inception-date measurement convention. Without that analysis, pricing a participant reward at block success applies a method the SEC staff has objected to in writing.
Entry 5: move Bitcoin to cold storage
Before the 16 July transaction Northstar controls two UTXOs, 0.38174625 BTC from February and 0.04732918 BTC from the May payout, totalling 0.42907543 BTC. The move to cold storage creates a 0.40000000 BTC output to the cold-storage address, 0.02904401 BTC of change back to Northstar, and a 0.00003142 BTC network fee. The UTXOs change dramatically; the economic position changes only by the fee, worth $3.74 at the July price against $3.05 of FIFO basis. Only the fee units leave, so only they are derecognised under IAS 38.112, with IAS 38.113 measuring the gain as net disposal proceeds less carrying amount.
| Account | Debit | Credit |
|---|---|---|
| Network fee expense - self-transfer | $3.74 | |
| Digital assets - BTC, FIFO basis | $3.05 | |
| Gain on disposal of BTC used as fee | $0.69 |
There is no entry for the 0.40000000 BTC cold-storage output or the 0.02904401 BTC change output merely because they are new UTXOs. Northstar controls both, so no future economic benefit has left, IAS 38.112 is not engaged, and the lot history survives.
Entry 6: sell BTC for cash
On 22 September Northstar sells 0.07563879 BTC. At $112,830.75/BTC the proceeds are $8,534.38 against a $7,339.98 FIFO basis, so the gain is $1,194.40.
| Account | Debit | Credit |
|---|---|---|
| Cash | $8,534.38 | |
| Digital assets - BTC | $7,339.98 | |
| Gain on disposal of BTC | $1,194.40 |
Note where that $1,194.40 is not presented. IAS 38.113 requires gains on derecognition of an intangible asset to be recognised in profit or loss and states that they "shall not be classified as revenue." For a mining company the temptation to put a disposal gain on the revenue line is real, and the standard forecloses it. That sentence restricts gains only; a disposal loss is not caught by it.
Entry 7: buy equipment with Bitcoin
In the same September batch Northstar pays a supplier 0.05000000 BTC for cooling equipment worth $5,641.54 at the stated transaction-date value, against a $4,851.99 FIFO basis.
| Account | Debit | Credit |
|---|---|---|
| PPE - cooling equipment under installation | $5,641.54 | |
| Digital assets - BTC | $4,851.99 | |
| Gain on disposal of BTC | $789.55 |
Paying with Bitcoin does two things at once: it acquires the equipment and it derecognises the BTC used as consideration. This is not an asset-to-asset transfer at historical cost, and a system that reclassifies $4,851.99 from "Digital assets" to "PPE" loses the $789.55 gain and understates the equipment.
Entry 8: allocate the September network fee
The batch also pays a 0.00002275 BTC network fee worth $2.57, allocated by economic-purpose output value, the change output excluded: 39.80% to the equipment, or $1.02, and 60.20% to selling cost, or $1.55. The fee units carry $2.21 of FIFO basis, producing a $0.36 disposal gain under the stated cost model.
| Account | Debit | Credit |
|---|---|---|
| PPE - allocated network fee | $1.02 | |
| Selling cost - allocated network fee | $1.55 | |
| Digital assets - BTC, FIFO basis | $2.21 | |
| Gain on disposal of BTC used as fee | $0.36 |
One on-chain batch, three accounting events. The network does not say which part of the fee belongs to the purchase and which to the sale; that comes from business purpose and a documented policy. The fee is a separate disposal of BTC, not a cost folded into the other two entries, which is why its $2.57 is split rather than charged twice. The same reasoning applies when a network or gas fee on another chain serves more than one business purpose.
Entry 9: depreciation at year end
| Account | Debit | Credit |
|---|---|---|
| Depreciation expense - ASIC fleet | $37,346.11 | |
| Accumulated depreciation - ASIC fleet | $37,346.11 |
The cooling equipment is still under installation, so nothing is depreciated on it. Note what does not reduce this charge: IAS 16.55 provides that depreciation does not cease when an asset becomes idle or is retired from active use unless it is already fully depreciated, so curtailing a fleet through a low-margin period cuts revenue without cutting the straight-line charge. The same paragraph also carves out usage methods, under which the charge can be zero while there is no production, so an entity depreciating ASICs by hashes produced reaches a different answer on idling and should say so in its policy note.
Reconcile the remaining BTC before any closing measurement
Bitcoin journal entries are only as good as the quantity underneath them, so quantity comes before valuation: a precisely valued wrong quantity is still wrong. 0.38174625 + 0.04732918 - 0.00003142 - 0.12563879 - 0.00002275 = 0.30338247 BTC. The wallet ends the year holding two UTXOs, of 0.27433846 and 0.02904401 BTC, whose boundaries again have nothing to do with the two accounting lots. At $87,497.94/BTC on 31 December, 0.30338247 BTC is worth $26,545.34, or $3,097.51 under the pre-close book basis.
| Lot | Quantity | Remaining cost basis | 31 Dec fair value |
|---|---|---|---|
| February purchase residue | 0.25605329 BTC | $24,847.37 | $22,404.14 |
| May pool payout | 0.04732918 BTC | $4,795.48 | $4,141.21 |
| Total | 0.30338247 BTC | $29,642.85 | $26,545.34 |
Lot fair values are rounded individually for display while the total is computed from the unrounded quantity, so the lot values sum to one cent more than the total. Pick one convention and apply it consistently.
IFRS period-end entry, tested lot by lot
Northstar's IFRS policy is IAS 38 under the cost model, so the year-end question is impairment, not remeasurement. IAS 36.9 requires an assessment at each reporting date of whether there is any indication that an asset may be impaired, IAS 38.108 requires an indefinite-life intangible to be tested at least annually regardless of indicators, and IAS 36.8 compares carrying amount with recoverable amount, which IAS 36.18 defines as the higher of value in use and fair value less costs of disposal.
IAS 36.22 determines recoverable amount for an individual asset unless it does not generate cash inflows largely independent of those from other assets, in which case the test moves to the cash-generating unit (CGU) it belongs to. A BTC treasury holding generates no such independent inflows, so the general rule would push the test to a CGU. It stays at the asset only through IAS 36.22(b), which excepts an asset whose value in use can be estimated to be close to a measurable fair value less costs of disposal, which is the position of a holder of a quoted, actively traded asset with immaterial selling costs. IAS 36.21 then lets fair value less costs of disposal serve as recoverable amount where there is no reason to believe value in use materially exceeds it, so recoverable amount is taken as the observable $26,545.34.
| Account | Debit | Credit |
|---|---|---|
| Impairment loss - BTC | $3,097.51 | |
| Accumulated impairment - BTC, by lot (February purchase residue; May pool payout) | $3,097.51 |
Closing IFRS carrying amount: $26,545.34. That this equals the quoted market value does not turn IAS 38 into a fair-value model; it is an IAS 36 recoverable-amount assessment that landed on the same number.
That single line is a presentation summary, not the test. Because IAS 36 fixes the unit of account at an asset or a CGU, nothing in it lets an entity net one holding's unrealised loss against another's unrealised gain and impair the difference. Here both lots sit below cost, so the two lot-level tests, computed on unrounded lot values, add to the $3,097.51 posted above. Posted lot by lot and rounded to the cent, the two charges are $2,443.23 and $654.27, which sum to $3,097.50, a one-cent rounding difference against the single line shown. Pick one convention and disclose it; do not let the two coexist in the same ledger. Change the facts (a February lot in loss, a May lot bought cheaply enough to be in gain) and netting understates the impairment by an unrecognised gain the cost model cannot recognise at all. So compute and post the charge lot by lot, and keep that record: reversal testing has to know which lot was written down and by how much.
Presentation, for periods after this example. These statements are prepared under IAS 1. IFRS 18 Presentation and Disclosure in Financial Statements replaces IAS 1 for annual periods beginning on or after 1 January 2027, early application permitted, and applies retrospectively, so a calendar-year entity restates its FY2026 comparatives; it also moves several IAS 1 requirements into IAS 8, retitled Basis of Preparation of Financial Statements. The amounts do not change; where they sit does.
US GAAP fair-value bridge
Under US GAAP, in-scope BTC is measured at fair value under ASC 820 each reporting period, with every change in net income (ASC 350-60-35-1). ASC 350-60 does not supply the derecognition model. ASC 350-60-05-2 states that the Subtopic "does not address the initial measurement, recognition, and derecognition of crypto assets", so a disposal follows ASC 350-10-40-1, which routes a nonfinancial asset to Subtopic 610-20, or to Topic 606 where the counterparty is a customer. Current major-firm interpretation remeasures the departing units to transaction-date fair value, then derecognises them under that guidance (KPMG US, Crypto Assets Handbook). Label that correctly: no sentence in ASC 350-60 requires a remeasurement before every sale.
Over the original FIFO cost basis, the departing units gain $0.69 in July and $1,194.40, $789.55 and $0.36 in September, a total transaction-date remeasurement gain of $1,985.00.
Precondition: Northstar reports annually only. Those four amounts are struck against the original February cost basis because no interim balance-sheet date falls between February and each transaction. ASC 350-60 is effective for fiscal years beginning after 15 December 2024 including interim periods within those fiscal years (ASC 350-60-65-1(a)), so a quarterly reporter would already have remeasured at 31 March and 30 June; its gains would run from the most recent interim fair value and would differ from every figure above. Copying these four numbers into an interim reporter's ledger produces the wrong per-transaction gains. The full-year effect on net income is unchanged; the periodic split is not.
For each departing quantity, remeasure the BTC to fair value through earnings, then derecognise both its cost component and its fair-value adjustment against the consideration or expense. No further disposal gain remains here only because this example assumes the consideration equals ASC 820 fair value at each transaction moment. That is an assumption, not a universal rule: the ASU 2023-08 basis for conclusions says the gain or loss on sale may be zero, and it will not be zero where units are sold outside the principal market or at an agreed price that is not fair value, leaving a real ASC 610-20 gain or loss to recognise.
One disclosure consequence is easy to miss. Although $1,985.00 is presented as fair-value remeasurement, the same $1,985.00 is also Northstar's cumulative realised gain for ASC 350-60-50-4(b), because a realised gain is measured against original cost basis. The two answer different questions and the annual disclosures require both, alongside the opening-to-closing reconciliation in ASC 350-60-50-3. The remaining 0.30338247 BTC closes with a $29,642.85 cost basis and a $26,545.34 fair value. ASC 350-60-50-1 requires both at interim and annual dates, so the cost ledger cannot be discarded once the balance sheet moves to fair value.
| Account | Debit | Credit |
|---|---|---|
| Fair-value loss - BTC | $3,097.51 | |
| Digital assets - fair-value adjustment | $3,097.51 |
Closing US GAAP carrying amount: $26,545.34. This entry needs no lot-level test, because fair value is measured on the whole in-scope holding, so netting is correct here, the opposite of the IFRS position above. Crypto assets, and their remeasurement gains and losses, are presented separately from other intangible assets and from changes in other intangibles' carrying amounts (ASC 350-60-45-1 and 45-2).
The same number, two different models: what happens if BTC recovers
Both frameworks close at $26,545.34 for unrelated reasons, and a price recovery separates them at once. Under US GAAP nothing special happens: ASC 350-60-35-1 keeps measuring at fair value through net income, up or down, with no ceiling. Under the IFRS cost model a recovery is an impairment-reversal question under IAS 36, and it is not discretionary. IAS 36.110 requires an assessment at the end of each reporting period of whether a previously recognised impairment loss may no longer exist or may have decreased, and an estimate of recoverable amount if it may. IAS 36.114 then requires reversal "if, and only if, there has been a change in the estimates used to determine the asset's recoverable amount since the last impairment loss was recognised". That is mandatory, not a policy choice. IAS 36.117 caps that reversal at the carrying amount, net of amortisation or depreciation, that would have been determined had no impairment loss been recognised in prior years.
So on a recovery the IFRS carrying amount can climb back toward, but never above, the $29,642.85 pre-impairment basis, while the US GAAP amount follows the market past it. That cap is the second reason to keep the per-lot record: without it, each lot's ceiling cannot be computed. An IAS 2 inventory conclusion, or the broker-trader exception, produces a third pattern again.
What this example teaches
Bitcoin journal entries are the last step, not the first. Before posting, answer six questions in order: what happened economically, what evidence proves it, how much BTC changed ownership, what price policy applies, which lot leaves, and which framework governs the carrying amount. That sequence prevents the standard errors: recognising change as income, treating self-transfers as sales, counting a pool payout as revenue twice, ignoring the disposal of BTC used to pay a fee, using UTXOs as accounting lots, applying financial-reporting FIFO as a tax method, netting one lot's unrealised loss against another's gain in an IAS 36 test, and assuming IFRS and US GAAP reach the same carrying value for the same reason. The evidence that supports each of those answers is the subject of the next article on records and reconciliation.
More in this series
Accounting Token Anatomy: Bitcoin. This article stands alone, but the series builds in order.
Previous (01.1.8): Bitcoin Accounting Under US GAAP: ASC 350-60, Fair Value and Disclosures
Next (01.1.10): Bitcoin Accounting Records, Controls and Reconciliation: A Practical Close Guide
All fifteen articles
- 01.1.1: Bitcoin for Accountants: The Technical Concepts You Actually Need
- 01.1.2: What Do You Actually Own When You Hold Bitcoin?
- 01.1.3: Why the Bitcoin Blockchain Is Not an Accounting Ledger
- 01.1.4: How to Account for Bitcoin Transactions: A Practical Event-by-Event Guide
- 01.1.5: Bitcoin Valuation for Accounting: Which BTC Price Should You Actually Use?
- 01.1.6: Bitcoin Mining Accounting: Rewards, Pools, Revenue, ASICs and Costs
- 01.1.7: Bitcoin Accounting Under IFRS: IAS 2, IAS 38, Impairment and Disclosure
- 01.1.8: Bitcoin Accounting Under US GAAP: ASC 350-60, Fair Value and Disclosures
- 01.1.10: Bitcoin Accounting Records, Controls and Reconciliation: A Practical Close Guide
- 01.1.11.1: Bitcoin Tax in Canada: Capital Gains, Business Income, ACB, Mining and GST/HST
- 01.1.11.2: Bitcoin Tax in the United States: Basis, Disposals, Mining and Form 1099-DA
- 01.1.11.3: Bitcoin Tax in the UK: Capital Gains, Section 104 Pooling, Mining and CARF
- 01.1.11.4: Bitcoin Tax in the EU: What DAC8 and VAT Do, and What Member States Still Decide
- 01.1.12: What Accounting Standards Still Do Not Answer About Bitcoin
Sources and further reading
- IFRS Interpretations Committee, Holdings of Cryptocurrencies, June 2019
- IAS 2, Inventories
- IAS 38, Intangible Assets
- IAS 36, Impairment of Assets
- IAS 16, Property, Plant and Equipment
- IFRS 15, Revenue from Contracts with Customers
- IFRS 13, Fair Value Measurement
- IFRS 18, Presentation and Disclosure in Financial Statements
- IAS 8, Basis of Preparation of Financial Statements
- FASB ASU 2023-08, Accounting for and Disclosure of Crypto Assets (ASC 350-60)
- FASB ASU 2016-12, ASC 606 noncash consideration measured at contract inception
- FASB ASC 350-10-40, derecognition gateway
- FASB ASU 2011-04, ASC 820 fair-value measurement
- Coinbase Exchange candle endpoint documentation
- Bitcoin developer guide, transactions
- SEC staff comment to MARA, February 2, 2024
- KPMG US, Crypto Assets Handbook, April 2026
- CRA, special rules for other transactions (identical properties)
- HMRC, Cryptoassets Manual CRYPTO22200: pooling
- Treas. Reg. §1.1012-1
All amounts are part of one internally consistent illustrative fact pattern. They are not a substitute for applying the relevant framework and tax rules to an entity's actual transactions.
Educational research, not accounting, tax, legal, valuation or investment advice. Every entry above depends on the six stated assumptions; a different classification, lot method, reporting frequency or contract analysis produces different entries on the same facts.
Frequently Asked Questions
- In what order should a Bitcoin journal entry be built?
- Answer six questions in order before posting: what happened economically, what evidence proves it, how much BTC changed ownership, what price policy applies, which lot leaves, and which framework governs the carrying amount. The journal is the last step in that sequence, not the first.
- Does moving Bitcoin to cold storage create a journal entry?
- Only for the network fee. The move destroys and recreates unspent transaction outputs, but the entity still controls both the cold-storage output and the change output, so no future economic benefit has left, IAS 38.112 is not engaged and the lot history survives. Only the fee units leave, so only they are derecognised.
- Is a mining-pool payout revenue a second time when it reaches the wallet?
- No. The pool's private ledger evidences that the reward became enforceable and the later payout settles it, so booking another amount on wallet receipt counts the same economics twice. The wallet, seeing only an incoming payment, supports the error.
- Can an IAS 36 impairment test net one Bitcoin lot against another?
- No. IAS 36 fixes the unit of account at an asset or a cash-generating unit, so nothing in it lets an entity net one holding's unrealised loss against another's unrealised gain and impair the difference. Compute and post the charge lot by lot and keep that record, because reversal testing has to know which lot was written down and by how much.
- Why do IFRS and US GAAP reach the same closing Bitcoin carrying amount here?
- For unrelated reasons. The IFRS figure is an IAS 36 recoverable-amount assessment under the cost model that happened to land on the quoted market value, while the US GAAP figure is an ASC 820 fair-value measurement. A price recovery separates them at once, because an IFRS reversal is capped at the pre-impairment basis and the US GAAP amount follows the market past it.