The question is deceptively simple, but the answer has profound implications for how enterprise value is measured and reported. When a company invests £50 million to train a proprietary language model, should that expenditure be expensed immediately as a period cost, or capitalised as an intangible asset on the balance sheet? Under current IFRS and US GAAP, the answer in most cases is: expense it. Under the emerging consensus reflected in SNA 2025 and the new FASB guidance, the answer is increasingly: it depends.
This is the accounting gap at the heart of the AI era. The standards by which publicly listed companies report their financial position have not caught up with the economic reality of AI investment. The result is systematically understated asset values, distorted return on capital metrics, and capital allocation decisions made on incomplete information.
IAS 38 (International Accounting Standard 38) governs the recognition and measurement of intangible assets. It is the baseline framework under which most non-US companies operate. The standard is neither hostile to capitalising intangible assets nor permissive — it requires six criteria to be met before an asset can be recognised on the balance sheet.
An intangible asset arising from development activity can only be capitalised if:
Technical feasibility: The entity must intend to and be able to complete the intangible asset so that it will be available for use or sale. For AI systems, this means the technical team must have demonstrated that the model can achieve specified performance targets, not merely that development is theoretically possible.
Intention to complete: The entity must have the intent to complete development and use or sell the asset. This is not merely future possibility — there must be contemporary evidence of committed plan. For a company training a model but uncertain whether it will deploy it, this criterion fails.
Ability to use or sell: The entity must have the ability to use the intangible asset internally or to sell it to a third party. For a proprietary model with no external market and unclear internal use case, this becomes contentious.
Future economic benefits: The entity must be able to demonstrate how the asset will generate future economic benefits — whether through cost reduction, revenue generation, or competitive advantage. This is where AI spending becomes difficult to defend under current standards. Training a model creates an asset, but quantifying its future economic contribution is inherently uncertain.
Adequate resources: The entity must have sufficient technical, financial, and other resources to complete development and use or sell the asset. A startup with £2 million invested in training might struggle to demonstrate this for a £50 million model.
Reliable measurement: The entity must be able to reliably measure the development costs attributable to the asset. This is theoretically straightforward — track compute, engineering time, data acquisition — but becomes complex when development spans multiple projects or when compute is shared across AI and non-AI development.
IAS 38 is theoretically applicable to AI development costs, but practical application is fraught. The standard was written for software development (code is measurable, functionality is verifiable) and patent applications (outcomes are definable). AI development is messier: the outputs are probabilistic, reusable across multiple applications, and their future value is speculative.
Consider a company investing in three AI projects. The decision process under IAS 38 looks like this:
| Project | Investment | Technical Feasibility | Intention | Ability to Deploy | Economic Benefit | Resources | Measurement | Decision |
|---|---|---|---|---|---|---|---|---|
| Fine-tuning existing model for customer support | £50K | Yes: proven methodology | Yes: documented roadmap | Yes: internal deployment in Q2 | Measurable cost savings in support | Yes | Yes: engineering time + compute tracked | Capitalise |
| Exploratory R&D into emerging model architecture | £500K | Uncertain: proof-of-concept stage | Uncertain: may not proceed | Unclear: might not be deployable | Speculative: outcome unknown | Limited resources allocated | Difficult: mixed with other research | Expense |
| Training proprietary LLM for competitive advantage | £50M | Yes: milestones achieved | Yes: core strategic asset | Yes: intended for product integration | Strong: trained model will improve product | Yes: dedicated team, committed budget | Difficult: complex allocation, multiple uses | Capitalise or Expense? |
The third case is where current standards break down. A £50 million investment in training a proprietary language model that will power your product for the next five years is economically an asset — it will generate returns over an extended period and has competitive value. Yet IAS 38's requirement for "reliable measurement" of development costs becomes problematic when a single model is used across multiple products, improved continuously, and its contribution to specific revenue streams is probabilistic.
In September 2025 the US Financial Accounting Standards Board (FASB) issued ASU 2025-06, which amends the internal-use software guidance in ASC 350-40. It is not an AI standard: it applies to all software a company develops for its own use, which includes most AI models built or fine-tuned for internal operations or offered to customers as a hosted service. Software developed to be sold or licensed stays under ASC 985-20.
The change is to when capitalisation starts. ASU 2025-06 removes the project stages (preliminary project, application development, post-implementation). For annual periods beginning after 15 December 2027 (calendar 2028 for December year ends, with early adoption permitted), costs are capitalised once:
Completion is not probable while there is significant uncertainty about the development itself, for example where the software has novel or unproven functions or features that coding and testing have not yet resolved, or where its significant performance requirements are still being identified or substantially revised. For AI work, that is often the position during model training and experimentation.
A financial services firm spends £400K fine-tuning a language model for anti-money laundering detection, for its own use. Under ASU 2025-06, the cost is capitalised from the point management has committed funding and completion is probable, but not while it is still unclear whether the model can meet its detection performance requirements; costs during that period are expensed. Under IAS 38, the same project is capitalised only from the date all six criteria in IAS 38.57 are demonstrated, and only if the firm controls the model.
The System of National Accounts (SNA 2025) is the global standard for national economic accounting, followed by statistical offices including the ONS, Eurostat, and the BEA. In its 2025 update, SNA 2025 made a watershed decision: data is now recognised as a productive capital asset, and AI systems built on that data are treated as capital formation rather than intermediate consumption.
This has profound implications. When a company invests in collecting, cleaning, and structuring data for use in AI training, or when it invests in the AI system itself, these are now treated by national accountants as capital formation (investment) rather than operating expenditure. This is the opposite of current financial reporting standards, where most of this spending is expensed.
SNA 2025 implementation varies by country. The ONS (UK) will begin reflecting data capitalisation in national accounts from Q3 2026. Eurostat (EU) has committed to adoption across member states by 2027. This means published productivity statistics will begin to shift — organisations will appear more capital-intensive and labour-productivity statistics will improve.
The gap between SNA 2025 (data and AI systems are capital) and IAS 38/ASC 350 (expense most AI costs) is now explicitly documented. For companies reporting under IFRS in countries that follow SNA 2025 methodology, this creates a reporting anomaly: the national accounts will show rising intangible capital, while the company's financial statements will show these same investments as expensed costs.
Even where capitalisation is theoretically permitted, applying it in practice requires overcoming several technical challenges.
Allocation across multiple projects: A compute cluster training multiple models simultaneously generates costs that must be allocated to individual projects. How do you allocate £50 million in compute spending across five different models being trained in parallel? Standard methods (by GPU hours, by parameter count, by training time) are available but imperfect.
The problem of continuous improvement: An AI system is rarely complete and static. The model is trained initially, then fine-tuned, then updated with new data, then re-trained with improved algorithms. Which costs are capitalised (part of the initial asset), and which are expensed (maintenance and improvement of existing asset)? Current standards offer guidance, but application is contentious.
Amortisation and useful life: Once capitalised, an AI model must be amortised over its useful life. What is the useful life of a language model? Three years? Five years? The answer depends on expected technological obsolescence, competitive dynamics, and intended usage. Frontier AI models have historically shortened useful lives (new models render previous generation partly obsolete), but this may be changing as model quality plateaus.
Impairment testing: An expensed cost cannot be impaired — it is already gone. A capitalised asset must be tested for impairment whenever there is evidence of loss of value. If a model is trained at cost and subsequently proves less effective than anticipated, or is superseded by a cheaper alternative, the capitalised amount must be written down.
Auditors are the gatekeepers of capitalisation. A company that proposes to capitalise £20 million in AI development costs will face significant auditor scrutiny. The audit firm must be satisfied that the IAS 38 or ASU 2025-06 criteria are met — that the asset is technically feasible, that its future economic benefit is probable, that costs are reliably measured, and that there is credible evidence of intended deployment. This is not impossible, but it requires rigorous documentation and a compelling narrative. Companies seeking to capitalise must build the evidence base before the investment, not after.
A technology company commits £100 million to training a large language model from scratch. They build a dedicated team of 50 researchers and engineers. They acquire compute capacity for two years. They commit to integrating this model into their product line.
IAS 38 treatment: The company must capitalise this investment from the date it can demonstrate:
Outcome: Capitalisation is required from that date; spend before it stays in profit or loss (IAS 38.71). If the criteria are met from the start, the £100M is recorded as an intangible asset (technology capital) on the balance sheet. It is then amortised over the expected useful life (likely 4-5 years for a frontier model). Annual amortisation expense is £20-25M.
ASU 2025-06 treatment (US GAAP, from 2028): if the model is used internally or offered as a hosted service, costs are capitalised once funding is committed and completion is probable, and not while significant development uncertainty remains, which for a model trained from scratch can last well into the project. A model sold or licensed to customers falls under ASC 985-20 instead.
A professional services firm uses OpenAI's GPT-4 API but decides to fine-tune it with proprietary firm knowledge to improve its performance on firm-specific terminology and methodologies. They invest £50K in data preparation, fine-tuning, and integration.
IAS 38 treatment: This is the boundary case. Technically, the six criteria can be met:
However, auditors would likely challenge capitalisation. The asset value is questionable — a fine-tuned model is vendor-dependent, not independently valuable. If the vendor discontinues the base model, the fine-tuning becomes worthless. The investment is also at the lower end of the scale where capitalisation overhead (tracking, amortisation, impairment testing) may exceed the administrative benefit.
Likely outcome: Expensed. A model fine-tuned and hosted on a vendor's API is usually a service the firm does not control, so under the IFRIC agenda decisions the cost is expensed (see SaaS configuration costs under IAS 38). Only if the firm controlled the resulting software, and the six criteria were met, would IAS 38 require capitalisation.
ASU 2025-06 treatment (US GAAP, from 2028): implementation costs of a hosting arrangement follow the same ASC 350-40 rules, so they are capitalised once funding is committed and completion is probable, and expensed over the term of the arrangement. The same spend is usually expensed under IFRS.
A financial services firm allocates £500K to an exploratory research project investigating whether AI can improve fraud detection in payment systems. The outcome is uncertain. They may succeed and deploy the system, or they may conclude that the AI approach is inferior to existing rule-based systems.
IAS 38 treatment: Capitalisation is not defensible.
Outcome: Expense as R&D cost. This is correct treatment. Exploratory research has uncertain outcomes and is properly expensed as incurred.
The capitalisation question and the valuation question are related but distinct. Even if a cost is expensed under current accounting standards, the asset it creates may have genuine value.
Consider the example of the £50 million proprietary language model. Suppose that under IAS 38, the company concludes it cannot reliably measure the future economic benefit and decides to expense the cost. From a balance sheet perspective, the asset is invisible — an intangible asset worth £50 million has not been recorded.
But from a valuation perspective, the asset is very real. If the company is sold, the buyer will pay for the proprietary model. They will conduct due diligence on its technical quality, its competitive advantage, its integration into the product, and its expected useful life. They will then apply a valuation methodology — either cost approach (what did it cost to build), market approach (what do comparable models trade for), or income approach (what value does it generate) — to determine its contribution to enterprise value.
The buyer's valuation of the model might be £50 million (cost recovery), or £200 million (income approach, if the model is critical to product differentiation), or £10 million (if better alternatives have emerged since it was built).
The gap between what the balance sheet shows (nothing — it was expensed) and what the market values (potentially substantial) is where intangible asset measurement becomes critical for M&A, PE transactions, and investor valuation.
Expensing under accounting standards does not diminish economic value. It reflects conservative accounting practice. But it creates a measurement gap: investors and acquirers must look beyond the balance sheet to value the intangible assets that have been created by expensed spending. This is where structured intangible asset valuation becomes essential to informed capital allocation.
The gap between IAS 38, US GAAP and SNA 2025 is real, but no change to IFRS is scheduled. The IASB has a research project on intangible assets under way (see what is changing in IAS 38), and it has not published proposals; nothing in it is tied to ASU 2025-06.
In the interim, IFRS reporters have no election: AI development spending that meets all six IAS 38.57 criteria must be capitalised, and spending that does not must be expensed. The judgement lies in dating when the criteria were met and keeping the evidence. SNA 2025 changes national accounts, not company accounts, so it is no basis for capitalising under IFRS.
The commercial reality is shifting toward capitalisation. Companies that are serious about AI as a capital asset — training proprietary models, building moats through technology capital — need the evidence that lets their balance sheets reflect it where the standards allow.
For boards and CFOs, the decision on AI capitalisation is not purely an accounting one. It is a signal about how the organisation views AI: as an operating expense to be minimised, or as a capital investment to be measured, managed, and valued.
David Stroll is Co-Founder and Chief Scientist at Opagio, specialising in productivity measurement frameworks and the economics of intangible capital. His work draws on SNA 2025, OECD, and ONS methodologies.
IAS 38 sets six criteria for capitalising development costs, but applying them to AI projects is fraught with ambiguity. This article maps each criterion to AI development realities and provides practical guidance for CFOs and accountants navigating the recognition question.
Read more →
A billion-fold increase in computing power. The internet, smartphones, and now AI. Yet TFP growth averaged just 1.0% — less than the Oil & Electricity era achieved with far simpler technology. Welcome to the IT productivity paradox. Lesson 5 of the Productivity 250 series.
Read more →
A practical guide to software capitalisation under IAS 38 and ASC 350-40, plus valuation methods for software as an intangible asset. Covers when to capitalise, how to value, and common mistakes in software asset accounting.
Read more →Get the latest insights on intangible asset growth and productivity delivered to your inbox.
Take the free intangible asset assessment to see where your business stands across Opagio 12.