How to Account for Bitcoin Transactions, Event by Event

Learning how to account for Bitcoin transactions is mostly a matter of classifying the economic event first and using the chain afterwards to evidence quantity and settlement. A single Bitcoin transaction can be a sale, a supplier payment, an internal transfer and a fee at once, and the blockchain will not say which is which.

The chain records the value consumed and the value created, and nothing about the business purpose, so a ledger built by importing transactions literally books revenue that never happened and loses the units that actually left the entity (Bitcoin Developer Guide, Transactions).

The reverse trap is harder to spot. An accounting event can occur with no Bitcoin transaction at all: a pool accruing a reward on its private ledger, a borrower defaulting, or a payment settling off-chain over the Lightning Network (Lightning BOLT 5).

Identify the business event first. Use the blockchain to support quantity and settlement, not to invent the accounting classification.

This reference covers native BTC: bitcoin on the Bitcoin blockchain itself, not a token on another network or a claim that tracks the price. Two terms carry it. A UTXO, or unspent transaction output, is a discrete piece of spendable value created by an earlier transaction; a wallet "balance" is only the sum of the UTXOs its keys can spend, and an output is always spent whole. An accounting lot is a quantity of BTC with an acquisition date and a cost basis. The two do not align, so UTXO selection must never be treated as the accounting lot method by default.

How to account for Bitcoin transactions: four questions before you book anything

Four questions come before any material BTC event reaches the ledger. What happened economically? What asset or liability is involved: native BTC, a contractual claim to BTC, or a BTC-denominated liability? How much BTC changed economically, separating retained change and self-transfers from the BTC that actually left? And what functional-currency amount applies under the documented valuation policy at that event's recognition timestamp? Answer them from wallet records, exchange statements, contracts, invoices, pool ledgers and channel records, not from the chain alone.

Buying Bitcoin, in self-custody or at a custodian

A cash purchase creates a Bitcoin asset when the applicable recognition criteria are met. Capture the quantity, purchase time, counterparty, cash paid, trading and network fees, custody destination, functional-currency amount and acquisition-lot reference; every later question about basis, lot selection and disposal gain is answered from that list.

The framework decides what enters the opening amount. Under IFRS, a separately purchased holding under IAS 38 starts at cost including directly attributable acquisition cost, while IAS 2 determines the cost of BTC acquired as inventory, and the IFRS Interpretations Committee's June 2019 agenda decision routes a holding to one or the other. Under US GAAP the purchase is not an ASC 350-60 question at all: ASC 350-60-05-2 says the Subtopic "does not address the initial measurement, recognition, and derecognition of crypto assets," which are accounted for "in accordance with other generally accepted accounting principles" (FASB ASU 2023-08). Only after that entry does an in-scope holding enter the ASC 350-60 fair-value model.

Keep acquisition price and later valuation price in separate fields. Merging them is how subledgers start disagreeing with the general ledger.

Custody changes the evidence, not the principle. BTC withdrawn to a self-custody wallet leaves settlement evidence on the chain; BTC left at a custodian can be traded on the custodian's private ledger and never appear on-chain. The entity must then decide whether it still recognises native BTC or holds a contractual claim instead, which turns on whether specific coins are segregated, whether the custodian may use them, who bears gains and losses, and what the customer would recover in insolvency.

Receiving Bitcoin from a customer, and the measurement-date trap

A customer payment in BTC is two separate pieces plus a third that follows later: recognise the sale or service under the applicable revenue rules, recognise the BTC as noncash consideration at the amount the framework requires, and treat the later movement of that BTC as a new event. Keeping them apart prevents a common error: treating a later sale of customer-received BTC as if the cash proceeds were fresh revenue.

Not every incoming receipt is revenue at all. BTC can arrive as a shareholder contribution, a gift, a grant, a loan drawdown, the settlement of a receivable, or a return of the entity's own funds, and the credit side depends on the relationship and the conditions attached rather than the direction of the transfer. That is why an automated rule of the form "incoming BTC equals revenue" is unsafe.

The measurement date is where a US GAAP reader gets hurt. ASC 606-10-32-21 fixes the measurement date for noncash consideration at contract inception, not the date of receipt, and not the date revenue is recognised, and in an evergreen arrangement those dates can be months apart. In a February 2024 comment letter the SEC staff told a listed miner that measuring rewards "using the spot rate of bitcoin at the time that the block is successfully mined … does not comply with the requirement in ASC 606-10-32-21 to measure noncash consideration at contract inception" (SEC staff comment letter to MARA, 2 February 2024). That is a comment to one issuer rather than codified guidance for every entity, but it marks the boundary clearly enough to design around.

