How to Audit Intangible Assets Under IAS 38

The identifiability test in IAS 38.12: separable or contractual

IAS 38.8 defines an intangible asset as an identifiable non-monetary asset without physical substance. The identifiability criterion in IAS 38.12 exists to distinguish intangible assets from goodwill.

An asset is identifiable if it meets either of two tests: separability (capable of being separated from the entity and sold, transferred, licensed, rented, or exchanged) or contractual origin (arising from contractual or other legal rights, regardless of whether those rights are separable).

This matters most in business combinations. When your client acquires another entity, IFRS 3 requires the acquirer to recognise identifiable intangible assets separately from goodwill. Customer lists that could be sold independently are separable. Patents qualify through the contractual-rights route. A trained workforce fails both tests, so it stays in goodwill.

The audit risk is underidentification.

Acquirers frequently lump everything beyond tangible assets and identified liabilities into goodwill because it’s simpler. IAS 38.12 and IFRS 3.13 don’t allow that. Your procedure on a business combination should include a structured review of what intangible assets might exist: customer relationships, order backlogs, technology, trade names, favourable contracts, and non-compete agreements. Each one gets tested against the separable-or-contractual criterion.

If the client engaged a valuation specialist to identify and value intangible assets in the acquisition, your work under ISA 620 includes evaluating the specialist’s competence, objectivity, and methodology. If the client didn’t engage a specialist, you need to assess whether the purchase price allocation is complete. A €5M acquisition premium with zero identified intangible assets is a red flag.

Recognition of purchased intangible assets versus internally generated ones

IAS 38 draws a sharp line between purchased and internally generated intangible assets. For a purchased intangible asset (acquired separately or in a business combination), recognition under IAS 38.21 requires that future economic benefits are probable and the cost is measurable. Both conditions are generally presumed to be satisfied for assets acquired in an arm’s length transaction (IAS 38.25), because the purchase price reflects the market’s assessment of the probability of future benefits.

Internally generated intangible assets face a much higher bar. IAS 38.51 through IAS 38.67 impose the research/development distinction and the six capitalisation criteria. The asymmetry is deliberate. Purchased assets have a market-validated price. Internally generated assets don’t, and the risk of capitalising costs that won’t generate future benefits is substantially higher.

The practical consequence: if your client buys a software licence for €300,000, recognition is straightforward (cost is the purchase price, future benefits are presumed). If your client spends €300,000 building equivalent software internally, recognition depends entirely on whether the six criteria in IAS 38.57 are met, and the amount capitalised is only the expenditure incurred from the date all six criteria are first satisfied (IAS 38.65). Expenditure incurred before that date is gone. IAS 38.71 prohibits reinstating costs previously expensed.

This creates an incentive for management to argue that the IAS 38.57 criteria were met earlier than they actually were, to capitalise more costs and improve short-term profitability. Your audit is testing the date, not just the existence of the criteria.

The research versus development boundary: IAS 38.54 through IAS 38.56

IAS 38.54 requires all expenditure on research (or on the research phase of an internal project) to be expensed when incurred. No exceptions. IAS 38.8 defines research as original and planned investigation undertaken with the prospect of gaining new scientific or technical knowledge and understanding. The key word is “prospect.” Research is exploratory. The outcome is uncertain.

IAS 38.56 says that expenditure on the development phase of an internal project can be capitalised, but only if the entity can demonstrate all six criteria in IAS 38.57 are met. IAS 38.8 defines development as the application of research findings or other knowledge to a plan or design for the production of new or substantially improved materials, devices, products, processes, systems, or services before the start of commercial production or use.

The boundary matters because it determines the earliest possible capitalisation date. In pharma, clinical trials represent the research phase until the trials produce results demonstrating the drug works. A software company building a prototype to test whether a technical approach is feasible is in the research phase until the prototype proves feasibility.

IAS 38.56(a) gives examples of development activities: the design, construction, and testing of pre-production prototypes and models; the design of tools, jigs, moulds, and dies involving new technology; and the design, construction, and operation of a pilot plant that is not of a scale economically feasible for commercial production. Your working paper should identify the specific activity the client designates as the transition from research to development and test whether that activity genuinely falls within IAS 38.56’s definition.

