Crypto as Customer Consideration: Revenue under IFRS 15

When a customer pays in crypto, the number of tokens received is not the revenue figure. IFRS 15 treats crypto as non-cash consideration, measured at fair value generally at contract inception, and that is what revenue is recognised on. The tokens then become an asset accounted for separately, so a single crypto-paid sale raises two distinct questions. This article works through that two-part mechanic and the discipline of keeping later price moves out of revenue. The asset side, once the crypto is on the books, follows the classification covered in the IAS 38 hub.

The revenue mechanic in brief

• Crypto from a customer is non-cash consideration under IFRS 15, measured at fair value (or, where fair value cannot be reasonably estimated, by reference to the stand-alone selling price).
• It is generally measured at contract inception; later price moves are the asset's question, not a revenue remeasurement.
• One crypto-paid sale raises two accounting questions: the revenue measurement, and the subsequent crypto-asset accounting (IAS 38, IAS 2, or ASU 2023-08).
• Keeping revenue separate from the subsequent remeasurement stops volatility distorting reported revenue.
• US GAAP differs (ASC 606 plus ASU 2023-08), so a dual reporter applies each framework.
• The measurement and its date are a fact-specific auditor judgement. This is not accounting advice.

Revenue = measured consideration, not token count

Crypto received from a customer is non-cash consideration. Under IFRS 15, non-cash consideration is generally measured at fair value; where fair value cannot be reasonably estimated, the entity refers to the stand-alone selling price of the goods/services. Revenue is not "the number of tokens" — it is the measured value of the consideration. Measurement and its timing are fact-specific auditor judgements.

Measured generally at contract inception

IFRS 15 generally measures non-cash consideration at fair value at contract inception; subsequent changes in the crypto's value are a separate question — the accounting for the asset received, not a continuous revenue remeasurement. Treating later price moves as revenue adjustments is a common error. The precise measurement date and any constraint are framework-/fact-specific, auditor-confirmed.

Then: the crypto is an asset

Once recognised, the crypto received is an asset under the applicable crypto guidance — typically IAS 38 intangible (cost/revaluation), IAS 2 inventory for a broker-trader, or US GAAP ASU 2023-08 fair value if in scope (see crypto asset account classification). A single crypto-paid sale → two distinct questions: revenue measurement and subsequent asset accounting. Both auditor-confirmed.

Volatility between contract and settlement

Generally the revenue reflects the consideration measured under IFRS 15 at the relevant point; price movements after that flow through the asset, not by re-opening revenue — though the exact treatment of any inception-to-receipt period depends on facts/framework. The discipline: separate revenue measurement from subsequent crypto remeasurement so volatility doesn't distort reported revenue. Auditor judgement.

US GAAP differs

The non-cash-consideration-at-fair-value principle is broadly shared, but the specific revenue standard (ASC 606) and subsequent crypto accounting (ASU 2023-08 fair value through net income) differ in detail from IFRS 15 / IAS 38. A dual-reporting entity applies each framework's revenue and asset guidance (see crypto CoA GAAP/IFRS mapping) — auditor-confirmed.

Practical guidance

1. Treat crypto received as non-cash consideration — measure at fair value, not token count.
2. Measure generally at contract inception; don't re-open revenue for later price moves.
3. Account for the received crypto as an asset under the applicable standard.
4. Separate revenue from subsequent remeasurement — protect reported revenue from volatility.
5. Apply each framework if dual-reporting (IFRS 15/IAS 38 vs ASC 606/ASU 2023-08).
6. Confirm measurement, date, and asset treatment with your auditor — fact-specific; not accounting advice.

Choosing a tool for crypto revenue

The whole discipline here is keeping the inception-date consideration value apart from what the token does afterwards, so the tool has to model both without conflating them. If you are evaluating one — Cryptio and Bitwave can capture the value of crypto received — confirm it can:

