Report phase

Disclosure requirements for a token-built asset

Report

IAS 38 requires disclosure, for each class of intangible, of whether useful lives are finite or indefinite, the useful lives or amortisation rates, the amortisation methods, the gross carrying amount and accumulated amortisation, and the paragraph 118 reconciliation IAS 38 §118. For a token-built asset these apply as they would to any finite-life intangible, with impairment disclosures overlapping IAS 36.

What the note must state

That the useful life is finite, and the useful life applied or the amortisation rate used.
The amortisation method used for the class.
The gross carrying amount and any accumulated amortisation and impairment at the start and end of the period.
The line of the income statement in which amortisation is included.
The paragraph 118 reconciliation of opening to closing carrying amount.

These requirements are the standard IAS 38 class disclosures; a token-built asset does not attract a separate regime, but its useful-life and method choices carry more explanatory weight because they are less familiar to a reader IAS 38 §118.

Where impairment disclosure overlaps IAS 36

Impairment losses appear both in the IAS 38 reconciliation, as a movement in the carrying amount, and in the IAS 36 impairment disclosures, which call for the events and circumstances that led to the loss and the basis on which recoverable amount was determined IAS 36 §18. For a model written down after a deprecation event, the note should name the event, not merely book the number.

What is often missed

Three omissions recur. The useful-life rationale for a fast-obsoleting asset is stated as a bare number with no explanation, inviting challenge. The amortisation method is disclosed but not justified against the pattern of benefit IAS 38 §98. And the impairment narrative is thin, giving the number without the deprecation or supersession event that caused it. Each gap is easy to close and each strengthens the note.

Materiality and aggregation

Where capitalised token spend is material, presenting it as its own class or clearly within a software intangibles class helps a reader understand it. Where it is immaterial, it can be aggregated, but the useful-life and impairment judgements should still be capable of support in the file even if not separately disclosed.