If the entity cannot distinguish the research phase from the development phase of an internal project, IAS 38.53 requires all expenditure on that project to be treated as research phase expenditure. Expensed in full. This is the fallback position, and it applies more often than clients would like.

The six capitalisation criteria in IAS 38.57

IAS 38.57 lists the conditions that must all be demonstrated before development costs can be capitalised. Each criterion requires specific audit evidence. Here’s what that looks like in practice.

Technical feasibility (IAS 38.57(a)): for software, this might be a completed and tested prototype, a technical architecture review, or a sign-off from the development lead confirming the approach works. A project plan alone doesn’t demonstrate feasibility. The question is whether the entity has evidence that the product can be built, not just that the entity plans to build it.

Intention to complete (IAS 38.57(b)): board minutes authorising continued investment, an approved project budget, or a product roadmap showing the asset in a future release. If the project has been paused, deprioritised, or reassigned to a skeleton team, the intention condition weakens.

Ability to use or sell (IAS 38.57(c)): for software intended for sale, this might be evidence of existing distribution channels, market research, or customer interest. For internal-use software, it’s the existence of a business process that will use the asset. A product with no identified user or buyer fails this condition.

Future economic benefits (IAS 38.57(d)): a signed customer contract, a letter of intent, a market analysis from a credible source, or (for internal use) a cost-benefit analysis showing the asset will reduce costs or increase efficiency. This is the condition most often satisfied with vague assertions rather than evidence. Push for something concrete.

Adequate resources (IAS 38.57(e)): a funded project budget, an allocated development team, and access to necessary technology. If the entity’s cash flow projections show it cannot fund the remaining development without additional financing that hasn’t been secured, this condition fails.

Reliable measurement (IAS 38.57(f)): a time-tracking system that captures hours by project, a cost allocation methodology, and clear separation between capitalised development costs and expensed overheads. If the entity’s time recording system doesn’t distinguish between research and development activities at the project level, this condition is not met.

Your working paper should test each criterion individually and document the evidence obtained for each one. A single-line conclusion (“IAS 38.57 criteria met”) without supporting evidence is exactly what inspection reviewers flag.

Useful life assessment: finite versus indefinite under IAS 38.88

IAS 38.88 requires the entity to assess whether the useful life of an intangible asset is finite or indefinite. An indefinite useful life doesn’t mean infinite. It means there is no foreseeable limit to the period over which the asset is expected to generate net cash inflows for the entity (IAS 38.88). A broadcast licence that is renewed indefinitely at negligible cost might have an indefinite useful life. A software platform that faces technological obsolescence within five years has a finite useful life.

Finite-life intangible assets are amortised over their useful life (IAS 38.97). Indefinite-life intangible assets are not amortised but must be tested for impairment annually under IAS 36 and whenever there is an indication of impairment (IAS 38.108). The classification determines whether amortisation expense hits profit or loss or whether the asset is carried at cost (or revalued amount) until impairment occurs.

The audit risk is management’s incentive to classify an asset as indefinite-life to avoid amortisation charges. IAS 38.90 lists factors to consider: the expected usage, typical product life cycles for similar assets, technical or technological obsolescence, stability of the industry, expected actions by competitors, the level of maintenance expenditure required to obtain the expected future economic benefits, the period of control over the asset, and whether the useful life depends on the useful life of other assets.

For most intangible assets in mid-tier entities (capitalised development costs, customer relationships from acquisitions, software licences), the useful life is finite. Indefinite-life classification should be rare and supported by strong evidence that no foreseeable limit exists. If the client classifies a capitalised software platform as indefinite-life, challenge the assessment: what is the technology stack, how quickly does the relevant technology evolve, and when will the platform require a fundamental rebuild rather than incremental updates?

IAS 38.109 requires the entity to review the useful life of an indefinite-life intangible asset each period to determine whether events and circumstances continue to support the classification. A change from indefinite to finite is treated as a change in accounting estimate under IAS 8 and is not retrospective.

Amortisation method and the IAS 38.98 rebuttable presumption

