Accounting for Token Issuance: IFRS Treatment of Crypto Asset Fundraises

The Accounting Question That Determines Everything

Token issuances (whether structured as an ICO, an IEO, a private token sale, or a simple SAFT agreement) have been used by companies to raise capital since 2017. Despite the volume of transactions that have occurred, the accounting treatment under IFRS remains an area where many companies have made significant errors, either recognising proceeds as revenue immediately when they should have been deferred, or failing to recognise financial liabilities where the token structure creates genuine redemption rights.

The IFRS Foundation published an Agenda Decision on cryptoassets in June 2019, which confirmed that the existing IFRS standards apply to token holdings and issuances, and that no new standard was required. This means the accounting follows the economic substance of the instrument under existing frameworks: IFRS 15 for service obligations, IFRS 9 for financial instruments, and IAS 32 for equity classification. The 2019 agenda decision has been supplemented by extensive technical guidance from the Big 4 firms and the ICAEW, which this article draws on.

The Fundamental Question: What Obligation Does the Token Create?

Every token issuance accounting analysis begins with the same question: what contractual right does the token confer on its holder? The answer to this question determines which accounting standard governs the issuer's recognition of the proceeds received. There are four possible answers, leading to four different accounting treatments:

The critical discipline required is to analyse the actual terms of the token, not what it is called in the whitepaper or how it was marketed. A token marketed as a "utility token" may, on analysis, create contractual rights to future services (deferred revenue) or even financial return rights (financial liability). The label is irrelevant; the substance governs.

Scenario 1: Utility Token with Future Service Obligation

The most common scenario for pre-product token issuances is a utility token that gives holders the right to access the company's platform or services once they are built. The token is sold before the service is available. In substance, the company has received payment in advance for services that it has not yet delivered. This is a performance obligation under IFRS 15.

Accounting treatment

The proceeds received from the token sale are recognised as a contract liability (deferred revenue) on the balance sheet. Revenue is recognised as the company satisfies the performance obligation, which occurs as the service is delivered to token holders. The timing and pattern of revenue recognition depends on whether the performance obligation is satisfied at a point in time (e.g. when the token can be exchanged for a specific defined service) or over time (e.g. when the token gives ongoing access to a platform over its useful life).

An important complexity arises where the platform launches and the service is available, but token holders choose not to redeem. IFRS 15 requires the company to assess whether it expects a significant proportion of tokens to remain unredeemed (breakage) and to recognise breakage revenue accordingly. Over-aggressive recognition of breakage creates a risk of revenue reversal and should be approached conservatively.

Scenario 2: Security Token Paying Dividends

A security token that entitles holders to a share of the company's revenues, profits, or assets is a financial instrument. The question is whether it should be classified as a financial liability or equity under IAS 32.

IAS 32 classification test

Under IAS 32, an instrument is equity only if it contains no contractual obligation to deliver cash or another financial asset, and no contractual obligation to exchange financial assets or liabilities on potentially unfavourable terms. If a security token pays a defined dividend based on revenues or profits, or if it gives holders a redemption right (the ability to demand the return of their investment), it is a financial liability, not equity. Most security tokens that have been issued in the crypto market contain at least one feature that would require financial liability classification.

Scenario 3: Payment Token with No Contractual Obligation

The most ambiguous and legally uncertain scenario is a payment token (analogous to a cryptocurrency such as Bitcoin) where the issuer creates the token and sells it, but the token carries no contractual right to receive services from the issuer, no share of revenues or profits, and no redemption right. Examples in the market include native tokens of blockchain protocols, where the token is necessary to pay transaction fees on the network but the issuer has no ongoing obligation to the holder.

The accounting for this scenario is genuinely complex and fact-specific. The key questions are:

• Does the issuer have any continuing involvement with the token's operation or value? If yes, this creates a performance obligation.
• Is there any legal basis on which a holder could claim the return of the purchase price? If yes, this may create a financial liability.
• Does the whitepaper or any associated documentation create implied obligations? Implied obligations can qualify as performance obligations under IFRS 15.

