The capitalise-versus-expense decision for AI spend.
AI capitalisation is recording internal AI investment and spend as an intangible asset on the balance sheet rather than expensing it through the P&L. Under IFRS, IAS 38§57 permits it only once development-phase criteria are met; under US GAAP, ASC 350-40350-40-25 permits it only for qualifying application-development costs, now gated by ASU 2025-06. Most experimentation and pre-training is expensed.
Recognise the spend as an intangible asset and amortise it over its useful life.
Charge the spend to the P&L in the period it is incurred.
Pick a cost line to route it to capitalise, expense or prepaid under IFRS.
The five governing standards
Source-of-record index →Intangible assets, including internally generated intangibles
Internal-use software
Software to be sold, leased or marketed
Cloud computing arrangements that are service contracts
Targeted improvements to internal-use software (ASC 350-40)
Enter from a cost line
Priya's route. Find your GPU, data, labelling or hosting spend and see the default treatment and governing standard.
AI cost taxonomy→Enter from a standard
The auditor's route. Read IAS 38 and ASC 350-40 laid out clause by clause, with the cost lines each one governs.
Standards index→Enter from a treatment
The FP&A route. See what capitalise, expense and prepaid do to the numbers, and which standards mandate each.
Treatments→Questions a controller types
Can AI spend go on the balance sheet instead of the P&L?
Some of it, under conditions. Under IFRS, IAS 38 permits capitalisation only for development-phase costs incurred once all six recognition criteria are met. Under US GAAP, ASC 350-40 permits it for qualifying internal-use software costs once completion is probable, now framed by ASU 2025-06. Research, exploration and pre-training are expensed.
Is fine-tuning an LLM capitalisable?
It can be. Fine-tuning a base model for a defined internal use can reach development phase under IAS 38 or the application-development threshold under ASC 350-40, so costs from that point may be capitalised if the recognition tests are met and no significant development uncertainty remains.
What did ASU 2025-06 change?
ASU 2025-06 replaces the project-stage model in ASC 350-40 with a probable-to-complete recognition threshold and adds a significant-development-uncertainty condition that defers capitalisation of novel or unproven software. It is effective for annual periods beginning after 15 December 2027, with early adoption permitted.