Training the model
Can an entity capitalise the compute cost of fine-tuning an AI model under IAS 38, and if so, from what point?
A year ago, many finance teams met artificial intelligence as a subscription line. Now a growing number are building with it. They take an open-weights model, fine-tune it on their own documents, and put the result in front of customers. The invoices have changed shape too. A fine-tuning project still pays engineers, but it also buys licensed datasets, pays people to label data, and runs up a cloud compute bill that can rival the payroll.
IAS 38 has a clear rule for internal projects: expense research, capitalise development once six criteria are met. The rule was written for projects that move from a design to a build. Machine learning does not work like that. Teams run experiments, keep the runs that work and repeat. So the question every preparer with an AI project now faces is where research ends, what the asset actually is, and which of those costs belong in it. The IASB is looking at intangibles, but no answer will arrive in time for December 2026.
Why the issue arises
Three features of AI work strain the IAS 38 model.
The first is the phase boundary. Paragraph 52 splits an internal project into a research phase and a development phase. In a conventional software build, the line is usually a signed-off design. In machine learning the "design" is partly discovered by training. A team may not know whether a model can reach the required accuracy until it has trained one, and every training run looks like an experiment.
The second is the asset itself. A fine-tuned model is a set of weights layered on someone else's base model. Sometimes the entity holds those weights on its own systems. Sometimes they never leave the provider's platform. Whether there is anything the entity controls is a real question, not a formality.
The third is cost attribution. Compute is billed by the hour or by the month, across experiments, failed runs and the final model alike. Data costs sit somewhere between buying an asset and paying for a service. None of this maps neatly to the examples in IAS 38.
What is clear
Quite a lot, once you strip the problem back to the standard.
There is no IFRIC agenda decision on AI models. The closest are the two cloud computing decisions: a customer with a right only to access a supplier's hosted software receives a service, not an intangible asset (IFRIC Update, March 2019), and configuring or customising that software usually creates no asset for the customer because it does not control the software (IFRIC Update, March 2021).
Research expenditure is expensed when incurred, and no asset arises from the research phase (IAS 38.54).
An intangible asset arising from development shall be recognised if, and only if, all six criteria in paragraph 57 are demonstrated. Once they are, capitalisation is required, not optional (IAS 38.57).
If an entity cannot distinguish the research phase from the development phase, it treats the whole project as research (IAS 38.53).
Cost runs from the date the criteria are first met. Earlier costs stay expensed and cannot be reinstated (IAS 38.65, 38.71).
The cost of an internally generated asset includes the costs of materials and services used or consumed in generating it, employee benefits arising from its generation, and amortisation of licences used to generate it (IAS 38.66(a), (b) and (d)). Cloud compute consumed in training is a service consumed. In principle, it qualifies.
General overheads (unless directly attributable to preparing the asset for use), identified inefficiencies and the cost of training staff to operate the asset are excluded (IAS 38.67).
Before any of that, the item must meet the definition of an intangible asset: identifiable and controlled, with expected future economic benefits (IAS 38.8, 38.12, 38.13, 38.18).
The IASB has not settled the AI question either. Its intangible assets project uses software as a service and agile software development as test cases. Rather than make AI and data separate test cases, the project uses them as examples when exploring similar principles and testing potential solutions. The IASB planned to decide the project's direction in the fourth quarter of 2026. Any change to IAS 38 is likely to be years away.
The competing readings
The control question is usually answerable on the facts. The phase boundary is where judgement lives. Three readings are in circulation.
Reading 1: the proof is the finished model. Technical feasibility (IAS 38.57(a)) cannot be shown until the production model meets its target on validation data. Every training run before that point is research. Under this reading, almost nothing is capitalised, because once the final model passes its tests, the expensive work is over.
Reading 2: the proof is the pilot. Feasibility is shown when evidence from a pilot, such as a training run on a sample of the data, shows the target is achievable with a chosen base model, method and data pipeline, and the team stops redesigning the approach. After that point, full-scale training is the construction and testing of a chosen alternative, which paragraph 59 lists as development. Its compute is capitalised, provided the other five criteria are met.
Reading 3: iterative means indistinguishable. Machine learning is experimental from start to finish, so no clean boundary exists. Paragraph 53 applies and the whole project is expensed.
Why reading 1 fails
Reading 1 confuses feasibility with completion. Paragraph 57(a) asks for "the technical feasibility of completing" the asset. That is a forward-looking test. Paragraph 59(a) lists the "design, construction and testing of pre-production or pre-use prototypes and models" as development. The "models" there are design models, not machine-learning models, so the paragraph works by analogy only. But the analogy is close: testing a pre-use prototype is a development activity, and a pilot training run at reduced scale is the nearest machine-learning equivalent of a prototype, or of a pilot plant below commercial scale (IAS 38.59(a), (c)). If feasibility could only be shown by a finished, tested model, the paragraph 57 test could never be passed until the costs had already been spent. Nothing could ever be capitalised, and IAS 38 would become an expense-everything rule for this kind of asset.
KPMG Switzerland's published guidance on AI software takes the view that feasibility is usually shown when a model meets its performance target on validation data and the design has stopped changing fundamentally. That is a sensible test, and it refers to a model, not to the production model. Read with paragraph 59, we think a pilot that meets the target at reduced scale can satisfy it. If the test is read as requiring the production model itself, it collapses into reading 1.
Reading 3 fails as a default for a different reason. Paragraph 53 is a consequence, not a choice. It applies when the entity cannot distinguish the phases. It does not let an entity that can distinguish them expense its development costs, because paragraph 57 says the asset "shall" be recognised. Reading 3 is the right answer only where the phases genuinely cannot be told apart. Where they can, but the evidence is missing, the result is the same for a different reason: the paragraph 57 criteria cannot be demonstrated. In practice, that will be the outcome for many first projects, because nobody wrote down when the approach was frozen.
Reading 2 has a genuine weakness. A pilot on a small sample does not always predict full-scale results. A model that hits 92% on a 5% sample may plateau below target on the full data. The answer is not to reject reading 2 but to apply it honestly: feasibility is shown when what remains is engineering, not discovery. If the team still expects to change the base model or the method depending on how training goes, the project is still in research.
Worked example: Fastnet Legal Technologies Ltd
Fastnet Legal Technologies Ltd, a Cork software company with a 31 December year-end, builds a contract-review assistant for law firms. It fine-tunes an open-weights language model whose licence permits commercial use and modification. It trains adapter weights on rented cloud GPUs in its own cloud account and stores the weights in its own code repository. Staff are under confidentiality obligations. The weights can be licensed to others. So the model is identifiable and controlled (IAS 38.12(a), 38.13, 38.14).
Its 2026 timeline is as follows.
January to March (research). The team compares three base models, tests prompting without fine-tuning and runs small experiments. Compute costs €140,000 and staff €180,000.
31 March (feasibility). A pilot fine-tuning run on 5% of the data reaches 92% accuracy on clause extraction on a held-out test set, against a target of 90%. The board approves the budget and the product plan, and the technical lead records that the base model, method and data pipeline are frozen. Fastnet treats 1 April as the date all six criteria in paragraph 57 are met.
1 April (dataset). Fastnet buys a perpetual, non-exclusive licence to an annotated dataset of contracts for €360,000. It holds a copy on its own systems. This is a separately acquired intangible asset (IAS 38.25–27). Fastnet expects to use the data for retraining and for successor models, so it amortises the licence over three years, at €10,000 a month, longer than the two-year life of the first model.
April to August (development). Full-scale training compute costs €420,000. Of that, €60,000 relates to two runs abandoned because of a bug in the data pipeline. In-house data labelling costs €150,000, ML engineers €208,000 and dataset amortisation €50,000. Fastnet also allocates €40,000 of office overhead to the project and spends €15,000 training its customer-support staff on the new tool.
1 September (available for use). The model goes live. Fastnet estimates a useful life of two years with no residual value. From September to December it spends €45,000 on monthly retraining to keep accuracy at its launch level.
Under reading 2, the development-phase costs split as follows.
Cost | €000 | Capitalised | Expensed |
Research phase | 320 | 320 | |
Training compute | 360 | 360 | |
Abandoned runs | 60 | 60 | |
Data labelling | 150 | 150 | |
ML engineers | 208 | 208 | |
Dataset amortisation | 50 | 50 | |
Office overhead | 40 | 40 | |
Staff training | 15 | 15 | |
Total to 31 August | 1,203 | 768 | 435 |
The arithmetic: €360,000 + €150,000 + €208,000 + €50,000 = €768,000 capitalised. The compute, labelling and engineering costs are services consumed and employee benefits arising from generating the model (IAS 38.66(a) and (b)). The dataset amortisation is amortisation of a licence used to generate it (IAS 38.66(d)). The abandoned runs are identified inefficiencies, the overhead is a general overhead and the support-staff training is training staff to operate the asset, so all three are expensed (IAS 38.67(a)–(c)). Development-phase costs total €883,000, of which €115,000 is expensed.
Amortisation starts on 1 September, when the model is available for use (IAS 38.97): €768,000 ÷ 24 months = €32,000 a month, or €128,000 for September to December. The carrying amount at 31 December is €640,000. The retraining keeps the model at its launch accuracy, so it maintains the asset rather than enhancing it, and is expensed (IAS 38.20). The dataset amortisation after launch, €40,000 for four months, also goes to profit or loss. The dataset's carrying amount is €270,000 (€360,000 less nine months at €10,000).
Under reading 1, feasibility is reached only when the production model passes its final tests in late August. Effectively all €883,000 of development-phase cost is expensed, and no material model asset is recognised. The table treats it as nil.
Charge | Reading 1 | Reading 2 |
Research phase | 320 | 320 |
Development phase | 883 | 115 |
Retraining | 45 | 45 |
Dataset amortisation | 40 | 40 |
Model amortisation | 128 | |
Total charge | 1,288 | 648 |
The difference, €640,000, is the model's carrying amount at 31 December. It reverses over the next 20 months as amortisation. The total cost is the same either way. What changes is when it hits profit or loss, and whether the balance sheet shows the asset the company has just spent most of a year building.
What to do
Settle control first. Map where the weights live, who can run them and what the base-model licence allows. If the model exists only on a provider's platform and can be used only through its interface, start from the 2019 and 2021 cloud computing decisions.
Write a policy that defines the feasibility event for AI projects: the evidence required (for example, a pilot meeting the target on held-out data), who signs it off, and what "frozen" means for base model, method and data pipeline.
Record the date contemporaneously. Paragraph 71 prevents costs expensed before the criteria could be demonstrated from being reinstated later, and evidence assembled after the event is weak evidence of when they were met.
Tag compute by project and by run. Mark experimental, abandoned and production runs, so the cloud bill can be split.
Assess each dataset on its own: what was acquired, whether the entity holds a copy, and for how long it can use it.
Define, in advance, what counts as enhancement and what counts as maintenance for retraining.
Disclose the judgement where it is significant (IAS 1.122, or IAS 8.27G once IFRS 18 applies), and the aggregate research and development expense (IAS 38.126).
Smaller questions
What if the model is fine-tuned on the provider's platform? Some providers fine-tune their own model on the customer's data and host the result. The customer can call it but cannot take the weights. That looks like the customisation in the March 2021 decision. The customer usually has no resource it controls separately from the provider's model, so the costs are expensed when the services are received, unless they buy something that is itself an asset, such as additional code the customer controls. If the fine-tuning service is not distinct from the ongoing access and is paid in advance, the 2021 decision points to a prepayment expensed over the access period.
Is the training data an asset? A dataset bought outright, or licensed with substantive rights and held by the entity, can be a separately acquired intangible asset. A subscription to a data feed is more likely a service. Data the entity builds internally is unlikely to be recognised on its own. Where it qualifies, its cost is part of the model. Datasets about the entity's own customers may face a further obstacle. Internally generated customer lists "and items similar in substance" cannot be recognised (IAS 38.63).
Does "training" in IAS 38 mean model training? No. IAS 38.5, 38.15, 38.67(c) and 38.69(b) refer to training people. Training a model is a different activity, and the word gives no reason to expense model compute.
Are failed runs always expensed? Not always. An experiment in the research phase is research. A run abandoned in development because of an avoidable error, like Fastnet's pipeline bug, is an identified inefficiency (IAS 38.67(b)). A planned run that tests a hyperparameter setting within the chosen approach is part of the normal cost of development. The line is judgement, which is why run-level tagging matters.
What about a model still in development at year-end? An intangible asset not yet available for use must be tested for impairment every year, whether or not there is an indicator (IAS 36.10(a)). A capitalised project that is half-trained at 31 December needs a test.
How long is the useful life? Short. Base models are superseded quickly, and IAS 38.104 requires the period to be reviewed at least at each year-end. Two to three years is easier to defend than five. The release of a much better base model can also be an impairment indicator for the cash-generating unit.
Why it matters for the 2026 year-end
Many groups will be closing their first full year with a live AI product. The capitalised amounts may be material for the first time, and the starting date for capitalisation is a judgement auditors will test from scratch. Groups that have expensed everything so far cannot change their minds for earlier spend. Paragraph 71 rules that out, unless the earlier expensing was an error, which is an IAS 8 question, not a change of mind. But they can set a policy now that applies to new projects and to the development phase of current ones.
The IASB's work may eventually change the definition and recognition criteria in IAS 38. Until then, the standard as it stands has to be applied to the costs being incurred today, and this year's financial statements will show which reading each entity has taken.
What the auditor will look at
The control analysis: base-model licence terms, where the weights sit and whether the entity can run them without the provider.
Evidence of the feasibility date: pilot results, the held-out test design, board minutes and the record that the approach was frozen, all dated before capitalisation began.
The compute split: cloud invoices traced to projects and runs, with experimental and abandoned runs excluded.
Dataset contracts, to support recognition, the amortisation period and the amount charged to the model.
Capitalised staff time, checked against timesheets and job roles, with overhead and support-staff training excluded.
The useful life, the impairment test for any asset not yet available for use, and the disclosures.
Work it through with our tools
Many AI projects fail the capitalisation test not on the standard but on the paperwork. The Tipping Point, our IFRS judgement navigator, helps you weigh the indicators for judgements like this one, see where the balance tips, and draft the significant judgements note. It is free with a member account.
Once the model is on the balance sheet, it is tested with the business it supports. Our CGU impairment template tests one cash-generating unit in Excel: carrying amount, value in use from a five-year forecast, allocation of any loss, headroom, a sensitivity grid and a draft note.
IAS 38 Intangible Assets in the Learning Hub: recognition, research versus development, amortisation and revaluation.
IAS 36 Impairment of Assets in the Learning Hub: testing assets not yet available for use and cash-generating units.
Year-End 2026 Reporting Update: our CPD course for the December close.
Disclosure Review: check the intangibles note and the judgements disclosure before the auditor does.
IAS 38 never mentions machine learning, but it already holds the answer to most of the question. Control decides whether there is an asset, the pilot decides when development starts, and the records decide whether anyone will believe you. Fine-tuning is development once the approach is fixed. The compute that builds the model belongs in the model.
Fastnet Legal Technologies Ltd is fictional. Figures are in euro. References are to IAS 38 Intangible Assets and IAS 36 Impairment of Assets.