IFRS diverges by construction. IFRS 15 requires noncash consideration to be measured at fair value but specifies no measurement date, so contract inception, receipt and satisfaction of the performance obligation can all be argued and the entity must adopt and disclose a policy. Two otherwise identical ledgers, one IFRS and one US GAAP, differ here by design rather than by error.

A company provides services and receives 0.05 BTC worth $5,000, measured at the date its framework requires:

Dr Bitcoin asset                         5,000
    Cr Revenue                           5,000

If it later sells that BTC for $5,400, the $400 difference is not additional customer revenue. Under an IAS 38 cost model it is a disposal gain, and IAS 38.113 is explicit that such a gain shall not be classified as revenue; under ASC 350-60 much of it will already have passed through net income before the sale.

Paying employees and contractors in Bitcoin

Bitcoin compensation has two sides for the payer: the payroll or service cost under the applicable compensation rules, and a separate derecognition of the BTC used to settle the obligation, which can produce a gain or loss.

Dr Payroll or contractor expense       X
    Cr Bitcoin asset                    Y
    Cr/Dr gain or loss                  X - Y

The residual depends on the model. Under an IAS 38 cost model the carrying amount is historical cost, so the difference can be large; under ASC 350-60 the units are already carried at fair value through net income (FASB ASU 2023-08), so once they are remeasured to the transaction moment little or no separate disposal difference remains. Payroll withholding, employment-tax and information-reporting obligations are jurisdiction-specific and must never be inferred from the financial-reporting entry.

Moving your own BTC: self-transfers, change and UTXO housekeeping

Own-wallet movement is where how to account for Bitcoin transactions and a literal reading of the chain come apart. An own-wallet transfer normally changes where BTC is controlled, not who owns it. Where beneficial ownership stays with the same reporting entity, do not record a sale, do not create a new acquisition lot for the retained quantity, do not reset basis because new UTXOs were created, and do record the network fee separately.

The arithmetic makes the point better than the rule. Suppose a transaction consumes 0.42907543 BTC and creates 0.40000000 BTC in cold storage (a wallet whose spending keys are kept offline during ordinary use) plus 0.02904401 BTC of change, with 0.00003142 BTC as the fee. The retained 0.42904401 BTC carries its accounting history forward untouched, and only 0.00003142 BTC has left the entity. An importer that reads the change output as a receipt records false income; one that sums only the explicit outputs misses the fee entirely, because Bitcoin has no separate fee field (Bitcoin Developer Guide, Transactions).

Consolidating 20 UTXOs into one, or splitting one into five, is the same story: when every retained output stays under the entity's control it is protocol housekeeping, not twenty disposals and one acquisition. Store UTXO identifiers in a different field from accounting-lot identifiers.

Fees: network, trading, brokerage and withdrawal

For an ordinary Bitcoin transaction the network fee is total inputs minus total outputs, derived rather than stated (Bitcoin Developer Guide, Transactions). Treat it as its own BTC outflow and let its functional-currency classification follow the purpose of the underlying transaction: a period expense for a pure internal transfer, part of the cost of acquiring another asset where the relevant standard permits or requires it, a selling or transaction cost, or another supported classification. Do not both expense and capitalise the same fee.

The half of the rule that gets dropped is the other side of the entry. The BTC used to pay the fee is itself disposed of. Those units have a carrying history, so paying a fee means derecognising them at their carrying amount and recognising any resulting gain or loss. A fee is two events, not one, and a ledger that records only the expense leaves basis stranded.

Trading, brokerage and withdrawal fees are different animals. A withdrawal fee is a custodian service charge that may not equal the network fee the custodian actually pays. The accounting follows who charged it, what service it relates to, whether it is settled in cash or BTC, and whether the applicable model capitalises or expenses it.

Custody: depositing and withdrawing

A transfer to a custodian is not automatically a disposal, and a withdrawal is not automatically an acquisition.

