A scale-up moves its finance, CRM or HR system to a software-as-a-service (SaaS) platform. The subscription is an operating cost; nobody disputes that. The harder question is the implementation bill that arrives alongside it: configuration, customisation, integrations, data migration, training. Under IFRS, most of it is expensed, some of it is spread over the contract term, and a small part can be capitalised. Under US GAAP, more of it sits on the balance sheet.
The answer under IFRS comes from IAS 38 and two agenda decisions of the IFRS Interpretations Committee, published in March 2019 and April 2021. Agenda decisions do not change IFRS; they explain how it already applies, so companies are expected to follow them, with sufficient time to implement any change. This article works through the three questions they pose, then runs one implementation through IFRS and US GAAP.
Under IFRS, SaaS implementation spend creates an intangible asset only when the customer ends up controlling software, usually code it owns and runs itself. Everything else is an expense: when the service is received if it comes from a third party or is a distinct supplier service, or spread over the contract term if it is a supplier service that is not distinct from the subscription.
The IFRS Interpretations Committee concluded in March 2019 that a contract giving a customer only the right to access the supplier's software in the future is a service contract, not an intangible asset or a lease.
The customer in a typical SaaS contract does not control the software. It cannot take possession of it, run it on its own hardware, or stop others using it; it receives a service over the term. Without control, IAS 38's definition of an intangible asset (IAS 38.8 and 13) is not met, so the subscription is expensed as the service is received.
The answer changes if the contract does give the customer control, for example a licence to take a copy of the software and run it on infrastructure the customer controls. That is a software asset bought under a licence, recognised under IAS 38 at cost.
| Contract gives the customer | Accounting under IFRS | Typical examples |
|---|---|---|
| A right to access the supplier's software over the term | Service contract: fees expensed as the service is received | Most SaaS ERP, CRM, HR and payroll platforms |
| A right to take possession of the software and run it itself | Intangible asset at cost (IAS 38) | Perpetual or term licences for software installed on the customer's own servers or cloud tenancy |
The Committee's April 2021 agenda decision addressed the costs of configuring or customising the supplier's application software in a SaaS arrangement, and distinguished the two activities.
The distinction matters less than it first appears. The decisive question for both is the same: does the work give the customer a resource it controls? Configuring the supplier's platform almost never does; the switches live in software the customer does not control. Customising the supplier's code usually does not either, because the modified code sits in the supplier's environment.
The exception is code the customer owns and controls. If the customer's own team, or a contractor working for it, writes an integration module or bridging software that the customer holds the rights to and can run elsewhere, that code can be an intangible asset in its own right, recognised if the six criteria in IAS 38.57 are met.
Data migration and training are not configuration or customisation and do not create an asset either way. Training is expensed under IAS 38.69(b). Moving data into a new system is a service, expensed when it is received (IAS 38.68-69A), or over the term if the SaaS supplier performs it and it is not distinct from the access.
When the implementation spend does not create an asset, the remaining question is timing. The 2021 decision applies the "distinct" concept from IFRS 15 to answer it:
An implementation partner that is not the SaaS supplier, contracted directly by the customer rather than subcontracted by the supplier, provides a separate service. The customer expenses it when the service is received.
If the supplier's configuration or customisation is distinct from the right to access the software, the customer expenses it when the supplier performs it.
If the supplier's work cannot be separated from the access it provides, for example because it customises the supplier's own code that only it can change, the customer expenses it as it receives access over the term. An upfront payment is held as a prepayment and released over the contract.
A prepayment is not an intangible asset. As it is released over the SaaS term it is an operating expense for a service, not amortisation, so it stays above EBITDA. Presenting it as software, or amortising it below EBITDA, misstates both.
Halden Systems Ltd, a UK scale-up reporting under IFRS, moves its finance system to a SaaS enterprise resource planning (ERP) platform on a three-year contract at £120k a year, starting on 1 January. The implementation work is done early in year one; for simplicity, the example treats the platform as in use from 1 January, so year one carries a full year of each charge. The implementation costs £300k:
| Item | Cost | Who does it | IFRS treatment |
|---|---|---|---|
| Customisation of the supplier's code for Halden's approval rules | 80 | The SaaS supplier, which alone can change its code; not distinct from access | Prepayment, released over the 3-year term: 26.7 a year |
| Configuration of workflows, approvals and reports | 100 | An implementation partner (a third party contracted by Halden) | Expensed when received |
| Data migration | 40 | Implementation partner | Expensed when incurred |
| Training | 30 | Implementation partner | Expensed (IAS 38.69(b)) |
| Connector to Halden's warehouse system | 50 | Halden's own developers; Halden owns the code and runs it on its own servers | Intangible asset if IAS 38.57 is met; amortised over 5 years: 10 a year (see note) |
| Total | 300 |
| Year 1 | Years 1-3 | |
|---|---|---|
| Subscription | 120 | 360 |
| Implementation expensed or released | 196.7 | 250 |
| Amortisation of the connector | 10 | 30 |
| Total cost in profit or loss | 326.7 | 640 |
The connector's five-year life rests on a judgement: Halden expects to keep using it, either with this platform or repointed to a successor system, although renewal of the SaaS contract is not reasonably certain (IAS 38.90). If it could only ever serve this three-year contract, a three-year life would be right. On a five-year life, its remaining £20k is carried into year four. Everything else is in profit or loss within the contract term.
US GAAP reaches a different answer. Under ASC 350-40, as amended by ASU 2018-15, a customer in a hosting arrangement that is a service contract capitalises implementation costs incurred in the application development stage, as it would for internal-use software, and amortises them over the term of the arrangement. The asset is presented with prepaid hosting fees, and its amortisation sits in the same income statement line as the hosting fees.
| Year 1 | Years 1-3 | |
|---|---|---|
| Subscription | 120 | 360 |
| Data migration and training (expensed) | 70 | 70 |
| Configuration and customisation (capitalised, amortised over 3 years) | 60 | 180 |
| Connector (internal-use software, amortised over 5 years) | 10 | 30 |
| Total cost in profit or loss | 260 | 640 |
Over three years Halden's implementation costs it the same £280k in profit or loss under either framework (£640k less the £360k subscription). The difference is timing: £206.7k of implementation cost lands in year one under IFRS, against £140k under US GAAP. For a scale-up measured on year-one EBITDA ahead of a raise, a £67k gap from the same invoices is material.
ASU 2025-06 removes the project stages from ASC 350-40. For annual periods beginning after 15 December 2027 (calendar 2028 for December year ends), capitalisation starts when management has authorised and committed to funding the project and it is probable the project will be completed and the software used as intended, with costs expensed while significant development uncertainty remains. Because hosting-arrangement implementation costs follow the ASC 350-40 internal-use software model, the same trigger will decide them. Early adoption is permitted from the beginning of an annual reporting period. See our comparison of IAS 38 and ASC 350 for the detail.
FRS 102 has no rule written for cloud computing arrangements. UK private companies apply Section 18's definition of an intangible asset, which turns on control just as IAS 38 does, so most reach the same conclusion: a right to access software is a service, and configuration of a supplier's platform is an expense. Where FRS 102 is silent, management may also consider the requirements of IFRS dealing with similar issues (FRS 102 10.6), which here means IAS 38 as the IFRIC agenda decisions explain it.
For accounting periods beginning on or after 1 January 2026 (earlier application allowed), FRS 102 Section 18 also has guidance on assets with both tangible and intangible elements: software a machine cannot run without is part of the hardware. That rarely affects SaaS, where the customer holds no hardware, but it matters for on-premises systems. Our IAS 38 vs FRS 102 Section 18 comparison covers the 2026 changes.
SIC-32 is the only IFRS Interpretation written for one kind of software asset: a company's own website. It applies IAS 38 stage by stage:
| Stage | Treatment |
|---|---|
| Planning (feasibility, objectives, selecting hardware and software) | Expensed, like research |
| Application and infrastructure development, graphical design, content development | Capitalised if the IAS 38.57 criteria are met and the costs are directly attributable |
| Content that advertises or promotes the entity's own products | Expensed |
| Operating (maintenance and updates) | Expensed, unless the cost meets the IAS 38.18 recognition criteria (SIC-32.9(d)) |
| Hosting by an external provider | Outside SIC-32: a service, expensed when received (SIC-32.5) |
A website used mainly to promote the entity's own products cannot show that it will generate probable future economic benefits, so all of its development cost is expensed. A site that takes orders can pass that test.
The IASB is reviewing IAS 38. At its 22 September 2026 meeting it looked at a model for how a customer should account for contracts that license intellectual property, using a SaaS contract as the test case. It was not asked to make any decisions; its staff expect to ask for decisions in early 2027, and the next milestone on the work plan, deciding the project's direction, has no date. Any change to the answer in this article is years away; our article on what is changing in IAS 38 tracks the project.
Halden's invoices do not change between frameworks; the answer does. A scale-up founder sees the same thing within one framework: the statutory accounts expense almost all of the implementation, while the work plainly builds something the business will use for years.
That is the gap Opagio Intangibles is built to show without blurring it. It presents a company's accounts on three bases, one at a time: Reported (as filed), Accounting-eligible (what the standards would let the company capitalise) and Management (a non-statutory view of the investment, never for filing). The statutory answer stays the statutory answer; the management view is a separate basis, clearly labelled. For scale-ups preparing for a round, see Opagio for growing companies.
Usually not. Configuration sets switches and parameters in software the supplier controls, so it does not create an intangible asset for the customer. The cost is expensed when the service is received, or spread over the contract term if the supplier's configuration is not distinct from the access it provides (IFRIC agenda decision, April 2021).
Configuration sets flags, switches, values or parameters so the software's existing code works in a particular way. Customisation modifies the code or writes additional code, changing or adding functionality. Either can create an asset only if the customer ends up controlling the resulting code.
When the work creates software the customer controls, typically code the customer owns and can run itself, such as an integration module on its own servers. That code is recognised under IAS 38 if the six criteria in IAS 38.57 are met.
Yes. Under ASC 350-40 (ASU 2018-15), eligible implementation costs of a hosting arrangement that is a service contract (those in the application development stage) are capitalised like internal-use software and amortised over the term, presented with prepaid hosting fees; training and data conversion are expensed. ASU 2025-06 changes when capitalisation starts for annual periods beginning after 15 December 2027.
Ivan Gowan is the Founder and CEO of Opagio. He has 25 years in financial technology, including building and scaling technology platforms at IG Group. Meet the team.
Opagio Intangibles runs RFR, MPEEM, With & Without and Cost across every intangible asset you own — the evidence base that survives Fair Value scrutiny.
A practical guide to software capitalisation under IAS 38 and ASC 350-40, plus valuation methods for software as an intangible asset. Covers when to capitalise, how to value, and common mistakes in software asset accounting.
Read more →
A development-cost capitalisation policy template for IFRS reporters, section by section, with the cost rules of IAS 38.66-67, the evidence auditors ask for against each of the six tests, and the FRS 102 policy-choice variant.
Read more →
Every intangible asset passes through seven stages, from identification to disposal, and each stage has an owner, a record and an accounting consequence. Here is how a scale-up runs the intangible assets lifecycle, what the board should see, and where IAS 38 and FRS 102 apply.
Read more →Get the latest insights on intangible asset growth and productivity delivered to your inbox.