Capitalising software development costs under IAS 38 for UK deeptech and SaaS startups

Capitalise vs. Expense: The Strategic Impact for UK Startups

For a UK-based SaaS or Deeptech startup, the engineering payroll is often the largest single line item on the profit and loss (P&L) statement. This expense directly reduces your EBITDA, a key metric for investors. However, accounting standards provide a mechanism to reframe a portion of this spending not as a cost, but as an investment in a value-generating asset. This process, known as capitalisation, is governed by International Accounting Standard 38 (IAS 38) on Intangible Assets. For many UK companies, especially those backed by venture capital, the equivalent standard is FRS 102.

Understanding the rules for capitalising software development costs under IAS 38 is not just an accounting exercise. It is a strategic tool for managing your financial narrative and demonstrating the long-term value you are building.

At its core, the choice is between expensing a cost or capitalising it. An expense hits your P&L immediately, reducing your profit for that period. A capitalised cost, conversely, is recorded as an asset on your balance sheet. By moving a portion of your development salaries from an operating expense to an intangible asset, you can significantly improve key performance indicators like EBITDA, which can be critical during fundraising rounds and for meeting bank covenants.

Under these accounting rules, the software you build is considered an internally generated intangible asset. It lacks physical substance but is expected to generate future economic benefits for your company. The framework of IAS 38 (Intangible Assets) is the accounting standard governing the capitalisation of software development costs. The entire standard rests on a fundamental separation of your product development lifecycle into two distinct phases: 'Research' and 'Development'. This split is central to internal software project accounting and determines whether costs must be expensed or can be added to the balance sheet.

For a wider view on this topic, see the hub on Capex, Depreciation, and Intangibles. If you operate under US standards, see our US GAAP capitalisation guide.

The Crucial Distinction: IAS 38 Software R&D Accounting Rules

The most critical aspect of applying IAS 38 is its strict separation of activities into two phases. As the standard states, A strict distinction is made between the 'Research Phase' where all costs must be expensed, and the 'Development Phase' where costs can be capitalised. (IAS 38). Costs incurred during the Research Phase, such as activities aimed at obtaining new knowledge, evaluating product alternatives, or prototyping early-stage concepts, must always be treated as expenses as they are incurred. You cannot capitalise them.

Only when a project moves into the Development Phase can you begin capitalising the associated costs. This transition is not a subjective judgement call. To proceed, a project must satisfy six specific criteria simultaneously. According to the IAS 38 authoritative recognition criteria, To move from the Research to the Development phase, six specific criteria must all be met: 1. Probable future economic benefits; 2. Intention to complete; 3. Resources available; 4. Ability to use or sell; 5. Technical feasibility; 6. Expenditure can be measured reliably. (IAS 38).

The Six Criteria for Capitalising Software Costs

Let’s break down these six hurdles in the context of a UK SaaS or Deeptech startup.

1. Technical Feasibility: This is often the highest hurdle. It means you are past the point of blue-sky thinking and have a clear, documented technical plan to build and complete the asset. The core technical risks have been resolved. For example, you have successfully completed a proof-of-concept for a new machine learning algorithm or confirmed that a critical third-party API integration works as required.
2. Intention to Complete: You must genuinely plan to finish and launch the feature or product. This cannot be a speculative project. Evidence typically includes board minutes approving the project, detailed product roadmaps, or resource allocation plans showing a clear commitment to completion.
3. Ability to Use or Sell the Asset: You must be able to demonstrate how the completed software asset will be used to generate value. For most SaaS companies building a new feature for their platform, this criterion is straightforward as the feature will be sold to customers. For internal tools, you must show how it will be used to improve operations or reduce costs.
4. Probable Future Economic Benefits: You need tangible evidence that the new feature will generate revenue, increase customer retention, or create cost savings. This could be a business case with financial projections, market analysis showing clear demand, or user research indicating customers are willing to pay for the new functionality.
5. Availability of Adequate Resources: You must have the technical, financial, and other resources to see the project through to completion. This means having the necessary cash runway to fund the development and a committed engineering team with the right skills to build, test, and deploy the asset.
6. Reliable Measurement of Expenditure: You must have a system in place to accurately track and allocate the specific costs attributable to the development of this asset. This is a practical requirement that necessitates robust internal processes, which we will explore next.

Research vs. Development in Practice

Consider a SaaS company building an AI-powered forecasting module. The initial phase of exploring different predictive algorithms, testing data sets, and building low-fidelity prototypes is firmly in the 'Research' camp. All associated developer salaries and costs are expensed on the P&L as they occur.

However, once the board approves a specific technical approach, the business case is signed off, a budget is allocated, and the engineering team begins writing production-level code for the feature, the company has crossed the threshold into 'Development'. From this point forward, the directly attributable costs of building that module can be capitalised as an intangible asset.

Audit-Proof Your Process: Tracking and Documenting Costs

Demonstrating that you have met the six criteria is only half the battle. To satisfy an auditor, you must have robust, contemporaneous evidence to support every pound you capitalise. As noted by industry experts, auditors expect contemporaneous evidence. This can be a challenge for early-stage businesses where the finance function might be a sole founder using Xero and spreadsheets, not an enterprise-level system.

The key is creating a clear and consistent audit trail that links specific costs to specific capitalisable projects. The most significant cost is typically developer salaries, so implementing a reliable time-tracking process is non-negotiable.

The reality for most Series A startups is more pragmatic: you do not need a complex, expensive system, but you do need a consistent one. Tools like Clockify or Harvest can be integrated with project management software like Jira to provide the necessary data. Developers should log their time against specific projects, features, or epics, and these tickets should be clearly tagged as 'Research', 'Development', or 'Maintenance'.