On the way in, the question is whether the entity retains the same asset and beneficial ownership. If the arrangement preserves the entity's rights in the BTC, the movement is a custody change rather than derecognition; if it transfers control and leaves the entity with a contractual claim against the intermediary, the entity may need to derecognise native BTC and recognise a different asset carrying credit risk. The deciding evidence is the custody agreement, segregation terms, reuse or rehypothecation rights (the custodian's ability to re-pledge or lend out customer assets), withdrawal rights and insolvency treatment.

On the way out, the chain shows BTC arriving at the entity's wallet, which looks like a receipt. If the entity already recognised the BTC while it was in custody, the withdrawal is not a new acquisition and generates no revenue; if it had recognised a contractual claim instead, the withdrawal settles that claim.

The January 2025 rescission of SAB 121 by SEC Staff Accounting Bulletin 122 returned safeguarding entities to the otherwise applicable contingency and disclosure guidance, but rescission does not prove that either party recognises the BTC.

Selling Bitcoin for fiat, and why "net gain" is not always right

The pattern most people learn first (derecognise the BTC, recognise the cash, record the difference from carrying amount as a gain or loss) is right for an IAS 38 holding and for an in-scope US GAAP holding. It is wrong where the BTC is held for sale in the ordinary course of business.

Where BTC is held for sale in the ordinary course of business it is IAS 2 inventory, measured at the lower of cost and net realisable value, and selling it produces gross revenue and a cost of sales, not a net gain buried in other income. One exception matters for exactly this reader: a commodity broker-trader within IAS 2.3(b) and 2.5 measures at fair value less costs to sell, with changes in profit or loss. A trading entity, and in some fact patterns a miner that routinely sells production, therefore presents the same transaction very differently from a treasury holder, and the June 2019 agenda decision forces that classification question before the disposal question. Going the other way, IAS 38.113 is emphatic that a disposal gain on an intangible shall not be classified as revenue, so an IAS 38 holder cannot present BTC sales on the revenue line even if selling BTC is what the business does.

US GAAP routes disposal outside ASC 350-60 entirely. Because ASC 350-60-05-2 excludes derecognition, disposal follows ASC 350-10-40-1 to Subtopic 610-20, or to Topic 606 where the disposal is a contract with a customer, and the gain or loss is the difference between the consideration and the carrying amount. Since that carrying amount is already a fair-value amount remeasured through net income, the ordinary reading treats departing units as remeasured up to the transaction date, so little or no separate disposal gain remains. That is interpretation rather than Codification, and it breaks down whenever consideration differs from ASC 820 fair value: a sale outside the principal market, or an agreed price that is not fair value (FASB ASU 2023-08).

Whichever model applies, the lot comes from the entity's documented policy, not from the wallet: do not assume the UTXOs the wallet happened to spend determine the carrying amount removed.

Spending Bitcoin on goods, services or equipment

Paying with BTC is two things at once: acquisition or expense of whatever the entity receives, and disposal of the BTC used as consideration. Payment in BTC does not erase the disposal accounting for the BTC itself. The entry, however, is not framework-neutral, and presenting it as though it were is a live error.

Suppose equipment worth $8,000 is acquired with Bitcoin whose carrying amount is $6,700. Under an IFRS cost model the compressed entry works:

IFRS - IAS 38 cost model
Dr Equipment                            8,000
    Cr Bitcoin asset                    6,700
    Cr Gain on BTC disposal             1,300

Under US GAAP that single entry is not available. ASC 350-60 has been effective for fiscal years beginning after 15 December 2024, including interim periods within those fiscal years (ASC 350-60-65-1(a)), and applies to all entities holding crypto assets (ASC 350-60-15-2). In-scope BTC is measured at fair value with every change in net income (ASC 350-60-35-1), so the units are remeasured first and derecognised second:

US GAAP - step 1, remeasure the units to transaction-date fair value (ASC 350-60-35-1)
Dr Bitcoin asset - fair-value adjustment      1,300
    Cr Fair-value gain - BTC                  1,300

US GAAP - step 2, derecognise the units (ASC 350-10-40-1)
Dr Equipment                                  8,000
    Cr Bitcoin asset - carrying amount        6,700
    Cr Bitcoin asset - fair-value adjustment  1,300

The two-step presentation is a convention rather than a Codification requirement, and remeasuring up to the transaction date is likewise interpretation rather than a stated rule. What is not optional is the destination of the $1,300: under US GAAP it is a fair-value remeasurement effect in net income, not a disposal gain. Note also that the entity acquired equipment without using cash, so this is a noncash item rather than an investing outflow.

