Businesses carrying out software development may be eligible for R&D tax relief, but not all software projects or development activities qualify. The key is to identify which work forms part of qualifying R&D and which costs relate to it. This guide, prepared by our R&D tax relief specialists, explains when software development can qualify, where the R&D boundary sits and which costs may be claimable.
When Does Software Development Qualify for R&D Tax Relief?
Software development can qualify in two ways. The software project can itself seek an advance in science or technology, or software can be created or adapted specifically for use in a wider qualifying R&D project. HMRC gives software developed to support R&D in life sciences as one example of the second route.
Where the software itself is the R&D project, two core conditions must be met.
- The project seeks an advance in science or technology.
The advance must increase the overall knowledge or capability available in the relevant field, rather than simply create something new for the company or its customers. - The project involves scientific or technological uncertainty.
A competent professional in the relevant field must not be able to readily determine whether the required result is achievable or how to achieve it using available knowledge. A competent professional is someone with suitable knowledge and experience in that field. The uncertainty must be technological rather than simply a question of time, cost, available resources, or development effort. A technically demanding project is therefore not automatically R&D if an experienced software professional could readily work out how to achieve the required result using established methods.
A new SaaS product, bespoke platform or feature can therefore be commercially innovative without qualifying as R&D.
A wider commercial software project can contain both qualifying R&D and routine development, so only the parts that meet the R&D criteria should be treated as R&D.
What Types of Software Development Can Qualify as R&D?
The starting point is the technological baseline: what was already publicly available or readily deducible to a competent professional when the project began. The claimed advance should then be assessed against that baseline, rather than against the company’s previous software or the functionality of a particular competitor’s product. Qualifying software R&D can arise in work on architecture, algorithms, system integration and technological constraints such as performance or security.
1. Extending Software Architectures, Frameworks or Data Architectures
Software architecture work can qualify where a project develops a data architecture beyond the capability of readily available database engines or extends a framework, SDK or software library beyond its original design because the required solution is not readily deducible.
Configuring existing software to meet a company’s requirements is outside R&D where the required capability already exists within the software.
2. Developing New or Appreciably Improved Algorithms
Algorithm development can qualify where a novel algorithm produces a significant increase in overall software capability.
Routine optimisation or fine-tuning does not qualify unless it produces a genuine, non-trivial improvement in the underlying technology.
3. Solving Non-Standard Integration and Interoperability Problems
Integration work can qualify where separate technologies or software components need to work together and a competent professional cannot readily determine how they should be combined to achieve the required function.
Using established integration methods is outside R&D where the required interaction is readily deducible. The number of systems or amount of development work does not change that distinction.
Relevant uncertainty may arise, for example, where incompatible data structures, communication protocols, transaction models or processing constraints mean that established integration techniques cannot achieve the required behaviour. The qualifying work is the technical investigation and development needed to overcome that limitation, rather than the integration activity simply because multiple systems are involved.
4. Overcoming Performance, Scalability, Reliability or Security Constraints
A demanding performance, scalability, reliability or security requirement does not qualify by itself. Work can qualify where meeting that requirement requires a technological advance and a competent professional cannot readily determine how to achieve it using existing knowledge.
For example, routine performance benchmarking is outside R&D, while development needed to overcome a technological performance limitation can form part of qualifying R&D.
UI, UX and visual design are outside R&D where the work is limited to layout, styling, usability or other aesthetic qualities. Work in these areas can qualify where achieving the required result depends on resolving a scientific or technological uncertainty.
Where Does Qualifying Software R&D Begin and End?
Qualifying software R&D begins when work starts to resolve a technological uncertainty and ends when the uncertainty is resolved or that work stops. A wider software project may start earlier and continue later, so its delivery timeline does not define the R&D boundary.
The same stage of software development can fall inside or outside the R&D boundary depending on what the work is intended to achieve.
|
Stage |
Within the R&D boundary when |
Outside the R&D boundary when |
|
Requirements and planning |
The work identifies a technological uncertainty or plans the technical work needed to resolve it. |
The work covers ordinary business requirements or commercial, financial, marketing or legal planning. |
|
Design and development |
The work contributes to resolving the technological uncertainty. |
The work applies an established solution without contributing to the resolution of the uncertainty. |
|
Testing |
The results help resolve the technological uncertainty by feeding back into the development work. |
Testing confirms functionality, usability or performance after the relevant uncertainty has been resolved. |
|
After release or during maintenance |
A new technological uncertainty emerges and work begins to resolve it. |
The work consists of routine maintenance or fault fixing. |
Qualifying work can therefore include developing prototypes, technical proofs of concept, alternative architectures or experimental versions where these are created to test possible solutions to the technological uncertainty. Failed approaches can also form part of the R&D where the results contribute to understanding why a proposed technological solution does not work.
HMRC recognises certain supporting activities as qualifying indirect activities, even though they do not directly resolve the technological uncertainty. These include administration, finance, personnel, maintenance or security undertaken for the R&D project, training required to support the R&D, and scientific or technical information services carried out for R&D support. Ordinary support activities outside HMRC’s defined qualifying indirect activities remain outside the R&D project.
Which Software R&D Costs Can Be Claimed?
Software R&D expenditure can include staff costs, externally provided workers, software licences, data and cloud computing, consumables and qualifying payments to contractors. The amount that can be claimed depends on how each cost relates to the R&D and the rules for that expenditure category.
- Staff costs
The proportion of salaries, wages, bonuses, employer Class 1 National Insurance contributions and employer pension contributions relating to employees or directors working on qualifying R&D can be included. - Externally provided workers
Payments for individuals supplied by a staff provider can qualify where those individuals work on the R&D under the company’s supervision, direction or control. For an unconnected staff provider, 65% of the payment attributable to qualifying earnings may qualify. - Software licences
Licence costs for software used in R&D can qualify. Where the same software is used for R&D and other work, only a reasonable proportion of the cost should be included. - Data licences and cloud computing
Costs for data licences, cloud storage, hardware facilities, operating systems and software platforms can qualify when used in activities that directly contribute to resolving the technological uncertainty. - Consumables
Costs for items consumed or transformed during qualifying R&D can be included. This can cover power, water, fuel and materials used in the R&D activities. - Contractor payments
Payments for R&D contracted out by the company can qualify where the contracted-out R&D conditions are met. For an unconnected contractor, 65% of the relevant contractor payment can generally be included. - The customer intends the R&D to be carried out
The customer can generally claim where it enters the contract intending or contemplating that R&D of that sort will be required. The software company would normally be carrying out R&D contracted to it by the customer and would not claim for the same R&D. - The software company decides to undertake its own R&D
The software company may claim where it independently decides that R&D is needed to fulfil the contract and plans that R&D itself. This can apply where the customer commissions an outcome but did not intend or contemplate the R&D subsequently undertaken by the developer. - The project description is too generic
Naming the technology used or the development task does not show what scientific or technological uncertainty the project faced. The description should identify the uncertainty, explain the work undertaken to resolve it and state how it was resolved or why it remained unresolved. - The competent professional should ideally explain the technological baseline, what limitations existed within available approaches, why the solution was not readily deducible and what technical work was undertaken to resolve the uncertainty. Simply stating that the project was difficult, technically challenging or required experienced developers is unlikely to demonstrate qualifying R&D on its own.
- Project records do not support the R&D description
HMRC does not require a specific format for R&D records. Project plans, design notes, test results and progress reports can support the advance, uncertainties and technical work described in the claim. - The qualifying cost calculation is unclear
The claim should show which expenditure was treated as qualifying and how the amount claimed was calculated. HMRC identifies the absence of a clear supporting calculation as a risk factor when reviewing R&D claims. - The technical solution was not known at the start. Experienced developers had to determine whether the required capability was achievable or how it could be achieved.
- Existing software, frameworks or architectures could not meet the technical requirement. The team had to develop or materially extend the underlying technology.
- Several technical approaches had to be developed and tested. Prototypes, failed approaches or comparative testing were used to find a workable solution.
- Technical limitations required substantial redesign or prevented the intended result. A project can still contain qualifying R&D where an approach fails or the project is abandoned.
- The R&D work and related costs can be identified separately within the wider project.
Overseas R&D costs
Contractor and externally provided worker costs are restricted where the relevant R&D is carried out overseas. Overseas R&D can still qualify where the conditions necessary for the R&D are not present in the UK, are present where the work takes place and would be wholly unreasonable to replicate in the UK. Lower costs or greater availability of workers overseas do not meet this exception.
Costs used for both R&D and other development
Costs used partly for qualifying R&D and partly for other software development need to be apportioned. For example, only the relevant proportion of an employee’s staff cost should be included where they split their time between qualifying R&D and routine development. Software used for both purposes requires a reasonable allocation of its licence cost.
Who Can Claim R&D Tax Relief When Software Development Is Outsourced or Carried Out for a Client?
For accounting periods beginning on or after 1 April 2024, the company that decides to undertake or initiate the R&D will generally be able to claim relief for that R&D. A software company does not automatically qualify for relief simply because its developers performed the technical work.
The contract helps establish which situation applies, but its wording alone is not decisive. HMRC considers the contractual terms and surrounding circumstances to determine which party intended the R&D to be carried out when the agreement was made.
Software R&D Tax Relief FAQs
1. Which R&D Tax Relief Scheme Can a Software Business Claim Under?
For accounting periods beginning on or after 1 April 2024, qualifying software R&D can be claimed under the merged R&D expenditure credit scheme. Loss-making R&D-intensive SMEs that meet the relevant conditions can choose Enhanced R&D Intensive Support instead. The applicable scheme depends on the company’s circumstances rather than the type of software it develops.
2. How Much R&D Tax Relief Can a Software Business Claim?
There is no fixed amount of R&D tax relief for a software business. The value depends on qualifying expenditure, the scheme used and the company’s tax or loss position.
The merged scheme provides a taxable expenditure credit equal to 20% of qualifying R&D expenditure. Under ERIS, a qualifying loss-making R&D-intensive SME can claim an additional deduction equal to 86% of qualifying expenditure and surrender eligible losses for a payable credit at 14.5%. The amount received can be limited by the PAYE cap.
3. Can Software Developed for Internal Use Qualify for R&D Tax Relief?
Yes, software developed for internal use can qualify for R&D tax relief. HMRC applies the same R&D test whether the software is intended for internal use, licensing or sale.
4. Can a Failed or Abandoned Software Project Qualify for R&D Tax Relief?Can a Failed or Abandoned Software Project Qualify for R&D Tax Relief?
Yes, a software project can qualify even when the intended technological advance is not achieved. R&D is determined by whether the project sought an advance and attempted to resolve technological uncertainty, not by whether the project ultimately succeeded. Projects stopped because of technical or commercial barriers can still contain qualifying R&D.
5. Can Software R&D Qualify When Another Company Has Already Solved the Same Problem?
Yes, work can still seek an advance where another company has achieved the same technological result but the knowledge needed to reproduce it is not publicly available or readily deducible. This can apply where the existing solution is protected as a trade secret or where the result is known but the method used to achieve it is not available.
Where Software R&D Tax Relief Claims Commonly Go Wrong
A software R&D claim must show why the project qualifies and how the amount claimed was calculated. The Additional Information Form requires details of the advance sought, the scientific or technological uncertainties, the work undertaken to address them and the qualifying expenditure for the projects described.
When Is a Software Project Worth Reviewing for R&D Tax Relief?
A software project is worth reviewing where the development team had to solve a technological problem that could not be resolved using an established approach.
Typical signs include:
- The technical solution was not known at the start. Experienced developers had to determine whether the required capability was achievable or how it could be achieved.
- Existing software, frameworks or architectures could not meet the technical requirement. The team had to develop or materially extend the underlying technology.
- Several technical approaches had to be developed and tested. Prototypes, failed approaches or comparative testing were used to find a workable solution.
- Technical limitations required substantial redesign or prevented the intended result. A project can still contain qualifying R&D where an approach fails or the project is abandoned.
- The R&D work and related costs can be identified separately within the wider project.