Digital Asset Accounting: What Merchants Need to Know

Say a customer pays you in crypto and you convert it to fiat or a stablecoin the same day. You barely touch the fair value rules everyone writes about. The money comes in, you book revenue for what you received, and the crypto is off your balance sheet within hours.

The heavy machinery of ASU 2023-08 – monthly remeasurement, fair value hierarchy, impairment reversals – mostly applies to businesses that hold crypto as an investment. Most merchants don't. That single distinction changes almost everything about how you keep your books, and nearly every guide on this subject skips it.

This is written for the business receiving a payment, not the one holding crypto as an investment. The two have very different accounting lives, and the difference is the whole point. We'll go through how the US GAAP rules classify what you take in, how cost basis works when crypto comes and goes, what you actually have to disclose, and why converting on arrival takes most of this off your plate.

A note on scope. This covers US GAAP and US federal tax treatment. Rules differ under IFRS and in other jurisdictions, and none of this constitutes formal tax advice – confirm your own position with a qualified crypto accountant or crypto CPA before you file.

What counts as a digital asset under the new rules?

In late 2023, the FASB issued ASU 2023-08 (designated as ASC 350-60 in the code) and, for the first time, required companies to report cryptocurrency subject to the standard at fair value in each reporting period, with changes in value recognized directly in net income. This standard is effective for fiscal years beginning after December 15, 2024. Companies that use the calendar year as their fiscal year – both public and private – will apply it beginning January 1, 2025.

Before that, crypto sat on the books as an indefinite-lived intangible asset. You booked it at cost, tested it for impairment, and marked it down when the price fell. If the market recovered, though, you were stuck – the old rules let you write it down but never back up.

An asset only falls under ASC 350-60 if it meets every one of these conditions:

• It's an intangible asset as defined in GAAP.
• It gives the holder no enforceable rights to underlying goods, services, or other assets.
• It lives on a cryptographically secured distributed ledger.
• It's fungible.
• The reporting entity or a related party didn't issue it.

Bitcoin and Ether clear all five. That's why they're the textbook examples.

What stays outside the fair value model

Not everything with a ticker qualifies. NFTs fail the fungibility test, so they stay on the old intangible-asset model. Wrapped tokens need a closer look: if the token conveys an enforceable claim to an underlying asset, it likely fails the "no enforceable rights" criterion, and the "wrapped" label alone doesn't settle it.

Stablecoins are the subtle case, and they get their own section below, because the answer isn't the one most people assume.

Are stablecoins accounted for the same way as Bitcoin?

Not automatically, and this trips up a lot of merchants who assume a dollar-pegged token is just "digital cash." Under ASC 350-60, you have to examine the token's terms. A stablecoin that gives you a redemption right – an enforceable claim against the issuer or its reserves – can fail the "no enforceable rights" test and fall outside the fair value model. One that doesn't may fall inside it. USDC and USDT shouldn't be assumed to qualify one way or the other just because they're tokens; the terms decide.

This matters because so many merchants now settle directly in stablecoins. If you accept USDC for a sale, the accounting question isn't "how do I remeasure this crypto asset every month? For a merchant, a stablecoin received for goods or services is closer to a daily revenue item you record and sweep, not an issuer's position to mark. The classification analysis still has to happen, but the practical reality – a pegged token that you convert or hold for days, not quarters – keeps it far simpler than Bitcoin on a corporate treasury.

A separate question is whether you can treat a received stablecoin as a cash equivalent on the balance sheet. People often reach for the GENIUS Act here. It doesn't help as much as the headlines suggest – more on that near the end.

How fair value is measured: the Level 1/2/3 hierarchy

For an in-scope asset, measurement runs under ASC 820, which sorts inputs into three levels. The level depends on the quality of the underlying price data, not how well-known the coin is.

And Bitcoin or Ether isn't automatically Level 1 either. It depends on the market and the measurement date, not the coin's reputation. You assess the specific measurement and your principal or most advantageous market each period. For a merchant converting on arrival, you rarely build a full hierarchy, because the asset isn't sitting on the books waiting to be remeasured.

