The IAS 38 Framework, Refreshed
IAS 38 (and its UK GAAP equivalent, FRS 102 Section 18) distinguishes between research and development. Research phase expenditure is always expensed. Development phase expenditure must be capitalised where six specific criteria are met: technical feasibility, intention to complete, ability to use or sell, generation of future economic benefits, availability of resources, and reliable measurement of expenditure.
The framework applies to any internally generated intangible asset, including software. The specific tests for software have not changed. What has changed is the range of activities that a growth-stage fintech engineering team is now doing that involve AI, and each of those activities needs to be classified as research (expense), development (capitalise if criteria met), or operations (expense in period).
What Qualifies for Capitalisation
Applying the IAS 38 tests to the four categories of AI activity most common in 2026 growth-stage engineering teams:
Two boundary calls deserve specific attention because they are where policy inconsistency shows up.
The Research-to-Development Trigger
The transition from research (expense) to development (capitalisable) requires an identifiable product with technical feasibility demonstrated. For AI work, this trigger is often documented late or not at all — engineers move fluidly from "let's see if this works" to "we're shipping it in the next release" without a formal design gate. The finance team needs a written product-approval trigger (an internal design gate document, a product manager sign-off email, an approved epic in the product tracker) that dates the transition. Without it, the auditor will push everything into research and expense the lot.
The Development-to-Maintenance Trigger
Once an AI feature is released to production, further tuning is expensed as operating cost. But "released to production" for AI can mean multiple things — behind a feature flag, to a beta cohort, to all customers, generally available. The policy needs to define the specific event that ends the capitalisation window. Common practice: the earlier of (a) 90 per cent user rollout or (b) general availability announcement.
What Costs Go Into the Capitalised Amount
IAS 38 permits capitalisation of directly attributable costs incurred to bring the asset to the condition necessary for its intended use. For AI development, this typically includes:
- Engineering headcount (fully loaded). Salary, on-costs (NI, pension), share-based payment charges, benefits, and directly attributable overhead. Include the time actually spent on capitalisable development, not aggregate engineer time.
- Model training compute. GPU costs during fine-tuning runs. Not costs of running production inference.
- Data labelling and preparation. Contractor spend on training data annotation, in-house data engineering time.
- Third-party model access during development. API calls to base models during the fine-tuning or evaluation phase. Not production inference costs.
- Software licences directly required. Tools like Weights & Biases, evaluation platforms, that are used for the development.
Explicitly excluded: general administrative overhead, marketing spend, training of staff on general AI competence, ongoing production inference, and any expenditure prior to the point at which the six IAS 38 criteria are met.
The Useful Economic Life Problem
Once an amount is capitalised, IAS 38 requires it to be amortised over its useful economic life. For traditional software (a payments module, a customer portal), a three-to-five-year life has been the default. For AI-related intangibles, the useful life question is materially harder because the underlying models change so quickly.
Three considerations set the range:
- Base model lifecycle. If your product depends on a specific base model version, and base models are being superseded every 9 to 12 months, useful economic life is bounded by how long that base model will be supported by the provider. Anthropic, OpenAI, and other providers have been retiring older models on rolling 18 to 24-month cycles.
- Fine-tune portability. A fine-tune of a specific base model is not portable to the next base model — it needs to be redone. This means the useful life of a fine-tuned artefact is bounded by the useful life of the underlying base model.
- Embedding refresh cadence. Embeddings of a static corpus may have a longer useful life than a fine-tune, but if the corpus is refreshed regularly (a knowledge base updated weekly), the embeddings have a shorter useful life.
The important operational point: your policy should specify different useful economic lives for different classes of AI intangible, rather than applying a blanket three-year assumption across all AI-related capitalisation. Auditors are increasingly asking for the justification of the useful life assumption, particularly for fine-tune capitalisation where the base model risk is visible.
"The 2026 capitalisation question is not whether AI development costs qualify — the framework has always accommodated this. The question is whether your useful economic life assumptions still make sense when the underlying base models are being retired on 18-month cycles and your competitors are rebuilding their fine-tunes on new architectures every year."
A Practical AI Capitalisation Policy
A one-page policy that a growth-stage fintech can adopt without extended argument with the auditor:
- Scope: The policy applies to AI-related development including fine-tuning, embedding generation, prompt engineering libraries, agent frameworks, and evaluation harnesses.
- Research-to-development trigger: Capitalisation begins on the date the product management or engineering leadership formally approves a specific feature for build, evidenced by a design document or product ticket at "approved" status.
- Development-to-maintenance trigger: Capitalisation ends on the earlier of 90 per cent user rollout or general availability announcement, whichever is earlier.
- Cost basis: Directly attributable engineering headcount (fully loaded), training compute, data labelling, third-party model access during development, and directly required software licences.
- Time allocation: Monthly engineer time allocation to capitalisable projects agreed by the engineer and the finance team, cross-referenced to ticket / epic activity.
- Useful economic lives: Fine-tunes 18 months, embeddings 12 months (or 6 months if corpus refresh weekly), agent frameworks 3 years, evaluation harnesses 3 years.
- Impairment triggers: Base model retirement, product decommissioning, or material downgrade in production usage triggers impairment review at the next reporting date.
Key Takeaways
- IAS 38 (and FRS 102 s.18) applies to AI development in the same way as any internally generated intangible. The framework has not changed; the range of activities has.
- Fine-tuning for a defined product feature, embedding generation, prompt engineering libraries, and agent frameworks all qualify for capitalisation once the six IAS 38 criteria are met.
- Model selection and evaluation, ongoing production inference, and general staff AI training are all expensed.
- Two boundary triggers need documenting: research-to-development (formal product approval) and development-to-maintenance (90 per cent rollout or general availability).
- Cost basis includes fully loaded engineering headcount, training compute, data labelling, and third-party model access during development. Monthly engineer time allocation is the standard evidence.
- Useful economic lives should reflect the underlying asset: fine-tunes 18 months, embeddings 6-24 months, frameworks and evaluation harnesses 3 years.
- The auditor is now specifically asking about useful life assumptions for AI intangibles. Have the justification written down before the audit rather than during it.