• record the consideration value at the right point (generally contract inception), not just the token quantity;
• book the received crypto as an asset and track its subsequent remeasurement separately;
• keep revenue distinct from that remeasurement, so a later price move never re-opens recognised revenue;
• support the stand-alone-selling-price fallback where the token has no reliable fair value at inception.

The tool records the figures; the IFRS 15 measurement is an auditor judgement.

How Wag3s fits in

Wag3s Ledger records the value of crypto received from customers at the relevant point and tracks the subsequent asset separately with an audit trail, so revenue and crypto-asset remeasurement stay distinct and evidenced. The IFRS 15 measurement and the subsequent asset treatment are fact-specific and stay with your auditor; Ledger supplies the figures and trail that support their review. See the Ledger product page.

Further reading

• Crypto & IFRS 13 Fair Value Measurement
• Crypto Asset Account Classification
• Crypto Revenue and Expense Accounts
• Crypto CoA: GAAP and IFRS Mapping
• Crypto & IAS 7 Cash-Flow Statement
• Paying Contractors in Crypto

Worked example: SaaS subscription paid in USDC

A protocol charges a €1,200 annual subscription for on-chain data services. A customer pays in USDC on 1 March 2026 at the contract inception date. The USDC/EUR rate on 1 March is 1.00 (for simplicity). By 30 June, USDC has depegged slightly; by 31 December, it has recovered.

Revenue recognition. Under IFRS 15, the contract consideration is €1,200 of USDC. The non-cash consideration is measured at fair value at contract inception: 1 March, 1,200 USDC × €1.00 = €1,200. Revenue of €1,200 is recognised over the 12-month subscription period (performance obligation satisfied over time).

Accounting entry on 1 March (receipt of USDC):

• Dr USDC digital asset (BS): 1,200 USDC at €1,200 carrying amount.
• Cr Deferred revenue (BS): €1,200.

Monthly revenue recognition (March through February):

• Dr Deferred revenue: €100/month.
• Cr Subscription revenue (P&L): €100/month.

The USDC depeg in June (carrying amount falls to €1,140 at the balance-sheet date). Under IAS 38 cost model, the carrying amount does not fall below recoverable amount; if the impairment is assessed as temporary with recovery likely, no impairment may be recognised. Under a fair-value model, the mark-to-market loss of €60 is recorded through the P&L or OCI as the framework requires. This is an asset accounting question — it does not reopen the €1,200 of revenue already recognised.

Common error. A team using a fair-value model records the June depeg as a €60 reduction in revenue rather than as a fair-value loss on the digital asset. This is incorrect: the revenue was €1,200 (the value of what was received at contract inception); the subsequent loss is a P&L item from holding the asset, not a retroactive reduction in what was earned. Revenue is not restated for post-receipt price movements.

If USDC had no reliable fair value at contract inception. Suppose the customer paid in a less liquid token with an uncertain market price at the time of contract. IFRS 15 then requires measuring the consideration by reference to the stand-alone selling price of the services — €1,200, the price the protocol charges for the subscription in EUR. The token received is still booked as an asset at fair value (if measurable) or at cost; the revenue is €1,200 regardless of what the token is worth at the time.

Sources

• IFRS — IFRS 15 Revenue from Contracts with Customers: non-cash consideration is measured at fair value, or by reference to the stand-alone selling price where fair value cannot be reasonably estimated, generally at contract inception. Revenue is the measured consideration, not the token count, and later crypto price changes are the asset's accounting rather than a revenue remeasurement.
• IFRS — IAS 38 Intangible Assets and IAS 2 Inventories: the asset accounting for the crypto once received (intangible by default, inventory for a broker-trader).
• FASB — Accounting Standards Update 2023-08, Subtopic 350-60, with ASC 606 for revenue: the US-GAAP treatment, which differs in detail from IFRS 15 / IAS 38. A dual reporter applies each framework; the measurement, date, and treatment are fact-specific auditor judgements and this is not accounting advice.