R&D tax relief is one of the most valuable incentives available to software and technology companies, and also one of the most abused. Volume R&D mills have built a business model on telling founders that their engineering work almost certainly qualifies, then filing claims that HMRC later removes. The honest position is different: a great deal of software development does not qualify, and saying so plainly is both more accurate and better for your company.
This guide sets out the legal test, what it means in practice for software work, and, crucially, what does not pass it. It is aimed at founders and engineering leads at scaling software companies, not at one-person freelancers or agency project teams.
The legal test: advance in science or technology plus technological uncertainty
Software work qualifies for R&D relief only where it seeks an advance in science or technology and the work involves resolving genuine technological uncertainty. The test also requires that a competent professional in the field could not readily deduce the solution from existing knowledge. Routine software development, however hard or costly, does not qualify under HMRC's guidelines.
Three elements must all be present. Miss any one of them and the work is not R&D for tax purposes.
- An advance in science or technology. The work must extend the overall field, not just your company's own understanding of it. Applying known techniques to a new business problem does not advance the field. Discovering a genuinely novel algorithm, method or architecture that others in the field could not have readily deduced does.
- Technological uncertainty. It must not have been known, at the time the work was done, whether or how the objective could be achieved using existing scientific or technological knowledge. The uncertainty is about method, not outcome. If an experienced engineer could look at the problem and say "we know how to approach this, it just takes time to build", that is not technological uncertainty.
- Not readily deducible by a competent professional. The solution must not have been available by applying standard methods that an experienced software engineer in the relevant sub-field would routinely draw on. This is an objective test, not a test of your team's specific skill level.
One further point that is often blurred: an advance in the company's own knowledge is not sufficient. Your team learning a technology that already exists is not R&D for tax purposes. The advance must be in the field itself, in objective scientific or technological knowledge, not in your internal capability.
What genuinely qualifies: the positive case for software R&D
Where software work does pass the test, it tends to share characteristics. The following are categories where a qualifying case can be made, provided the specific facts support it.
- Novel algorithmic work. Developing a new algorithm where no known efficient solution existed, such as a new approach to a constraint-satisfaction problem, a novel graph-traversal method for a specific domain, or a machine-learning architecture that addresses a recognised limitation in the state of the art. The advance must be in the algorithm, not in applying a known algorithm to a new dataset.
- Performance and scale problems with no known solution. Where a system needs to achieve a performance target (latency, throughput, accuracy) that existing approaches cannot meet and where the engineering team must investigate unknown solution paths. The key is that the target could not be met by applying standard techniques more carefully. The uncertainty is about whether a solution at that specification is achievable at all.
- Genuine integration uncertainty. Where the integration of systems, protocols or hardware involves an interaction that is scientifically or technically uncertain, not just logistically complex. Building an API integration with a well-documented third-party service is not R&D. Building a real-time protocol bridge between two systems with conflicting data models and unknown interaction effects may involve qualifying work, if the uncertainty is genuine and the approach is not routine.
- Advances in compiler design, runtime environments or tooling infrastructure. Where the work pushes beyond what existing tools can do and requires genuinely new techniques to achieve a defined technical capability.
In each case, the claim is for the qualifying slice of cost attributable to that work. It is not a claim over the entire project or the whole engineering team's payroll.
What does NOT qualify: the honest negative list
This is the section that most R&D advisers soften. We do not soften it. The following categories do not qualify under HMRC's R&D guidelines, and claiming them creates a weak claim that HMRC can and does remove.
| QUALIFIES (with supporting evidence) | DOES NOT QUALIFY |
|---|---|
| Novel algorithm addressing a problem with no known efficient solution | Routine feature development using established frameworks and patterns |
| Achieving a performance/scale target where no known method exists | Standard CRUD application build, however large or complex |
| Resolving genuine uncertainty in system integration at a protocol or interaction level | Configuring or extending a known framework (React, Rails, Django, Laravel etc.) |
| Developing new compiler or runtime capabilities beyond the current state of the art | Cosmetic or UI work, including animations, layouts and styling |
| ML/AI work advancing beyond existing model architectures with documented uncertainty | Applying an existing ML model (including fine-tuning a pre-trained model) to a new dataset |
| Resolving a genuinely novel technical uncertainty in hardware-software interaction | Bug fixing and testing carried out as standard quality-assurance maintenance |
| Investigating genuinely unknown interaction effects between incompatible systems | Using an off-the-shelf approach, API or library that is new to your team but well-established in the field |
| Research into a technical approach where the feasibility is genuinely unknown | Performance work where standard optimisation techniques are applied more carefully |
The negative column is grounded in HMRC's R&D manual: qualifying R&D must seek an advance in science or technology and resolve technological uncertainty. None of the items in the right column do that.
Where the boundary falls inside a single project
Most real engineering projects contain both qualifying and non-qualifying work. The boundary runs through the project, not around it. You claim the qualifying workstreams, not the total project budget.
This is important because it changes the question. The question is not "does this project qualify?" It is "which specific workstreams within this project involved genuine technological uncertainty, and what costs are attributable to them?" The answer shapes the claim.
A project to build a new data platform might include:
- Designing a novel query execution layer that achieves latency targets no existing solution meets (potentially qualifying, if the uncertainty is genuine).
- Building the data ingestion pipeline using established ETL patterns (not qualifying).
- Developing the front-end dashboards and UI (not qualifying).
- Investigating whether a new compression algorithm can reduce storage costs below a threshold that existing algorithms cannot reach (potentially qualifying, depending on specifics).
- Configuring cloud infrastructure and deploying the system (not qualifying).
The claim is for costs attributable to the qualifying workstreams, apportioned appropriately. It is not a claim over total project cost. The Additional Information Form requires you to describe the qualifying work precisely, so imprecise boundary-drawing creates an AIF that HMRC can interrogate.
Worked example: a scaling team's engineering roadmap
The following is an illustrative example of how an R&D eligibility assessment might apply to a scaling engineering team's roadmap. All workstreams, numbers and descriptions are fictional and for illustration only. Apply the same reasoning to your own facts.
Suppose a B2B SaaS company has a six-workstream engineering roadmap for the year.
| Workstream | Description | Verdict | Reason |
|---|---|---|---|
| Query engine redesign | Building a new execution layer to achieve sub-10ms latency on a class of analytical queries that existing engines cannot handle at that specification | Potentially qualifying | Genuine technological uncertainty: not known whether that latency target is achievable; existing solutions cannot meet the specification; novel approach required |
| Billing and subscription module | Implementing recurring billing using Stripe, with standard subscription logic | Does not qualify | Routine development using a well-documented, established third-party API; no technological uncertainty |
| ML anomaly detection | Applying a pre-trained anomaly-detection model to a new category of operational data | Does not qualify | Applying an existing model to a new dataset; the model and the methodology are established; the advance is in the data, not in science or technology |
| Novel compression algorithm | Investigating whether a domain-specific compression technique can reduce storage by 60% below what DEFLATE achieves, where no published algorithm achieves this on the data type | Potentially qualifying | Advance sought in an objective technical capability; uncertainty about whether it is achievable; competent professional could not readily deduce the solution from existing methods |
| Multi-tenant UI redesign | Rebuilding the dashboard and settings pages across the product | Does not qualify | Cosmetic and UI work; no scientific or technological advance; no uncertainty beyond standard engineering execution |
| Real-time protocol bridge | Bridging two systems with conflicting real-time message-ordering guarantees where the interaction effects are genuinely unknown and no published approach addresses this combination | Potentially qualifying (verify specifics) | Genuine uncertainty about whether consistent ordering can be achieved; competent professional would not readily deduce the solution; confirm exact technical facts against CIRD guidance before claiming |
In this illustrative example, three of six workstreams potentially qualify. The R&D claim covers costs attributable to those three workstreams, not total engineering spend. The qualifying fraction matters, and it must be supportable with contemporaneous technical records.
A quick eligibility checklist
Before deciding whether a piece of work belongs in your R&D claim, run it through these questions. All four must be answered yes for the work to be potentially qualifying.
- Was there an advance sought in science or technology, not just in your company's own knowledge or in business capability?
- Was there genuine technological uncertainty about whether or how the objective could be achieved, where the outcome was not known in advance?
- Could a competent professional in the relevant sub-field NOT readily deduce the solution from existing scientific or technological knowledge?
- Was the work not routine, i.e. not the application of standard techniques in the normal way, however carefully or expensively?
If you reach a yes to all four, the work is potentially qualifying and the next step is to quantify the attributable costs accurately. If you are unsure on any of them, that uncertainty is worth resolving before the claim is filed, not after the Additional Information Form is submitted.
Why honesty in your claim protects your company
Weak or inflated R&D claims do not sit quietly with HMRC. Under the current regime, a detailed Additional Information Form must be submitted before the CT600 claim. HMRC uses the AIF to identify claims where the described work does not meet the qualifying test. Claims filed without a valid AIF are removed. Claims where the AIF describes non-qualifying work can trigger a compliance enquiry, which costs time, money and management attention regardless of outcome.
The volume-mill model works by filing large claims and hoping HMRC does not look closely. For funded, scaling companies, the downside of that approach is asymmetric: the repayment demand, interest and potential penalties on a removed claim far outweigh any uplift from claiming non-qualifying work. A defensible claim over a smaller qualifying base is worth more than an inflated claim that sits in HMRC's enquiry pipeline.
Once you have confirmed your qualifying workstreams, the next decision is which route applies. Most scaling software companies will use the merged scheme, which gives a 20% expenditure credit above the line. Loss-making companies whose qualifying R&D spend is at least 30% of total expenditure may qualify for ERIS, which provides an 86% additional deduction and a 14.5% payable credit. The R&D relief estimator gives an indicative figure for your scenario.
If this is your first claim (or your first claim in three years), the notification deadline is six months from the end of your accounting period. Miss it and the claim is invalid regardless of eligibility.
For a full account of how the merged scheme and ERIS work, see the merged R&D scheme guide. For the AIF requirements, see the AIF guide. If you are ready to talk through your specific workstreams and costs, the R&D claims service is the right starting point.
For more on what makes a software or SaaS business's R&D position defensible, see the relevant sections of the software development companies hub and the SaaS companies hub.