What Costs Can Be Capitalised?

Only direct costs are permissible under IAS 38. This primarily includes:

• The portion of employee salaries and related costs (e.g., National Insurance contributions) for time spent directly on development activities.
• Fees paid to third-party contractors for specific development work on the project.
• Amortisation of any software licences or development tools used directly in the creation of the asset.

General business overheads such as office rent, HR and administrative salaries, or sales and marketing costs cannot be capitalised as part of the intangible asset.

Worked Example: Calculating Capitalisable Salary Cost

Let's say a developer has a gross annual salary of £70,000. The company's associated National Insurance contribution is £8,000, making her total annual employment cost £78,000.

In a given month, her timesheet data from your tracking system shows she spent 60% of her time on 'Project Phoenix' (a new feature that has met the six criteria for development), 20% on fixing bugs in existing features (maintenance), and 20% on speculative R&D (research).

• Total Monthly Cost: £78,000 / 12 = £6,500
• Capitalisable Portion (Development): £6,500 * 60% = £3,900
• Expensed Portion (Maintenance & Research): £6,500 * 40% = £2,600

In this month, £3,900 would be added to the intangible asset on the balance sheet, improving EBITDA by the same amount. The remaining £2,600 would be recorded as a salary expense on the P&L. This clear documentation provides the reliable measurement needed to pass audit scrutiny.

After Capitalisation: Managing Your New Asset

Once a development project is complete, the accounting treatment shifts again. The standard is clear that Capitalisation of costs for a specific feature must cease once the asset is live and ready for its intended use. (IAS 38). This means the moment your new software module is deployed and available to customers, you must stop adding costs to the balance sheet for that asset. Any subsequent work, such as routine bug fixes or minor enhancements, is treated as an operational expense.

With a new intangible asset on your balance sheet, you must now manage it through two key processes: amortisation and impairment testing.

Amortisation: Spreading the Cost

Amortisation is the systematic process of expensing the value of the intangible asset over its useful life. In essence, it is to intangible assets what depreciation is to physical assets like laptops. Capitalised assets must be amortised (expensed) over their estimated 'useful life'. (IAS 38). You are recognising the cost of the asset on the P&L over the period it is expected to generate economic benefits.

Determining the 'useful life' is a matter of commercial judgement, but your reasoning must be defensible to an auditor. For software, technology changes rapidly, and features can become obsolete. In practice, we see that a common and defensible useful life for SaaS platform assets is 3-5 years. Choosing a five-year life means you would expense 20% of the asset's total capitalised cost each year through the P&L. For practical guidance on incorporating this into your financial planning, see our guide on Depreciation in Financial Models and Forecasts.

Impairment Testing: A Crucial Annual Check

This is a crucial check to ensure the value of your asset on the balance sheet is not overstated. According to IAS 38, Impairment testing must be conducted at least annually to ensure the asset's value on the balance sheet is not overstated. (IAS 38). This involves assessing whether the asset is still expected to generate the future economic benefits you originally projected.

If, for example, a competitor launches a superior product that renders your newly built feature obsolete, its value may be impaired. You would need to write down the carrying value of the asset on the balance sheet, which results in a one-time expense on the P&L. This process prevents companies from carrying worthless assets, which could mislead investors or HMRC about the company's true net worth. Learn more about Impairment Testing for Startup Assets.

Practical Takeaways for UK Tech Companies

For a growing UK tech company, correctly applying IAS 38 or FRS 102 for internal software project accounting is a sign of financial maturity. It directly impacts your reported profitability and the strength of your balance sheet, shaping the narrative you present to investors.

The process begins with establishing a clear internal policy that defines the exact point your projects move from the 'Research' phase to the 'Development' phase, ensuring all six criteria are met and documented. Next, implement a pragmatic but consistent time-tracking system to generate the audit-proof evidence required to justify which costs are capitalised.

Finally, remember that capitalisation is not a one-time decision. You must actively manage the asset through a disciplined amortisation schedule and annual impairment reviews. By mastering this process, you gain a powerful tool to more accurately reflect the value being created by your engineering team, strengthening your financial position for future funding rounds and strategic growth.

For a complete overview of capitalisation policy, see the Capex, Depreciation, and Intangibles hub.

Frequently Asked Questions

Q: What is the main difference between IAS 38 and FRS 102 for software capitalisation?

A: Both standards are very similar. They both require a distinction between a research phase (always expensed) and a development phase (can be capitalised). FRS 102, however, offers an accounting policy choice: you can either capitalise development costs that meet the criteria or choose to expense all of them.

Q: Can we capitalise costs for bug fixes or maintenance on our software?

A: No. Once a software asset is deployed and ready for its intended use, any further costs for maintenance, bug fixes, or minor updates must be expensed as incurred. Capitalisation is only for the initial development or for major upgrades that create significant new functionality and meet the six criteria.

Q: How does capitalising development costs affect R&D tax credits in the UK?

A: Capitalising software development costs does not prevent you from claiming R&D tax relief. The costs added to your balance sheet can still be included in your R&D claim for the year they are incurred. However, the accounting treatment and tax treatment are separate, so it is vital to get specialist advice.

Q: Is it better to choose a 3-year or 5-year useful life for amortisation?

A: The choice depends on how long you realistically expect the software to generate economic benefits. A shorter period (3 years) results in higher annual amortisation charges, reducing profit more quickly. A longer period (5 years) has the opposite effect. The choice should be justifiable based on your product lifecycle and technology refresh rates.