Stablecoin Chart of Accounts: Why It Is Not a Cash Account

The most common stablecoin accounting error is also the most intuitive one: the token tracks a dollar, so it gets booked in the cash account. For accounting purposes a stablecoin is generally not cash — it is a crypto-asset whose classification follows the same framework analysis as any other token. This spoke of the chart of accounts design cluster is dedicated to that specific trap: why "behaves like a dollar" is an economic intuition rather than an accounting classification, and how to structure the accounts so the balance sheet does not overstate cash. The classification of any particular stablecoin is an auditor judgement, so what follows is described, not prescribed.

The core point in brief

• A typical stablecoin is generally not cash and often not a cash equivalent: it is not legal tender, and its terms and risks differ from a bank deposit.
• It is commonly analyzed as a crypto-asset under the applicable framework, like other tokens.
• Booking it as cash overstates cash and hides it from crypto disclosures and the correct measurement model.
• Structure it as its own crypto-asset accounts (asset and wallet axes, realized/unrealized), not a fixed-at-par cash line.
• Depeg risk is part of why it is not cash: carrying amount, impairment, and fair value follow the applicable model.
• The classification is a framework-, instrument-, and jurisdiction-specific auditor judgement. This is not accounting advice.

Behaves like a dollar is not the same as being cash

Despite being designed to track a fiat value, a typical stablecoin is usually not cash and often not a cash equivalent for accounting: it is not legal tender, and its terms and risks differ from a bank deposit. It is commonly analyzed as a crypto-asset under the applicable framework, the same way other tokens are (see stablecoin accounting treatment). "Behaves like a dollar" is an economic intuition, not the accounting classification, and the classification is an auditor judgement on the specific instrument.

Why it matters

Putting stablecoins in the cash account is exactly the kind of misstatement an auditor looks for. The chart of accounts should keep them out of cash unless a specific analysis concludes otherwise.

How the chart of accounts should handle them

Typically as their own crypto-asset accounts, within the same classification framework used for other tokens (intangible, financial asset, or another treatment per the facts and framework), with the asset and wallet mapping axes applied as for any crypto (see chart of accounts design). Separating stablecoins from volatile crypto for management analysis is fine, but that separation is not the same as treating them as cash. The treatment is auditor-confirmed.

Depeg is part of the reason

A stablecoin can deviate from its reference value, so its carrying amount and any impairment or fair-value change are accounted for under the applicable model, not assumed at par. The chart of accounts therefore needs the same realized/unrealized structure as other crypto (see realized vs unrealized gain accounts), not a fixed-at-par cash line. The treatment of a deviation is framework-specific and auditor-confirmed.

Not one global rule

The general "not cash" position is widely applicable, but the precise classification and measurement depend on the framework (IFRS, US GAAP, French ANC) and the specific stablecoin's terms, and regulatory context such as the EU MiCA regime affects related obligations. The chart of accounts follows the applicable framework's conclusion for that instrument, auditor-confirmed, rather than a single global rule.

Practical guidance

1. Keep stablecoins out of the cash account by default.
2. Classify them under the same framework as other crypto-assets.
3. Use their own crypto-asset accounts with asset and wallet axes.
4. Apply a realized/unrealized structure, since depeg means they are not fixed at par.
5. Separate them for management analysis if useful, but recognise that is not "cash".
6. Confirm the instrument's treatment with your auditor. It is framework- and instrument-specific, and not accounting advice.

Configuring a tool so stablecoins aren't cash

Cryptio, Bitwave and similar sub-ledgers can map stablecoins to dedicated crypto-asset accounts rather than cash and apply the configured measurement. The specific thing to check when choosing one is that it does not silently default stablecoins into a cash or cash-equivalent line, which is the error this whole article is about. The tool applies the mapping; whether a stablecoin is cash, a cash equivalent, or a crypto-asset is an auditor judgement.

Where Wag3s fits

Wag3s Ledger maps stablecoins to dedicated crypto-asset accounts (asset and wallet axes, realized/unrealized) rather than the cash line, with an audit trail and ERP export. The classification of a specific stablecoin under the applicable framework stays with the entity's auditor; Ledger is built to support that determination with clean records, not to make it. See the Ledger product page.

Further reading

• Stablecoin Accounting Treatment
• Crypto Chart of Accounts Design
• Crypto Asset Account Classification
• Crypto Realized vs Unrealized Gain Accounts
• Stablecoin Payment Reconciliation
• Crypto CoA: GAAP and IFRS Mapping

A practical stablecoin chart-of-accounts structure

Below is an illustrative account structure for a company holding multiple stablecoins across multiple wallets. This is a design example, not a prescribed standard — your auditor confirms the appropriate classification under your applicable framework.

Balance sheet — current assets (crypto-asset section)

Under the cost model (common under IAS 38), the 1319 account captures impairment only. Under a fair-value model, it captures the full mark-to-market movement. Under US GAAP ASU 2023-08 (for in-scope crypto), fair value through net income applies and the unrealised change flows directly to the P&L rather than to a balance-sheet reserve.

Wallet sub-ledger axis. Each of the 1310-X accounts should be sub-ledgered by wallet address and custodian. This is not a separate account code hierarchy — it is a dimension on each account. The purpose: when the balance in 1310-USDC does not reconcile to on-chain USDC balances, the sub-ledger identifies which wallet the discrepancy sits in.

Income statement — realised gains/losses

The separation of gain and loss accounts (rather than a net "realised gain/(loss)") aids disclosure and audit — an auditor testing completeness of losses needs to see them separately from gains.

Why "stablecoin" is not a single account. The most common simplification error is maintaining one "stablecoins" account for all stablecoin holdings regardless of issuer. USDC, USDT, EURC, and DAI are distinct instruments with distinct issuers, distinct reserve structures, distinct regulatory classifications under MiCA, and distinct DAC8 reporting categories. They must be tracked separately to support instrument-level DAC8 reporting, MiCA-compliant classification, and independent impairment assessment per issuer.

Sources

• A typical stablecoin is generally not cash and often not a cash equivalent for accounting (it is not legal tender, and its terms and risks differ from a bank deposit), and is commonly analyzed as a crypto-asset under the applicable framework like other tokens. The fuller treatment is set out in stablecoin accounting treatment; the classification is an auditor judgement on the specific instrument.
• Measurement then follows the applicable crypto-asset framework — IFRS IAS 38 (cost or revaluation), US GAAP FASB ASU 2023-08 (fair value through net income for in-scope crypto), or, in France, the Règlement ANC n° 2026-01 recast — which is why depeg risk is accounted for under the model rather than assumed at par.
• The EU MiCA Regulation (UE) 2023/1114 affects related obligations and the instrument's regulatory classification. Booking stablecoins as cash overstates cash and removes them from the crypto disclosures; the treatment is framework-, instrument- and jurisdiction-specific and auditor-confirmed. This is not accounting advice.