Recording revenue when a customer pays you in crypto

Here's the core merchant scenario, start to finish. A customer buys a $1,000 product and pays in crypto.

At the sale

You recognize revenue of $1,000 – the fair value of what you received, measured at the transaction date. Revenue recognition under ASC 606 doesn't change just because the payment rail is a blockchain.

The asset lands

The crypto hits your wallet or your processor's balance. Its carrying amount is that same fair value at receipt. This value becomes your cost basis for any later disposal.

Conversion

If you convert to fiat or a stablecoin, you record the disposal. Any difference between the conversion proceeds and your cost basis is a gain or loss.

When steps 2 and 3 happen minutes apart, the gain or loss is usually trivial – a few cents of price drift, or nothing. When crypto sits on your books for weeks, that gap becomes real, and for an in-scope asset you'd also be remeasuring it to fair value at each reporting date in between.

This is the single worked example most competing guides never give. They stop at the standards. The proviso: numbers here are illustrative, and your own entries depend on your functional currency, your conversion timing, and your auditor's view.

Cost basis: FIFO, specific identification, and the per-wallet rule

For US federal tax – a separate track from GAAP financial reporting – you need a cost basis method for crypto you dispose of.

FIFO (first in, first out) is the default when you don't specifically identify the units sold. Specific identification is allowed when you identify the exact units and keep records that support their basis. 

HIFO (highest in, first out) isn't really a separate method – it's specific identification with the highest-basis lots picked first. One rule change matters more than it looks. For disposals on or after January 1, 2025, FIFO or specific identification applies within a single wallet or account, not across one universal pool covering all your wallets. Rev. Proc. 2024-28 gave a safe harbor to allocate unused pre-2025 basis to the assets held in each wallet or account as of that date – a transition measure, not the ongoing rule.

For a merchant who converts on receipt, basis tracking is light – the holding period is near zero, so there's little gain to compute. For one who accumulates crypto across several wallets, this is exactly where a crypto subledger earns its place.

Disclosure: what you have to show

ASU 2023-08 didn't just change measurement. It added presentation and disclosure requirements that, for an in-scope holder, go well beyond a single number.

On the balance sheet, in-scope crypto appears on its own line, separate from other intangibles, and its gains and losses sit separately in the income statement. You disclose your significant holdings, and once a year you file a rollforward: a reconciliation from opening to closing balance that accounts for what you added, what you sold, and the gains and losses booked along the way. 

For a merchant who settles on arrival, most of this is moot. There's no material closing balance to roll forward because the asset didn't stay, which brings us to the argument at the center of this whole topic.

Why instant conversion removes most of the burden

Here’s the part worth stating plainly, with a distinction most write-ups collapse: converting to fiat and converting to a stablecoin do different things to your balance sheet.

Convert to fiat on arrival and the crypto asset is gone before the reporting date. There’s no closing position, so the periodic fair value remeasurement at the centre of ASU 2023-08 has nothing to act on. Convert to a stablecoin and you still hold an asset at period end – a stable one, but an asset. What changes is the scope question. ASU 2023-08 covers crypto assets that carry no enforceable claim on an underlying, and a fiat-backed stablecoin with a redemption right against its issuer may sit outside that definition. Whether it does is a determination for your auditor, not for a payment provider, and it should be made before the first reporting period rather than during it. 

Either path, the accounting stays. Revenue is still recognised at fair value on the sale. The conversion is still recorded. The gain or loss between receipt and settlement is still recognised, even when the gap is measured in seconds. Disclosure covers activity during the period, not only the position at the end of it, so a quarter with a hundred receipts and a hundred conversions is a quarter with two hundred events to report, however empty the closing balance looks.

