The accounting treatment of AI development costs remains one of the most contested areas in financial reporting. Under IAS 38, internally generated intangible assets can only be recognised on the balance sheet when six specific criteria are met. But IAS 38 was drafted in 1998, when "intangible assets" meant patents and brand names — not neural networks, training data pipelines, and reinforcement learning systems.
This article provides practical guidance for CFOs and accountants facing the capitalisation question. For the broader accounting gap and the emerging FASB/SNA response, see Should You Capitalise Your AI Investment?.
IAS 38 distinguishes between research and development phases. Research costs must always be expensed. Development costs can be capitalised — but only when all six recognition criteria are simultaneously satisfied. There is no partial credit.
The distinction between research and development is critical for AI projects because the boundary is far less clear than for traditional R&D. Training a model to test a hypothesis is research. Refining a validated model for deployment is development. But many AI projects iterate continuously between these phases, making clean separation difficult.
The research/development boundary in AI is not a line — it is a gradient. CFOs must work with technical teams to define project milestones that map to the IAS 38 transition point. Without clear phase gates, all costs default to the research phase and must be expensed.
For traditional software, technical feasibility is typically demonstrated through a working prototype or proof of concept. For AI, the question is more nuanced: when is an AI model technically feasible?
A model that achieves target accuracy on a test dataset may still fail in production due to data drift, edge cases, adversarial inputs, or scaling challenges. Auditors are increasingly sceptical of "feasibility" claims based solely on benchmark performance.
Practical guidance: Define technical feasibility in terms of production-grade performance, not research-grade benchmarks. Document the specific performance thresholds, latency requirements, and reliability standards the model must meet. Do not claim feasibility until the model meets these standards in a production-representative environment.
This criterion is relatively straightforward for most AI projects — if the organisation is investing in development, there is typically a clear intention to deploy. However, exploratory AI projects where the end use is undefined do not satisfy this criterion. "We're building AI capability" is not an intention — "We are building a customer churn prediction model for the retail division" is.
The organisation must have the infrastructure, talent, and operational readiness to deploy the AI system. This is not trivial. Many organisations build AI models that never reach production because they lack MLOps capability, data pipelines, or integration pathways.
| Criterion | Traditional software | AI systems | Key difference |
|---|---|---|---|
| Technical feasibility | Working prototype | Production-grade model performance | AI models may work in lab but fail in production |
| Intention to complete | Project charter | Specific deployment plan | "Building AI capability" is insufficient |
| Ability to use/sell | Infrastructure exists | MLOps, data pipeline, integration ready | Many AI models never reach production |
| Future economic benefits | Revenue or cost savings | Measurable AI-driven improvement | Must demonstrate causation, not correlation |
| Resources available | Budget and team | ML engineers, compute, training data | Data availability is often the binding constraint |
| Reliable cost measurement | Standard project accounting | AI cost attribution | Shared infrastructure makes attribution complex |
The asset must demonstrate probable future economic benefits — either through revenue generation, cost savings, or other measurable improvements. For AI, this requires evidence that the model delivers measurable business impact, not just technical performance.
A logistics company develops an AI routing optimisation system. During the development phase, the model demonstrates a 12% reduction in fuel costs on historical route data. The company runs a 60-day live pilot on 20% of its fleet, confirming an 11% reduction in actual fuel costs. At this point — with live operational evidence of economic benefit — the criterion is satisfied. The development costs incurred after the pilot validation (but not before) are eligible for capitalisation.
The organisation must have sufficient technical, financial, and human resources to complete the project. For AI, the binding constraint is often data rather than budget. If the training data required for the model is not available, or if key ML engineering talent has departed, this criterion may not be met regardless of financial resources.
AI development costs must be attributable to the specific asset. This is challenging when AI teams work on shared infrastructure, when compute resources are pooled across multiple projects, or when data preparation serves multiple models.
Practical guidance: Establish project-level cost tracking from day one. Tag cloud compute costs to specific projects. Track ML engineer time allocation at the project level. Without granular cost tracking, capitalisation is not possible because the "reliable measurement" criterion fails.
Under FRS 102, UK companies have a choice: they can follow IAS 38 treatment for development costs or expense all R&D. Many smaller companies choose the simpler expensing approach, but this understates the balance sheet value of genuine AI assets. See our IAS 38 explained guide for the full standard.
Establish explicit milestones that mark the transition from research to development. Document what "technical feasibility" means for each AI project in specific, measurable terms.
Tag all costs — compute, data preparation, engineer time, third-party services — to specific AI projects. Without this, criterion 6 (reliable cost measurement) automatically fails.
Run controlled pilots or A/B tests to demonstrate that the AI system delivers measurable business impact. Document results with sufficient rigour to satisfy auditors.
Capitalisation requires all six criteria to be met at the same point in time. If any single criterion is not satisfied, all development costs for that period must be expensed.
There are AI development scenarios where capitalisation is clearly inappropriate, regardless of the investment magnitude:
In these cases, expensing is not just the conservative choice — it is the correct accounting treatment under IAS 38. The Opagio Growth Platform helps organisations track and categorise AI investments across the capitalisation boundary, ensuring accurate financial reporting while still recognising the strategic value of AI spending.
Capitalising AI development costs under IAS 38 is possible but demanding. The six criteria were not designed for AI, and applying them requires careful interpretation, robust evidence, and meticulous cost tracking. Most organisations will find that the majority of their AI spending falls in the research phase and must be expensed. The minority that qualifies for capitalisation requires production-grade evidence of technical feasibility and economic benefit. Get the accounting right — your intangible assets deserve accurate recognition.
David Stroll is Co-Founder and Chief Scientist at Opagio. His research spans productivity economics, intangible capital measurement, and accounting standards for technology assets. Learn more about the Opagio team.
AI investments create complex financial reporting challenges across recognition, measurement, disclosure, and impairment. This practical guide helps CFOs navigate the accounting treatment of AI spending, from capitalisation decisions to board-level disclosure.
Read more →
Under current accounting standards, most AI development costs are expensed immediately — treated as period costs rather than capital investments. Yet new FASB guidance (ASU 2025-06) and SNA 2025 recognised data as productive capital. This creates a widening gap between economic reality and financial reporting. Here is how to navigate it.
Read more →
A comprehensive guide to IAS 38 Intangible Assets: the recognition criteria, measurement rules, capitalisation requirements, and amortisation treatment. Includes practical guidance on R&D capitalisation and the gap between IAS 38 and economic reality.
Read more →Get the latest insights on intangible asset growth and productivity delivered to your inbox.
Book a free consultation to see how the Opagio Growth Platform can help your business.