Where there is genuinely no performance obligation and no financial obligation, the proceeds from a payment token sale might be recognised as revenue. However, this analysis requires careful legal and commercial review, and the position should be agreed with auditors before the proceeds are recognised. A company that has recognised payment token proceeds as revenue and then faces a regulatory challenge (such as the SEC's approach in the United States, which has classified many tokens as securities) may face both regulatory liability and an accounting restatement.

Decision Tree: Token Accounting Classification

Accounting for Tokens Received as Compensation or Payment

Companies may also receive tokens as payment for services rendered or as compensation for staff or advisers. The accounting for received tokens under IFRS is a separate question from the accounting for token issuance.

For tokens received as payment for services, the company recognises the fair value of the tokens received as revenue at the point they are received (or as each performance obligation is satisfied if the services are ongoing). The tokens themselves are then recognised as an asset on the balance sheet, classified and measured as follows:

• If the token is a financial instrument (e.g. it gives the holder a right to receive cash), it is classified under IFRS 9, typically as FVTPL for most cryptoassets (as they do not meet the SPPI test for amortised cost or FVOCI).
• If the token is not a financial instrument (most utility and payment tokens are not), it is classified as an intangible asset under IAS 38, measured at cost less any impairment. The cost is the fair value at the date of receipt. Impairment is recognised when the carrying amount exceeds the recoverable amount.

For tokens received as staff compensation (where a company awards its own tokens or third-party tokens to employees), IFRS 2 Share-Based Payment may apply. If the tokens constitute equity instruments of the company (which requires IAS 32 equity classification as above), IFRS 2 equity-settled treatment applies. If the tokens are cash-settled (the employee has a right to receive cash equivalent to the token value), IFRS 2 cash-settled treatment applies with a liability recognised at fair value at each reporting date.

Disclosure Requirements

Companies that have issued tokens or hold material cryptoasset positions should consider the following disclosure requirements:

• IFRS 15 disclosures: Where tokens are classified as contract liabilities, the company must disclose: the aggregate amount of the transaction price allocated to unsatisfied performance obligations; when it expects to recognise this revenue; and any significant judgements made in the timing of satisfaction.
• IFRS 7 disclosures: Where tokens create financial liabilities, the company must disclose: the nature and extent of risks arising from those instruments; fair value information; and the basis for fair value measurement (which for unlisted tokens typically requires level 3 valuation techniques).
• Accounting policy notes: The accounting policy for token issuance proceeds should be clearly stated in the notes to the financial statements, including the basis for classification and the revenue recognition policy. Auditors reviewing these accounts for the first time will scrutinise this note closely.
• Key sources of estimation uncertainty: Where the classification involves significant judgements (particularly for borderline cases), these should be disclosed as key sources of estimation uncertainty under IAS 1.

Key Takeaways

• The IFRS accounting treatment of token issuance proceeds depends on the obligation the token creates for the issuer. The label ("utility token", "security token") is irrelevant; the substance governs.
• Tokens creating a right to receive goods or services are contract liabilities under IFRS 15. Revenue is recognised only as performance obligations are satisfied.
• Tokens creating a claim on assets, revenues, or a redemption right are financial liabilities under IFRS 9 and IAS 32. Payments to holders are finance costs, not distributions.
• Tokens representing a residual equity interest may qualify as equity under IAS 32, but most crypto token structures contain features that require financial liability classification.
• Payment tokens with no contractual obligation are the most ambiguous scenario. Revenue recognition is potentially available but requires careful legal and accounting analysis and auditor agreement before it is applied.
• Tokens received as payment for services are recognised at fair value at receipt and classified as financial instruments (IFRS 9) or intangible assets (IAS 38) depending on their nature.
• Agree the accounting treatment with auditors before the token sale closes. A retrospective accounting analysis is less credible and creates audit conflict.