IAS 38.97 requires the depreciable amount of an intangible asset with a finite useful life to be allocated on a systematic basis over its useful life. IAS 38.98 lists the methods: straight-line, diminishing balance, and units of production. The method should reflect the pattern in which the asset’s future economic benefits are expected to be consumed.

IAS 38.98A introduces a rebuttable presumption that a revenue-based amortisation method is inappropriate. This means the entity cannot amortise an intangible asset based on the revenue generated by the activity in which the asset is used, unless the asset is expressed as a measure of revenue (a concession agreement that expires after a fixed amount of revenue is earned, for instance) or the entity can demonstrate that revenue and the consumption of economic benefits are highly correlated.

Most clients use straight-line. That’s usually acceptable for software, customer relationships, and licences, but question it for assets where the benefit is clearly front-loaded. A customer relationship acquired in a business combination typically generates declining revenue as customers attrite over time. A diminishing balance method might better reflect the consumption pattern. If the client uses straight-line and the customer attrition data shows a clear declining curve, the amortisation method may not comply with IAS 38.97.

Your working paper should document the amortisation method selected, the rationale for why it reflects the consumption pattern, and the useful life. For assets acquired in business combinations, cross-reference the useful life to the assumptions in the purchase price allocation.

Derecognition and the residual value trap

IAS 38.112 requires derecognition of an intangible asset on disposal or when no future economic benefits are expected from its use or disposal. The gain or loss is the difference between the net disposal proceeds and the carrying amount. Straightforward.

The trap is the residual value assumption. IAS 38.100 states that the residual value of an intangible asset with a finite useful life is assumed to be zero unless there is a commitment by a third party to purchase the asset at the end of its useful life, or there is an active market for the asset and the residual value can be determined by reference to that market and it is probable that such a market will exist at the end of the asset’s useful life.

In practice, the residual value of almost every intangible asset in a mid-tier entity should be zero. Capitalised development costs for a bespoke software platform have no active market. Customer relationships cannot be sold separately (in most cases). Internally generated brand names fail the recognition criteria entirely under IAS 38.63. If your client has assigned a non-zero residual value to an intangible asset, the burden of evidence is on the client to demonstrate either the third-party commitment or the active market.

A non-zero residual value reduces the depreciable amount and therefore reduces the annual amortisation charge. This is a common earnings management technique: set a residual value of 20% on a capitalised software asset and the amortisation charge drops by 20% per year. Unless the client can point to a committed buyer or an active market, the residual value should be zero.

Worked example: Dekker Software B.V.

Dekker Software B.V. is a Dutch SaaS company with €22M annual recurring revenue. In 2024, Dekker spent €1.8M on its next-generation analytics platform (“Dekker Insight”). The project ran from February to November 2024. Dekker’s CTO signed off on technical feasibility on 1 May 2024 after the prototype passed integration testing. The board approved the project budget on 15 March 2024. Dekker has 14 paying customers on a waiting list for the new platform, and its existing sales team will distribute it. Dekker’s development team uses Jira for time tracking at the project and task level. Total expenditure from 1 February to 30 April (research/pre-feasibility phase): €620,000. Total expenditure from 1 May to 30 November (post-feasibility development): €1,180,000. Dekker depreciates the asset straight-line over five years with zero residual value. The platform went live on 1 December 2024.

Step 1: Identify the research/development boundary (IAS 38.54, IAS 38.56)

February to April: the team was building and testing a prototype to determine whether the technical approach was viable. This is research-phase activity under IAS 38.54. The €620,000 spent in this period is expensed.

From 1 May onwards: the CTO signed off on feasibility, confirming the prototype passed integration testing. Development-phase activity begins on this date. The engagement team obtains the CTO’s sign-off memo (dated 1 May 2024) and the integration test results report.

Step 2: Test the six IAS 38.57 criteria at 1 May 2024

(a) Technical feasibility: CTO sign-off on 1 May, supported by integration test results. Met.

(b) Intention to complete: board resolution dated 15 March 2024 approving the full project budget through to launch. Met.

(c) Ability to use or sell: Dekker’s existing sales infrastructure and distribution channels are established. 14 customers on the waiting list. Met.

