Software is the intangible asset that companies most frequently encounter in their accounting. Whether it is internally developed, purchased off the shelf, or acquired as part of a business combination, software presents unique questions about when to capitalise, how to value, and how to amortise.
For technology companies, software is typically the core asset. For non-technology companies, internally developed software — ERP systems, customer portals, data platforms — often represents a significant capital investment that accounting standards require careful treatment of.
Software capitalisation is not optional — both IFRS and US GAAP require capitalisation when specific criteria are met. Under-capitalising (expensing everything) understates assets and overstates current-period expenses. Over-capitalising (capitalising speculative development) inflates assets and understates expenses. Neither is compliant.
Under IAS 38, internally developed software follows the standard's research-and-development framework. All costs in the research phase are expensed. Costs in the development phase are capitalised if the six criteria are met.
| IAS 38 Criterion | Software Development Application |
|---|---|
| Technical feasibility | Architecture design is complete; core technology is proven |
| Intention to complete | Project has management approval and dedicated resources |
| Ability to use or sell | Platform will be deployed commercially or used internally |
| Future economic benefits | Revenue model is defined or internal efficiency gains are quantifiable |
| Adequate resources | Budget is allocated; development team is staffed |
| Reliable cost measurement | Project tracking system captures costs by phase |
The capitalisation start point is when all six criteria are simultaneously met — typically at the point where the software moves from prototyping/proof-of-concept into structured development with an approved design specification.
The capitalisation end point is when the software is "available for use" — capable of operating in the manner intended by management. Post-launch enhancement costs are capitalised only if they meet the criteria independently (i.e., they represent a significant new feature, not routine maintenance).
A fintech company builds a new lending platform. The project has three phases: (1) research and feasibility — 4 months, £200K, all expensed; (2) development — 8 months, £600K, capitalised as an intangible asset; (3) post-launch optimisation — ongoing, £150K/year, expensed unless qualifying enhancements. The capitalised asset of £600K is amortised over its estimated 5-year useful life.
For companies reporting under US GAAP, ASC 350-40 governs the capitalisation of internal-use software. The framework is similar to IAS 38 but uses different terminology and has some practical differences.
| Stage | Treatment | Includes |
|---|---|---|
| Preliminary project | Expense | Feasibility studies, vendor evaluation, needs assessment |
| Application development | Capitalise | Design, coding, testing, installation, data conversion |
| Post-implementation | Expense | Training, maintenance, minor upgrades |
The 2020 ASU 2018-15 update clarified that implementation costs for cloud computing arrangements (SaaS) should be capitalised using the same criteria as internal-use software — even though the company does not own the underlying software. This is a significant development for companies with major SaaS dependencies.
When software needs to be valued — in an acquisition, for financing, or for strategic assessment — the primary methods are:
The cost approach estimates the cost to reproduce or replace the software from scratch. It is the most commonly used method for software valuation because inputs are well-defined.
Inputs:
The cost approach captures what the software cost to create, not what it is worth economically. A platform that took £2M to develop but generates £10M in annual revenue is worth considerably more than £2M. The cost approach is the floor, not the ceiling. For income-generating software, always cross-check with an income approach.
The RFR method values software based on the licence fees the owner avoids. Software licence royalty rates typically range from 15-30% for enterprise platforms and 5-15% for embedded technology components.
The income approach values software based on the present value of the cash flows it generates. For SaaS platforms, this is the most appropriate primary method because the revenue attribution is direct and observable.
Capitalised software is amortised over its estimated useful life, which should reflect the period over which the software is expected to generate economic benefit.
| Factor | Shorter Life | Longer Life |
|---|---|---|
| Technology evolution pace | Fast-moving (AI, mobile) | Stable (ERP, accounting) |
| Competitive pressure | High — risk of disruption | Low — established market |
| Maintenance investment | Low — approaching end-of-life | High — actively maintained |
| Architecture quality | Monolithic, hard to extend | Modular, API-driven |
| Customer dependency | Low switching costs | High switching costs, deep integration |
Regulators and auditors are increasingly sceptical of software useful lives exceeding 7 years. While some enterprise platforms genuinely have 10-15 year useful lives, many technology assets become economically obsolete within 3-5 years. The useful life assessment must be reviewed annually and adjusted when circumstances change.
When software is acquired in a business combination, IFRS 3 requires it to be identified and measured at fair value as part of the purchase price allocation.
Most modern software incorporates open-source libraries and frameworks. The cost approach must account for this — the replacement cost should not include re-developing functionality that is freely available as open-source. However, the integration, customisation, and testing of open-source components is proprietary work and should be included.
Technical debt — accumulated shortcuts, outdated architecture, missing documentation — reduces the effective value of software. In the cost approach, this is captured through the obsolescence adjustment. Functional obsolescence (the software does not fully meet current needs) and economic obsolescence (external factors have reduced its value) should both be assessed.
SaaS platforms are typically valued using the income approach because the revenue attribution is clear and recurring. On-premises software — where the revenue model involves one-time licences — may be better suited to the RFR method or cost approach.
| Software Type | Preferred Method | Rationale |
|---|---|---|
| SaaS platform | Income Approach | Recurring revenue directly attributable |
| Licensed software | Relief-from-Royalty | Observable licence rates as benchmark |
| Internal-use ERP | Cost Approach | No direct revenue; value is cost avoidance |
| Embedded firmware | Cost Approach | Component of larger product |
| AI/ML models | Income + Cost hybrid | Training data cost + incremental revenue |
AI models present emerging valuation challenges. The model itself (architecture, weights, training methodology) is a software asset. The training data is a separate data asset. The compute cost of training is a component of the cost approach. But the economic value may far exceed the training cost — a model that generates £5M in annual revenue through better predictions cannot be valued at its £200K training cost alone.
A healthcare AI company has developed a diagnostic model trained on 2 million anonymised patient records. The cost approach values the model at £1.8M (development time + compute costs). The income approach, based on the £4M annual revenue from diagnostic-as-a-service offerings, values it at £12M. The data asset (patient records) is valued separately at £3.5M using the cost approach. In the PPA, the model and data are recognised as separate intangible assets.
The shift from on-premises software to cloud-based delivery has created new accounting challenges. Under IFRIC guidance and ASU 2018-15, companies must distinguish between:
Only the first category is capitalised as an intangible asset. However, implementation costs for SaaS arrangements (configuration, customisation, integration) can be capitalised if they meet the criteria — a distinction that many companies miss, either capitalising too aggressively or expensing implementation costs that should be recognised as assets.
Ivan Gowan is the Founder and CEO of Opagio. With 25 years in financial technology — including building and scaling technology platforms at IG Group — he brings direct experience of software capitalisation, valuation, and the strategic role of technology assets in high-growth businesses. Meet the team.
A comprehensive guide to IAS 38 Intangible Assets: the recognition criteria, measurement rules, capitalisation requirements, and amortisation treatment. Includes practical guidance on R&D capitalisation and the gap between IAS 38 and economic reality.
Read more →A practical guide to the six core methods for valuing intangible assets: Relief-from-Royalty, MPEEM, With-and-Without, Cost, Income, and Market approaches. Includes when to use each method and worked examples.
Read more →A comprehensive guide to 35 types of intangible assets classified by IFRS 3, IAS 38, and the CHS growth accounting framework. Includes definitions, examples, and valuation approaches for each type.
Read more →Get the latest insights on intangible asset growth and productivity delivered to your inbox.
Book a free consultation to see how the Opagio Growth Platform can help your business.