Accounting for AI software investments

Under IFRS, AI software costs are typically assessed under AASB 138. Research activities are expensed as incurred, development costs may be capitalised only when AASB 138 recognition criteria are met simultaneously. For AI projects, the most challenging criteria often relate to control and technical feasibility. The latter is generally demonstrated when a model achieves its target performance on validation data and the underlying architecture is no longer being fundamentally redesigned. However, all recognition criteria must be satisfied before capitalisation can begin. 

Generally, no. API access arrangements are typically service contracts under the IFRIC Agenda Decisions on cloud computing arrangements. The customer does not control the underlying model; it purchases the right to send requests and receive outputs.

Exceptions may arise where the contract grants substantive rights, for example, a perpetual license under which the model is delivered to the entity and can be deployed on its own infrastructure independently of the provider. 

Where API access is used to develop an internally generated intangible asset, the related costs may be capitalised as directly attributable development expenditure if the AASB 138 criteria are met but it is that asset that is recognised, not the API arrangement.

It depends. The assessment typically focuses on whether the dataset is identifiable, controlled and capable of generating economic benefits independently of a specific model. Licensed third-party data may give rise to an intangible asset where substantive rights are transferred, whereas  subscription based data services raise different considerations under the IFRIC Agenda Decisions on cloud computing arrangements. Internally generated datasets are unlikely to be recognised as separate intangible assets in their own right, given the restrictions AASB 138 places on internally generated intangible assets. Where the costs of creating such datasets, for example, data collection, labelling and preparation, qualify for capitalisation, they are more commonly included in the cost of the AI model being developed rather than recognised as a standalone asset.

It depends on whether the activity creates a new asset, enhances an existing asset beyond its originally assessed standard of performance, or simply maintains it. Fine-tuning a foundation model so that it can perform a new, domain-specific task for example adapting a general-purpose model to review legal contracts or interpret medical records may give rise to a separable intangible asset, provided the entity controls the resulting model and the AASB 138 development criteria are met. Routine retraining to maintain model performance in response to changing or deteriorating data is generally treated as a period cost.

The distinction between maintenance and enhancement is one of the most frequently revisited areas of judgment in AI accounting policies and benefits from clear, project-level documentation.

AASB 138 requires the useful life to reflect the period over which the asset is expected to generate economic benefits, taking into account factors such as technical obsolescence, expected usage and any legal or contractual limitations. For AI models, useful lives are often significantly shorter than those traditionally applied to enterprise software, given the rapid pace of foundation model releases, technological innovation and architectural improvements.

Cloud compute consumed during the development phase of an internally generated intangible asset can be capitalised where it meets the AASB 138 criteria – that is, if the expenditure is directly attributable to creating, producing or preparing the asset for its intended use. Compute costs incurred during the research phase or before all recognition criteria are met, must be expensed as incurred.

In practice, the key challenge is attribution: training runs often include experimentation, hyperparameter tuning and unsuccessful iterations alongside the development of the final model, and capturing compute costs with sufficient granularity to support a capitalisation position is one of the more common practical challenges. 

AASB 136 requires an impairment assessment whenever there is an indication that an asset may be impaired. For AI assets, common indicators include the release of a materially superior competitor or open-source models, significant performance degradation in production, regulatory changes affecting deployment, deterioration in the underlying training data and strategic shifts that reduce the asset's expected use. 

AI assets rarely generate cash inflows largely independent of those from other assets, so the AI asset (if recognised) is tested for impairment as part of the cash-generating unit (CGU) to which it belongs, rather than on a standalone basis. Identifying the appropriate CGU requires judgment and should be revisited as the entity's AI deployment evolves: a model that initially supports a single product may later be embedded across multiple revenue streams, or a capability previously integrated into a broader offering may subsequently be commercialised standalone.

Possibly. The release of a materially superior foundation model or open-source alternative could represent an external indicator of impairment. The key question is whether it affects the recoverable amount of the existing asset or, more commonly, the cash-generating unit to which the asset belongs.

Where the existing asset continues to support the expected cash inflows of its CGU because it is embedded in a workflow, integrated with proprietary data, or serves a use case the new model does not adequately address – an impairment loss may not arise. Since impairment is assessed at the level of the CGU as a whole, which may comprise numerous other assets, a decline in the relevance of the AI asset alone does not necessarily result in impairment.