Software R&D tax credit claims in the UK are among the most contested. The legal test under the DSIT Guidelines 2023 requires genuine scientific or technological uncertainty, not just commercially novel development. HMRC looks past what your software does to how it does it, and whether that presented a problem a competent professional could not have readily solved.
Table of Contents
- What is the legal test for software R&D tax credits?
- Why does HMRC scrutinise software claims differently?
- What types of software development work qualify?
- What doesn't qualify for software R&D tax credits?
- What is the competent professional test in a software context?
- How has AI shifted the bar for software R&D claims?
- What happens if HMRC challenges your software R&D claim?
- Frequently asked questions
What is the legal test for software R&D tax credits?
Software R&D tax credit claims are governed by the DSIT Guidelines 2023, which carry legal force under s.1006 ITA 2007.
The statutory test has two components:
- the work must seek an advance in overall knowledge or capability in science or technology, and
- it must do so through the resolution of scientific or technological uncertainty.
Uncertainty is defined in paragraph 13 of the DSIT Guidelines as existing when knowledge of whether something is technically feasible or how to achieve it in practice "is not readily available or deducible by a competent professional working in the field."
The advance must be an advance in overall knowledge, not simply something new to your company or your development team.
Building software that is new to your business, or new to your market, does not satisfy the test. The question is always whether the underlying technology was advanced. That distinction is where a significant number of software claims fail, and where HMRC is focusing its attention.
Why does HMRC scrutinise software claims differently?
HMRC dedicates more guidance to software than to almost any other sector. CIRD 81960 specifically addresses how the general R&D definitions apply to software, and CIRD 81980 provides case studies illustrating the line between qualifying and non-qualifying work. That additional guidance exists because software claims are disproportionately prone to overclaiming.
The structural problem is this: any software system can be understood as two layers.
- The top layer is the functionality layer, describing what the system does and how it serves its users.
- The bottom layer is the technology layer, meaning the architecture, algorithms and engineering choices that deliver that functionality.
From HMRC's perspective, the functionality layer is almost entirely irrelevant. Their assessors look straight through it to the technology layer and ask:
what was happening there, and why was it technically difficult?
This catches many claimants off guard. A team that has built a sophisticated and commercially novel product will naturally describe what the system does. HMRC's caseworkers, now routinely supported by the internal CDIO (Chief Digital and Information Office) team, are asking a different question entirely.
HMRC was historically more lenient with software claims. That position changed materially over the past several years as CDIO officers took a more active role in enquiries. These are technically trained specialists who begin from a position of scepticism and ask precise questions about the technology layer.
A software claim that might have been accepted without challenge five years ago may not survive the same scrutiny today.
What types of software development work qualify?
CIRD 81960 identifies several broad categories that can qualify, subject to the uncertainty test being met:
- Non-trivial improvements to software that advance overall capability beyond the current state of the art, where the improvement would be recognised by a competent professional as genuine and non-trivial (per paragraph 23 of the DSIT Guidelines)
- Work that goes beyond existing software capabilities, where no established approach existed at the relevant date and genuine investigative work was required
- Complex system integrations involving technically uncertain interactions between architectures, data sources or protocols, where the uncertainty could not be resolved by applying documented approaches
- Novel algorithm development, particularly where a new mathematical or computational approach was itself the subject of the uncertainty
The claims that withstand scrutiny in my experience share one characteristic: the development team encountered a technical problem they could not resolve by applying known methods, and the process of investigation, iteration and failure is documented in a way that demonstrates genuine uncertainty.
The work does not need to succeed. Under paragraph 10 of the DSIT Guidelines, R&D occurs even where the advance sought is not achieved.
What doesn't qualify for software R&D tax credits?
The DSIT Guidelines and CIRD 81960 are clear about the activities that fall outside the definition. The following generally will not qualify:
- Configuring software, including the setup of commercial platforms, SaaS products or off-the-shelf systems
- Routine adaptation, such as tailoring existing systems to a new business context using established techniques and standard tooling
- Optimisation and fine-tuning that does not materially affect the underlying science or technology
- Building systems that are commercially novel but technologically routine, where the development draws entirely on well-understood frameworks and known approaches
The "bespoke" or "custom-built" label causes persistent confusion here. A system can be entirely bespoke, built for a specific client from scratch, and still involve no qualifying R&D. Bespoke means new to the buyer. That is not the same as technologically uncertain. Paragraph 22 of the DSIT Guidelines states directly that the routine adaptation of an existing process will not advance overall knowledge or capability, "even though it may be completely new to the company."
Agile development methodology creates a specific risk in this context. Iterative sprints generate a lot of visible activity, and the pace and complexity of delivery can create an impression of significant technical challenge. The development method is not, however, the test. The question is always whether genuine technological uncertainty existed at the outset of the relevant work, and whether investigation to resolve that uncertainty was the reason the activity was undertaken.
What is the competent professional test in a software context?
The competent professional test requires that the uncertainty was not "readily available or deducible" to a person with relevant expertise working in the field at the time of the project. In a software context, this is a technically demanding standard.
Software moves faster than almost any other sector. A technical problem that presented genuine uncertainty in 2021 may now have an established solution documented across multiple open-source repositories, developer forums and published tooling. CIRD 81960 expressly acknowledges that "an advance one year might not be considered an advance next year." The baseline year matters, and HMRC will probe it.
There is also a question of who constitutes the competent professional within the claiming organisation. If development was outsourced to an agency, but the agency is not named in the claim and has contributed nothing to the technical narrative, HMRC will question whether a competent professional was involved at all. Claims built around a director's commercial vision, with limited technical input from the engineers who wrote the code, rarely withstand enquiry.
The competent professional should be able to describe the state of technology at the start of the project, explain why the problem could not be resolved using existing approaches, and give a clear account of what was tried, what failed, and how the uncertainty was eventually resolved or abandoned.
How has AI shifted the bar for software R&D claims?
This is the most significant structural development affecting software claims right now, and most claimants and advisors are not yet thinking about it carefully.
The DSIT Guidelines have not changed. The uncertainty test is the same statutory test it was in 2023. But the practical baseline against which that uncertainty is assessed has moved. AI coding tools allow a competent professional to synthesise approaches from millions of repositories in seconds. Problems that required genuine sprints of engineering effort to resolve in 2022 may now be rapidly addressable by a developer working alongside an AI assistant.
The definition of "readily deducible" shifts accordingly.
HMRC has not yet issued formal guidance on AI-assisted development and its interaction with the uncertainty test. But the direction of travel is clear. Claims that characterise API integration complexity, performance optimisation or system architecture as inherently uncertain are increasingly exposed, particularly for accounting periods from 2024 onwards. Where AI tools formed part of the development workflow, the burden of demonstrating that genuine uncertainty remained will fall more heavily on the claimant, and the technical narrative will need to address this directly.
The answer is not to stop claiming. Genuine software R&D continues in volume, particularly in frontier AI research, regulated environments where AI-generated code is restricted, novel algorithm development and complex systems operating under unusual constraints. The answer is to be precise about where the uncertainty actually existed, and to document it in terms that reflect the current capability of both experienced developers and AI tooling.
What happens if HMRC challenges your software R&D claim?
HMRC's CDIO team is now routinely involved in enquiries into software claims. These officers approach the claim from a starting position of scepticism and ask highly specific technical questions. If an enquiry involves a CDIO officer, the response needs to be forensically prepared. A generic defence that restates the commercial purpose of the software will not be sufficient.
HMRC will ask specific questions about the technology layer, the credentials and direct involvement of the competent professional, the baseline state of technology at the relevant accounting period, the specific uncertainties encountered and what approaches were attempted before the solution was found. Vague answers invite follow-up requests and significantly extend the enquiry.
I have handled software R&D enquiries where the original claim was prepared by a volume agent with no meaningful technical input from the development team. In those cases, rebuilding a defensible technical narrative years after the work was completed is both difficult and costly. It is significantly better to prepare the claim correctly on the way in.
If a software claim has already attracted an enquiry, it should be treated as a specialist matter. HMRC can seek to disallow the full claim, and penalties apply where a submission is found to have been inaccurate.
Key takeaway: HMRC does not care what your software does. It cares how it does it, why that was technically uncertain, and whether a competent professional with access to current knowledge, including AI tools, could have deduced the solution without investigative work.
For guidance on how the defence process works if an enquiry has already opened, see the page on R&D tax credit defence. If you have received a formal written enquiry, the practical steps are set out at how to respond to an HMRC enquiry letter.
Frequently asked questions
Does agile development methodology qualify for software R&D tax credits?
Agile methodology does not determine eligibility. Agile, waterfall or hybrid approaches can all produce qualifying R&D, provided that genuine technological uncertainty was present and the activities were directed at resolving it. Agile projects require careful scoping: only the sprints or phases that addressed technically uncertain problems should be included in the claim. Routine delivery sprints, however iterative, do not qualify.
Can a company claim R&D tax credits for software developed by subcontractors?
Yes, but the rules are specific. Under the merged scheme applicable to accounting periods beginning on or after 1 April 2024, the contracting company can include qualifying subcontracted costs subject to certain conditions. The critical question is whether R&D was required from the outset of the contract. Where the need for R&D only became apparent during delivery, the analysis is more nuanced. Only one company in the chain should be claiming in respect of the same activity.
What is the difference between qualifying software R&D and ordinary commercial software development?
Qualifying software R&D involves genuine scientific or technological uncertainty that requires investigation and experimentation to resolve. Ordinary commercial software development uses known tools, frameworks and approaches to deliver a product that may be new to the business or market but does not advance the underlying technology. The fact that the output is commercially novel, valuable or bespoke does not determine whether R&D occurred.
Does it matter whether the software is for internal use or for sale to third parties?
No. CIRD 81960 confirms that eligibility is not affected by whether the software is developed for licensing, sale or internal deployment. The same DSIT Guidelines test applies regardless of the intended use. What matters is whether the development involved genuine technological uncertainty and sought to advance overall knowledge or capability in science or technology.
How does HMRC identify software R&D claims for enquiry?
HMRC uses risk-based profiling including SIC codes, Agents who prepared the claims and the AIF narratives (AI scans). Software claims attract attention for several reasons: high claim-to-payroll ratios, claims in sectors where software is incidental to the core business, claims prepared by high-volume agents and claims covering a large proportion of total employee costs. Since the introduction of the mandatory Additional Information Form, HMRC has detailed structured data on every claim and can identify thin or generic technical descriptions quickly.
What documentation should support a software R&D tax credit claim?
At minimum, the claim requires a technical narrative that identifies the specific projects claimed, describes the baseline state of technology at the start of each project, articulates the specific uncertainties encountered, explains what approaches were tried (including those that failed) and describes how the uncertainty was eventually resolved. The narrative should be written by, or with the direct input of, a technically qualified person who was involved in the work. Generic descriptions of project scope or commercial objectives are not sufficient.
Can a small software company or startup claim R&D tax credits?
Yes. Company size and organisational structure do not determine eligibility. The same statutory test applies to a two-person startup as to a listed technology company. What matters is whether qualifying R&D activities occurred and whether at least one person involved had the technical knowledge to understand and articulate the uncertainty. The documentation burden is the same regardless of company size.
Ready to review your software R&D claim?
Software R&D claims are disproportionately scrutinised, and the technical bar is rising as AI reshapes what a competent professional can be expected to deduce. Whether you are preparing a claim for the first time, reviewing a claim before submission, or responding to an HMRC enquiry into a software project, specialist input at an early stage saves significant time and money.
I work with companies across software, SaaS, fintech and technology-enabled sectors to build claims that will withstand scrutiny, and with those defending claims that were originally prepared without adequate technical grounding.
Contact me at stevelivingston@iptaxsolutions.co.uk or call 0161 961 0096 to discuss your position.