(d) Future economic benefits: 14 signed letters of intent from waiting-list customers, combined expected ARR of €480,000. Existing market demand validated by customer interest. Met.

(e) Adequate resources: approved budget of €1.8M is fully funded from operating cash flow. Development team of eight engineers allocated full-time. Met.

(f) Reliable measurement: Jira time tracking captures hours by project and task. Cost allocation separates Dekker Insight from maintenance work on the existing platform. The engagement team tests a sample of time entries against Jira logs. Met.

All six criteria met from 1 May 2024 onwards.

Step 3: Determine the capitalised amount (IAS 38.65, IAS 38.71)

Capitalised amount: €1,180,000 (expenditure from 1 May to 30 November 2024). The €620,000 incurred before the criteria were met is expensed. IAS 38.71 prohibits reinstating previously expensed amounts.

The team verifies the €1,180,000 against the Jira time reports and supporting cost records (contractor invoices, cloud infrastructure costs directly attributable to the development environment). General overheads (office rent, HR costs) are excluded per IAS 38.67.

Step 4: Test the useful life and amortisation (IAS 38.97)

Dekker depreciates the platform straight-line over five years with zero residual value. The engagement team assesses the useful life: the platform’s technology stack is current, but the SaaS analytics market evolves quickly, with competitors releasing major updates every two to four years. Five years is at the upper end of a reasonable range but supportable given Dekker’s planned update cycle. Zero residual value is correct because no active market exists for bespoke SaaS platforms and no third-party purchase commitment exists (IAS 38.100).

Amortisation for December 2024 (one month): €1,180,000 / 60 months = €19,667.

A reviewer sees the research/development boundary with dated evidence, all six criteria tested individually, the capitalised amount reconciled to source records, and the useful life assessment challenged against market conditions.

Practical checklist

1. For every capitalised development cost on the balance sheet, obtain dated evidence that all six IAS 38.57 criteria were met, and verify the capitalisation start date matches the date the last criterion was satisfied (not the project start date)
2. Test the research/development boundary by reviewing the entity’s own project documentation and challenging which activities fall into each phase (IAS 38.54 through IAS 38.56). If the entity cannot distinguish the phases, all expenditure is expensed under IAS 38.53
3. For intangible assets acquired in a business combination, verify that the purchase price allocation identified all separable and contractual-right intangible assets (IAS 38.12). A large goodwill balance with zero identified intangibles is a red flag
4. Verify the useful life assessment is documented with reference to the IAS 38.90 factors. Challenge indefinite-life classifications: what evidence supports the conclusion that no foreseeable limit exists?
5. Confirm residual values are zero unless the entity can demonstrate a third-party purchase commitment or an active market (IAS 38.100). Non-zero residual values on internally generated intangible assets should be rare
6. For amortisation, verify the method reflects the consumption pattern of economic benefits (IAS 38.97) and that a revenue-based method is not used unless the IAS 38.98A exemption applies

Common mistakes

• Capitalising from the project start date: Capitalising development costs from the project start date rather than from the date all six IAS 38.57 criteria are first met. The AFM’s inspection findings on intangible asset capitalisation frequently cite insufficient documentation of the capitalisation start date and the absence of dated evidence for technical feasibility. This is the single most common deficiency for software and technology entities.
• Failing to reassess useful lives annually: IAS 38.104 requires the amortisation period and method to be reviewed at least at each financial year-end. Entities that capitalised software five years ago using a ten-year useful life often haven’t revisited whether the technology is still expected to generate benefits for the remaining period, particularly when the competitive environment has changed.

Related Ciferi content

Related guides:

Put audit concepts into practice with these free tools:

Frequently asked questions

Further reading and source references

• IAS 38, Intangible Assets: the source standard governing recognition, measurement, amortisation, and derecognition of intangible assets.
• IFRS 3, Business Combinations: requires separate identification and recognition of intangible assets in acquisitions, applying the IAS 38.12 identifiability test.
• IAS 36, Impairment of Assets: applies to annual impairment testing of indefinite-life intangible assets and goodwill.
• ISA 620, Using the Work of an Auditor’s Expert: relevant when evaluating valuation specialists engaged for purchase price allocations.