Executive focus: research versus development, internally generated software, SaaS configuration, evidence for capitalisation and the IASB’s 2026 review of intangible-asset accounting.
Why digital projects create accounting pressure
Modern technology programmes rarely look like the software projects finance teams learned to account for twenty years ago. A company may pay for a cloud platform, configure third-party software, train an AI model using internal data, build APIs, purchase licences and run experiments—all inside one programme budget. The commercial project may be called “AI transformation”, but accounting must analyse the underlying rights and activities.
IAS 38 remains the core standard for internally generated intangible assets. It defines an intangible asset as an identifiable non-monetary asset without physical substance and imposes specific requirements on internally generated assets. In 2026 the IASB is conducting a comprehensive review of IAS 38, initially focusing on user information needs and whether aspects of the definition and recognition guidance need updating for newer types of intangibles and new ways of using them.
Research is expensed; development has a high hurdle
IAS 38 requires expenditure in the research phase of an internal project to be recognised as an expense when incurred. Research includes activities aimed at obtaining new knowledge, searching for alternatives and evaluating possible solutions. This is particularly relevant to AI proof-of-concepts: testing several models to see whether a business use case is viable often resembles research rather than development of an identifiable asset.
Development expenditure can be capitalised only when all recognition criteria are demonstrated, including technical feasibility, intention and ability to complete and use or sell the asset, probable future economic benefits, adequate resources and reliable measurement of attributable expenditure. Passing a management “go” gate does not automatically prove these accounting criteria.
The project needs an accounting phase boundary
The most important operational control is a documented date on which the project moves from research into qualifying development. Costs incurred before that date remain expensed; IAS 38 does not permit them to be reinstated later simply because the project eventually succeeds. Finance therefore needs evidence available at the boundary, not reconstructed months later.
A capitalisation memo can include the approved architecture, feasibility evidence, committed funding, expected use, business benefits, resource plan and cost-tracking design. The memo should identify the specific asset being created. “Digital transformation” is too broad. A separable software module, proprietary algorithmic component or controlled platform capability is a more meaningful unit of account if the recognition requirements are met.
SaaS changes the control analysis
In many cloud arrangements the customer receives access to the supplier’s software rather than control of the software itself. Subscription payments are therefore often service costs rather than the acquisition of an intangible asset. Configuration and customisation expenditure must then be analysed separately: who performs the work, what resource is created and does the customer control that resource?
This is where project accounting commonly goes wrong. A purchase order may label all implementation work as “software investment”, but accounting cannot rely on procurement categories. Finance should split licences, hosting, configuration, custom code, data migration, training and change-management activities and assess each component under the applicable requirements.
AI training data and models require rights analysis
An AI initiative may produce model weights, fine-tuned configurations, proprietary prompts, labelled datasets or workflow logic. The accounting question is not whether these items are technologically valuable. The question is whether the entity controls an identifiable resource and can demonstrate the recognition criteria. Contract terms with model providers and cloud vendors can be decisive.
If the supplier retains control and the customer merely consumes a service, capitalising the project because it creates long-term benefit may be inappropriate. Conversely, internally developed components that the entity controls may qualify once the development criteria are satisfied. Legal, security and finance teams need a shared view of ownership, access rights, portability and restrictions.
Cost measurement needs engineering discipline
Even when recognition is justified, only directly attributable expenditure incurred after the recognition date is capitalised. Time spent on research, general administration, training, duplicated processes or inefficiencies cannot simply be loaded into the asset because it is charged to the same project code.
Reliable measurement therefore depends on project data. Time recording, vendor work packages and change requests should distinguish capitalisable build activity from operational or exploratory work. Finance should test the allocation logic periodically instead of waiting until year-end. A high capitalisation ratio is not evidence of a successful project; it may indicate that cost categories are too coarse.
Why the 2026 IASB review matters now
The IASB’s current Intangible Assets project acknowledges that the economy has changed materially since IAS 38 was developed. In July 2026 the Board discussed potential changes to aspects of the definition and supporting requirements, using a cloud-based SaaS intellectual-property licensing arrangement as a test case. No final amendments were decided at that meeting.
Companies should therefore avoid anticipating new rules that do not yet exist. The correct 2026 accounting remains based on current IAS 38 and related IFRS guidance. However, finance leaders should follow the project because future changes may affect recognition, disclosures and the way digital investment is explained to investors.
Practical project checklist
- Break technology programmes into distinct rights, services and internally generated components.
- Document the research-to-development boundary before capitalisation starts.
- Test all IAS 38 development criteria, not only expected business benefit.
- Review SaaS contracts for control of software and custom components.
- Design project codes and time records that support reliable cost measurement.
- Expense training, research and general transformation activity when required.
- Track the IASB Intangible Assets project without pre-empting future amendments.