What immediate conversion does remove is the volatile holding period: no unrealised gains and losses accumulating quarter after quarter, no fair value inputs to defend on an asset whose price moved while you held it. That’s a narrower claim than “settlement timing solves your crypto accounting,” and it’s the accurate one. 0xProcessing’s VRCS converts incoming payments to a stablecoin as they land, which closes the volatility exposure. It doesn’t decide your reporting treatment, and no processor’s feature does.

Audit readiness: the documentation you actually need

Hold crypto or convert it; either way, an auditor will want to follow every transaction from the chain to your ledger. Run payments through a processor, and most of that trail is already sitting there. You’re not reconstructing it from block explorers.
What an auditor will actually ask you for:

• A record of each payment, down to the date, amount, asset, and what it was worth in fiat when it landed.
• The transaction hash for every transfer in and out, so each account entry points back to something on-chain.
• Wallet reconciliation. Match your on-chain balances to the books on a regular cadence.
• Settlement statements with the conversion rate and what you actually received in fiat or a stablecoin.
• Cost basis records per wallet or account, with the method you applied.
• Internal controls over who can move funds and how you authorize conversions.
• A rollforward of any crypto you actually hold across the period.

Notice how many of these a payment gateway produces natively. The disclosure rules ask for a source for your rate, wallet-level detail, and a reconciliation of movements. A dashboard or API that exports timestamped transactions, the hash, and the settlement rate is, in effect, handing you the raw material for those disclosures – rather than leaving you to assemble it from block explorers by hand. Put differently, your crypto bookkeeping and payment tooling do much of the same work. Let the processor’s records feed the books.

The 2026 regulatory context: GENIUS Act and SAB 122

Two recent developments change the backdrop, and both are easy to overstate.

SAB 122

The SEC issued it on January 23, 2025, effective January 30, 2025, rescinding the earlier SAB 121. SAB 121 required platforms safeguarding crypto for users to recognize a liability and a matching asset on their balance sheet at fair value. SAB 122 removed that prescriptive treatment. It doesn't mean a custodian never books a liability – you still assess whether a loss-related liability should be recognized under existing standards like ASC 450-20, with the relevant disclosures. For most merchants who don't safeguard other people's crypto, SAB 122 is background instead of a direct obligation.

The GENIUS Act

Signed July 18, 2025, it creates a federal framework for issuing payment stablecoins. It's frequently invoked to argue that a merchant receiving USDC or USDT can now book it as a cash equivalent. Per the Act's text, that's not what it does. It regulates issuers; it doesn't write a US GAAP rule that reclassifies stablecoins you receive as cash. Cash-equivalent classification stays an accounting analysis under applicable GAAP – the Act's passage doesn't settle it. (We cover the Act's broader merchant impact in our guide to the GENIUS Act and stablecoin payments separately; here the point is narrow.)

On timing: the Act's general effective date is the earlier of 18 months after enactment – January 18, 2027 – or 120 days after the primary federal stablecoin regulators issue final implementing rules. The OCC floated proposed rules back in February 2026, but proposed isn’t final, and the 120-day clock doesn’t start until the real ones land. Which means that, late in 2026, the law is on the books but not yet switched on.

Neither rule, then, hands a merchant a shortcut to booking received stablecoins as cash. What does simplify your books is settlement timing, not regulatory status.

Bottom line

For businesses that hold crypto as an investment, ASU 2023-08 is a genuine shift – fair value every period, a new disclosure package, an annual rollforward. For merchants who accept crypto as payment and convert it quickly, most of that weight never lands. You recognize revenue at fair value on the sale, record the conversion, and keep clean transaction records. The asset doesn't sit around long enough for remeasurement to bite.

The practical move is to decide, deliberately, whether you're a holder or a receiver. If you have no reason to carry volatile crypto on your balance sheet, converting on arrival keeps you on the simple side of every rule discussed here – and the records your processor already produces cover most of what an auditor and the disclosure standards will ask for.

If you're weighing how to set this up, the question worth asking isn't "which crypto accounting software do I buy" but "how do I stop volatile assets from reaching my balance sheet in the first place." Solve that, and the software question gets a lot smaller.

FAQ