Crypto-to-crypto exchanges

Exchanging BTC for another cryptoasset is a disposal of one asset and an acquisition of a different one, not a transfer between wallets. Determine the quantity derecognised, the carrying amount removed, the amount at which the acquired asset is recognised, any gain or loss, the fees and the valuation evidence for both legs. Many jurisdictions also treat such exchanges as taxable disposals, so do not copy the financial-reporting entry into the tax ledger, and check the position country by country in our crypto tax accounting guide.

Lending, borrowing and collateral

A Bitcoin loan is analysed from the contract, not from the promise that "10 BTC comes back later." If the borrower can sell or reuse the transferred BTC and owes only equivalent units later, the lender has likely transferred control and replaced the BTC with a contractual right.

Qualify what that right is before you name the account. A right to receive a fixed number of BTC is a right to a nonfinancial asset; it is not automatically a financial asset merely because the agreement is called a loan, so IFRS 9's expected-credit-loss machinery does not attach by default. IFRS has no Bitcoin-loan model, so under IAS 8 the entity develops a recognition, measurement, remeasurement and impairment policy by reference to analogous IFRS requirements and the Conceptual Framework. Reuse rights, collateral, recall rights, default remedies and who bears loss are the decisive facts.

US practice differs in shape. A January 2023 KPMG summary of SEC staff views has the lender derecognising loaned BTC when the borrower can direct its use and bears loss or theft risk, recognising a crypto-asset loan receivable measured at the fair value of the loaned units through earnings, and applying ASC 326 to credit loss separately (KPMG, Lenders' accounting for crypto intangible asset loans), which is nonauthoritative interpretation of a regulator's views, not a Codification model. Repayment settles principal and is not new income. A change is already at ballot. On 19 August 2026 the FASB tentatively decided that "crypto asset lending transactions should not result in derecognition of the transferred crypto assets". The lender instead reclassifies the asset as encumbered and captions it separately, with fair value reflecting the counterparty's credit risk, and recognises no separate asset for the right to receive the units back. Staff were directed to draft a proposed ASU with a 60-day comment period (FASB). That is a tentative Board decision and not current GAAP, but it reverses the receivable model above, so do not treat today's treatment as settled.

A borrower that obtains control holds both a Bitcoin asset and a separate obligation to return equivalent BTC, a liability that survives a sale of the borrowed units. Principal, interest and collateral are tracked independently and presented gross unless the offset criteria are actually met. KPMG's April 2026 handbook views that return obligation under ASC 815 as a hybrid instrument with a debt host and an embedded derivative indexed to BTC, requiring a bifurcation assessment (KPMG US, Crypto Assets Handbook, Q8.3.80). That is again interpretation of existing Topics, not Bitcoin-loan guidance.

Pledged BTC follows the same control test. If the pledge creates only a restriction, disclosure or reclassification is more relevant than derecognition; if control passes to the lender, another asset or right replaces the BTC. A liquidation after default can involve derecognition of the BTC, reduction of the secured liability, a gain or loss, a penalty or fee, and a residual receivable or payable, and only the loan agreement explains which.

When BTC stops being your asset: lost keys, theft and custodian failure

These look identical on a portfolio screen and are three different accounting problems: a lost key is an access and control problem, a custodian failure is a legal-rights and credit problem, and a borrower default is a receivable problem.

Lost keys. Losing the only usable private key destroys practical access without creating any on-chain transaction, and the BTC stays visible on-chain forever, which proves nothing about whether the entity still controls an accounting asset. Assess whether other backups or signing paths exist, whether recovery is realistic, whether derecognition or impairment criteria are met, and whether any insurance or recovery asset exists. Under IFRS the operative boundary is IAS 38's derecognition condition (no future economic benefits expected from use or disposal) read with IAS 37 and IAS 36 for any recovery asset; under US GAAP the Codification does not reach it squarely: ASC 350-10-40-1 governs the transfer or sale of a nonfinancial asset, routing to Subtopic 610-20 or to Topic 606, and both presuppose a counterparty and consideration that a lost key does not involve. In-scope units therefore continue to be measured at fair value under ASC 350-60-35-1 until the entity concludes that no asset remains (a judgement about the asset itself rather than a disposal), with ASC 450 governing any recovery claim.

Theft. Locating the stolen output solves nothing. Determine when control was lost and whether a recovery claim against a thief, custodian or insurer separately meets its own recognition criteria; do not net a potential recovery against the loss.

Custodian freeze or failure. If customer BTC remains segregated and legally protected, the analysis differs sharply from an unsecured exchange claim; if the BTC has effectively become a claim against an insolvent intermediary, credit and recovery risk dominate the measurement.

Hard forks and Lightning channels

Two protocol features generate entries that the chain alone describes wrongly.

Hard forks. A hard fork is a protocol change some participants decline to adopt, so the chain splits permanently and holders at the split point control units on each network. The original BTC is not automatically disposed of because the fork occurred. Assess whether the entity controls the new asset, whether it meets the recognition criteria, when control arose, and how to determine the initial credit and any allocation of existing basis. Tax treatment is jurisdiction-specific.

Lightning channels. The Lightning Network lets two parties transact in BTC without recording each payment on the blockchain: they open a channel by locking BTC into a single on-chain output both control, pay each other many times by exchanging signed statements of the channel's current split, and close with one on-chain transaction paying out each side's ending balance (Lightning BOLT 5). Each end of that story misleads alone. A funding transaction looks like BTC sent to a stranger, when the BTC may remain part of the entity's controlled position subject to channel constraints; a closing transaction looks like a fresh receipt, when it is the return of the entity's own balance. Between them, thousands of economic events can occur with no base-chain trace, so the accounting needs the node's channel records. A channel can also be resized on-chain by splicing without being closed, so an unexplained transfer involving a channel is not necessarily an opening or a close.

Mining-pool accrual and payout

A mining participant can earn under a private pool contract long before any BTC reaches its wallet. Where the pool statement establishes an enforceable and measurable amount, the entity can have income under the applicable model together with a receivable or earned pool balance, and the later on-chain payout settles that balance (Braiins Pool, rewards and payouts, documenting one pool's private ledger and not asserted as a universal rule). Do not record both the accrual and the payout as income, a mistake that is easy to make because the payout is the only part of the sequence the blockchain shows.

Bitcoin is not cash, and BTC-settled deals are noncash items

Most accountants arrive at Bitcoin with a foreign-currency mental model, and it misleads in two specific ways.

BTC is not cash or a cash equivalent. The IFRS Interpretations Committee concluded that a cryptocurrency is not cash, because it is not currently used as a medium of exchange and monetary unit broadly enough for that classification, and is not a financial asset, because it is neither cash, an equity instrument of another entity nor a contractual right (June 2019 agenda decision). Receiving, spending or transferring BTC is therefore not by itself a cash flow. Under IAS 7, cash paid to acquire BTC and cash received on sale are classified by the nature and purpose of the activity, while a BTC purchase of equipment or repayment of a BTC borrowing is a noncash investing or financing transaction, excluded from the statement of cash flows and disclosed elsewhere, the $8,000 equipment purchase above being exactly that.

One dating point matters for anyone planning FY2026 under IFRS. IFRS 18 Presentation and Disclosure in Financial Statements replaces IAS 1 for annual reporting periods beginning on or after 1 January 2027, with earlier application permitted, and is applied retrospectively, so FY2026 comparatives are restated on first application. It also renames IAS 8 to Basis of Preparation of Financial Statements and moves the starting point of the indirect-method cash flow statement from profit or loss to operating profit (IFRS Accounting Taxonomy 2024 Update 1, IFRS 18). It changes presentation and disclosure, not the conclusion that BTC is neither cash nor a cash equivalent.

US GAAP reaches the same place with one mandatory exception. BTC-only activity remains noncash, but ASC 230-10-45-27A applies when all its conditions are met (in-scope BTC received as noncash consideration in the ordinary course of business and converted nearly immediately, meaning within hours or a few days rather than weeks), and the resulting cash receipt shall then be classified as operating (FASB ASU 2023-08). If either condition fails, the entity classifies the cash under the other ASC 230 guidance on its facts.

BTC is also not translated as a foreign currency. The Committee's route to this is IAS 21.16, which it cited to establish that a cryptocurrency holding is a non-monetary item: the essential feature of a non-monetary item is the absence of a right to receive a fixed or determinable number of units of currency, and BTC gives the holder no such right. There is therefore no closing-rate retranslation of a BTC balance the way there is for a foreign-currency bank account; each recognition, derecognition and reporting-date measurement is expressed in the functional currency under the standard governing the underlying asset, which is why "functional-currency amount" in a BTC subledger means a measurement, not a translation.

Period-end measurement: an accounting event with no Bitcoin transaction

A reporting-date impairment, revaluation or fair-value adjustment moves no BTC: it creates no UTXO and no transaction hash, and only the functional-currency carrying amount moves, which is another reason a Bitcoin subledger cannot be derived from transaction history alone. The model matters more than the price. An in-scope US GAAP holding is measured at fair value through net income under ASC 350-60-35-1, the model our FASB digital asset explainer walks through in full, whereas an IAS 38 cost-model holding applies an IAS 36 recoverable-amount assessment and does not automatically record every price rise. Two correct ledgers can diverge at year end even when their BTC quantities agree to the satoshi. It is one more place where how to account for Bitcoin transactions is a different question from how to import them.

One transaction, three accounting events

Suppose an entity sends one transaction with these outputs: 0.05000000 BTC to an equipment supplier, 0.07500000 BTC delivered in settlement of an executed sale, change back to its own wallet, and a 0.00002000 BTC network fee. A chain importer sees one transaction; the accounting has to see three events and one deliberate non-event.

• Supplier leg. Recognise the equipment under the applicable property, plant and equipment guidance and derecognise the 0.05 BTC used as consideration.
• Sale leg. Recognise cash or an exchange receivable and derecognise 0.075 BTC. This leg settles an executed sale. If BTC is instead merely deposited with an exchange pending a trade, apply the custody test above: the deposit is not the disposal, and the sale is recognised when the trade executes.
• Fee leg. Derecognise 0.00002 BTC and allocate the fee to the transaction purposes under a documented policy.
• Change, the non-event. Preserve the existing accounting lots. Do not create revenue and do not create a new purchase.

That is why a protocol transaction identifier should link to several accounting event rows rather than to one, and why how to account for Bitcoin transactions is a question about events rather than about hashes.

The record structure, and what not to automate

Keep these fields separate for each imported transaction rather than collapsing them into one row: transaction identifier; economic event type; quantity acquired or disposed; self-transfer and change classification; network fee quantity; recognition timestamp; functional-currency price and its source; accounting-lot reference; custody and ownership conclusion; and supporting document. If one row cannot carry all of that, link the transaction to several accounting event rows.

Automation narrows the investigation into how to account for Bitcoin transactions; it does not conclude it. It can derive fees, identify likely change and flag unmatched transfers, but never infer from direction alone that an outgoing transaction is a disposal, an incoming output is income, or a new UTXO is a new lot. The wider close this sits inside is set out in our crypto accounting guide, and the lot side of it in what cost basis tracking actually involves.

More in this series

Accounting Token Anatomy: Bitcoin. This article stands alone, but the series builds in order.

Previous, 01.1.3: Why the Bitcoin Blockchain Is Not an Accounting Ledger

Next, 01.1.5: Bitcoin Valuation for Accounting: Which BTC Price to Use

Sources and further reading

• Bitcoin Developer Guide, Transactions
• Bitcoin Core 31.0 RPC documentation
• IFRS Interpretations Committee, Holdings of Cryptocurrencies, June 2019
• IAS 2, Inventories
• IAS 38, Intangible Assets
• IAS 36, Impairment of Assets
• IAS 8, Accounting Policies, Changes in Accounting Estimates and Errors
• IAS 7, Statement of Cash Flows
• IFRS 15, Revenue from Contracts with Customers
• FASB ASU 2023-08, Accounting for and Disclosure of Crypto Assets (ASC 350-60 and ASC 230-10-45-27A)
• FASB ASU 2016-12, ASC 606 noncash consideration measured at contract inception
• FASB ASC 350-10-40-1, derecognition of an intangible asset
• FASB, Accounting for Transfers of Crypto Assets
• SEC staff comment letter to MARA, 2 February 2024
• SEC Staff Accounting Bulletin 122
• KPMG US, Crypto Assets Handbook, April 2026
• KPMG US, Lenders' accounting for crypto intangible asset loans, January 2023
• KPMG, Crypto mining activities, 4 June 2026
• Braiins Pool, rewards and payouts
• Lightning BOLT #5

Educational research, not accounting, tax, legal, valuation or investment advice. Apply the relevant reporting framework and transaction facts before booking an entry. Where a passage above is labelled interpretation or regulator comment, it is not authoritative guidance and does not replace the underlying standard.