Capitalising software development

What must be shown before capitalising?

IAS 38 allows development costs to be capitalised only from the point the company can demonstrate: the technical feasibility of completing the software; its intention to complete and use or sell it; its ability to do so; how it will generate probable future economic benefits, such as revenue from customers using the new features; the technical, financial and other resources to complete it; and its ability to measure the costs reliably. Costs incurred before that point are expensed and cannot be capitalised later. See IAS 38 research and development.

How do the criteria work in agile development?

In agile teams, work is planned in epics and features and delivered in short sprints, with design and coding overlapping. Companies typically assess the criteria for each significant feature or epic: discovery work and prototypes are research; once the design is validated, the feature is approved and funded, and the team is confident it can be built, sprint costs on it are development. Time tracking by feature, approval records and architecture decisions provide the evidence. Bug fixes, refactoring that does not add functionality and keeping the platform running are maintenance.

Capitalising software development: a year of engineering spend

A SaaS company spends US$ 10 million on engineering in a year: 2 million on discovery and prototypes for new ideas, 6 million building two new modules after their designs were approved and feasibility shown, 1.5 million on bug fixes and minor improvements, and 0.5 million on training and general overheads. The modules are released at the year end and expected to stay useful for 3 years.

Capitalising 6 million raises this year's operating profit by that amount compared with expensing everything, and adds amortisation of 2 million a year for the next 3 years. Directly attributable costs, such as engineers' salaries and benefits, share-based payment and contractors working on the modules, are included; general overheads and training are not.

How is capitalised software amortised and tested?

From when the software is available for use, usually release, over its expected useful life, often three to five years for platform features given the pace of change, on a straight-line basis. Projects still in development are tested for impairment at least annually, and released software when there are indicators, such as features being replaced or abandoned. Abandoned projects are written off.

What about software sold to customers?

Under IFRS, the same IAS 38 criteria apply whether the software is used to deliver a SaaS service or sold as a licence. In practice, companies selling licensed software often reach technical feasibility late, close to release, so they capitalise less. See software licence or SaaS.

How does US GAAP differ?

Software used to deliver a SaaS service is internal-use software under ASC 350-40. ASU 2025-06, effective for annual periods beginning after 15 December 2027, removes the old project stages: capitalisation starts once management has authorised and committed to funding the project and it is probable that it will be completed and perform as intended, but not while significant development uncertainty remains, such as novel features not yet resolved through coding and testing. Software to be sold or licensed follows ASC 985-20, where costs are capitalised only after technological feasibility, which in practice means little is capitalised. See IAS 38 vs ASC 730 and SaaS accounting.

This guide is general information. It is not tax or legal advice for your situation.