Why Software FDs Assume They Do Not Qualify
The phrase "research and development" carries connotations of laboratories, white coats, and university spin-outs. Finance directors at software businesses often operate under the impression that R&D tax credits were designed for pharmaceutical companies testing compounds or aerospace engineers building prototypes, not for a 25-person SaaS company in Reading or a 50-person fintech in Leeds.
That assumption is understandable. The name of the relief does not help. Neither does the fact that many general accountants have limited exposure to R&D claims and rarely raise the subject with technology clients. A significant number of software companies have been paying more corporation tax than they owe, year after year, because the question was never asked.
The assumption is also wrong. HMRC's definition of R&D is deliberately technology-neutral. It was written to capture any project, in any sector, that resolves genuine scientific or technological uncertainty. Software development, because it routinely requires developers to solve problems that have no established solution, frequently meets that test.
HMRC's own annual statistics make the picture clear. In 2022 to 2023, the Information and Communication sector submitted 22,645 claims, more than any other sector including Manufacturing, Construction, or Professional Services. The average claim value for those companies was approximately £66,000. These are not exceptional businesses making unusual claims. They are ordinary software companies that asked the right questions.
The finance directors who have not claimed are not making a considered judgement that they do not qualify. Most have simply never had anyone sit down with them and work through what their developers actually do.
HMRC's Definition: Technology-Neutral by Design
The legal framework for R&D tax relief in the UK is set out in the Corporation Tax Act 2009 and applies HMRC's definition drawn from the Department for Science, Innovation and Technology guidelines. Those guidelines were written with deliberate breadth.
R&D for tax purposes takes place when a project seeks to achieve an advance in overall knowledge or capability in a field of science or technology, and involves the resolution of scientific or technological uncertainty. That uncertainty exists when a competent professional working in the relevant field could not readily deduce the solution from the existing state of knowledge.
HMRC's guidance explicitly states that software can constitute R&D. It gives examples including operating systems, programming languages, data management tools, communication systems, and software development tools. There is no requirement that the work be academically novel. The standard is whether the uncertainty existed for a practitioner in the field.
What this means in practice is that the test is applied at the level of your specific technical problem, not at the level of your product category or industry. A SaaS company is not automatically included or excluded. The question is whether, on a given project, your developers were working through uncertainty that a competent professional could not have resolved from known methods.
The advance does not need to be published or patentable. It does not need to benefit the world beyond your company. It needs to represent an advance in the state of knowledge or capability, even if that advance is understood only within your team. HMRC accepts that companies sometimes advance knowledge without any external documentation of that advance.
This definition has been applied consistently across thousands of software claims. There is a substantial body of precedent, and specialist advisers have a clear picture of what HMRC accepts and what it scrutinises.
Qualifying Activities: A Practical Guide
The following areas consistently produce qualifying R&D expenditure in software businesses. Each requires the same underlying test to be met: was there genuine technical uncertainty at the outset, and did your team work systematically to resolve it?
Novel Algorithms and Data Processing
If your team created an algorithm that processes, classifies, or analyses data in a way that existing approaches could not achieve at the required level of speed, accuracy, or scale, that is a strong candidate. The advance needs to be demonstrable. It is not sufficient that the algorithm is new to your company; it must represent an advance beyond what was publicly available at the time.
Common examples include ranking and recommendation systems built to handle constraints that off-the-shelf solutions could not meet, real-time processing pipelines designed to operate below latency thresholds that existing tools breached, and compression or transformation approaches devised for data formats or volumes that standard libraries were not designed for.
Proprietary Platforms with Technical Constraints
Building infrastructure or processing systems that required overcoming specific technical barriers is a well-established category of qualifying work. The barrier needs to be genuine. Performance requirements that led your engineers to abandon standard architectures and develop their own approaches, concurrency models that existing frameworks could not support, or fault-tolerance requirements that pushed you to invent new coordination mechanisms all represent the kind of technical constraint that produces qualifying expenditure.
Machine Learning and AI Development
Training custom models on novel data domains, designing new architectures for specific tasks, adapting existing techniques to contexts where they had not been validated, or developing training pipelines that required methodological invention can all qualify. Using an off-the-shelf model via an API does not. The distinction is between applying known tools and genuinely advancing the state of what those tools can do in a particular domain.
Security and Cryptography
Developing new approaches to authentication, encryption, or data protection where standard solutions were technically inadequate can qualify. This includes situations where your system's threat model, performance requirements, or data sensitivity created constraints that existing security libraries could not satisfy without modification or extension.
System Integration at Technical Limits
Integrating systems that were not designed to work together, in ways that required original technical solutions, can qualify provided no known method existed at the start. The key is that the integration challenge required invention, not just configuration. Where a developer spent weeks writing and rewriting a protocol translation layer because there was no established approach for the combination of systems involved, that is a candidate. Where a developer used a documented API connector in the expected way, it is not.
What Does Not Qualify
Many companies overstate their qualifying expenditure by including work that does not meet the technical uncertainty test. HMRC's compliance activity has increased substantially since 2021, and poorly prepared claims attract enquiries. Understanding exclusions clearly is as important as understanding what qualifies.
HMRC is explicit that routine software development does not qualify, even if the end product is commercially innovative or the project was large and complex. The distinction is always between technical novelty and commercial novelty.
Deploying existing frameworks and tools. Building an application using established frameworks such as React, Django, Next.js, or Salesforce does not constitute R&D if the development work involved selecting and applying these tools in the expected way. The application itself may be new to market; if the technical approach involved no uncertainty, the development does not qualify.
Standard database configuration and querying. Setting up databases, writing conventional queries, designing standard schemas, or building data pipelines using known architectural patterns does not qualify. Where a database performance problem required a genuinely novel approach, that specific element may qualify, but the surrounding work does not.
User interface and experience work. Design work, front-end implementation, animation, and user experience optimisation are excluded unless they involve solving a technical problem in human-computer interaction that goes beyond the application of established design and engineering practices.
Reproducing existing functionality. Work that replicates known functionality, adapts established solutions to a new context, or applies a documented pattern to a new project does not qualify even if the work was technically skilled and time-consuming.
Routine maintenance and bug fixing. Standard defect correction, performance tuning using established techniques, and software updates do not qualify. Where a defect reveals a fundamental architectural problem requiring novel engineering to resolve, that portion may qualify, but the identification and correction of standard bugs does not.
Business requirements analysis and project management. Time spent gathering requirements, writing specifications, managing projects, or conducting user testing does not qualify. These are excluded categories explicitly listed in HMRC's guidance.
How to Identify Qualifying Projects
The practical approach is to speak with your lead developers and ask them where they encountered problems that did not have obvious solutions. Where did they try multiple approaches before finding something that worked? Where did they spend significant time on something they could not find a solution for in documentation, academic papers, or established libraries?
Those conversations surface qualifying work more reliably than any desk-based review of project logs. Developers know when they were in genuinely uncertain territory. They remember the problems that kept them awake. Those are the projects worth examining.
The following questions are useful diagnostics:
- Was there a point in this project where your team did not know whether the approach would work?
- Did you try one or more approaches that failed before finding a solution?
- Could a competent developer have looked up the answer in standard documentation?
- Did the solution require you to extend, adapt, or invent beyond what existing tools could do?
- Was the technical problem specific enough that it was unlikely anyone else had solved it in a documented way?
A yes to the first two questions and a no to the third is a strong starting signal. A specialist adviser will then work through the project in more detail to establish whether the uncertainty meets HMRC's definition and whether the work was approached systematically.
The Documentation HMRC Expects
Since August 2023, all R&D claims must be accompanied by an Additional Information Form submitted to HMRC before or alongside the corporation tax return. This form requires project-level technical descriptions and cost breakdowns. The days of submitting a claim with minimal narrative are over.
-
1
Project descriptions
For each qualifying project, you need a description of the scientific or technological advance being sought, the uncertainty that existed at the start, and how your team worked to resolve it. This does not need to be written by HMRC standards from scratch; a specialist will shape your technical input into the required form.
-
2
Staff time records
HMRC expects contemporaneous records of how staff time was allocated to qualifying activities. Formal timesheets are ideal but not mandatory. Project tracking data, sprint records, commit histories, and manager sign-off on time allocations all contribute. The weaker your records, the more conservative your claim will need to be.
-
3
Cost substantiation
Payroll records, employer National Insurance and pension records, and invoices for subcontractors and qualifying software licences need to be traceable. For companies with clean payroll records and project-coded accounting, this is straightforward. For companies with informal processes, some reconstruction work is required.
-
4
Competent professional sign-off
HMRC expects that someone with relevant technical expertise has confirmed that the work involved genuine uncertainty. In most software companies this is the CTO, lead engineer, or a senior developer. Their input gives the claim technical credibility and reduces the risk of enquiry.
-
5
Director approval and submission
The claim is submitted as part of the corporation tax return. A company officer must approve it. Your specialist adviser prepares the Additional Information Form and the supporting cost schedule, and your accountant incorporates the relief into the CT600.
Worked Example: 25-Person SaaS Company in London
Consider a 25-person SaaS company based in London, building a B2B data platform. The company has a 31 March accounting year end and is profitable, paying corporation tax at 25%. Six developers spend a portion of their time on qualifying R&D activities, alongside two data scientists.
This example reflects a conservative time allocation. Companies with higher proportions of qualifying activity, or where data science and ML work is central to the product, would see higher totals. For this company, a claim of over £70,000 is realistic in a single year. Two years' worth of claims, where both periods are still open, could exceed £140,000.
"A claim of £70,000 in a single year is not an outlier for a 25-person software business. It is what the numbers produce when you apply the qualifying rules carefully to a team doing genuine technical work."
The Two-Year Deadline
R&D tax credit claims must be submitted within two years of the end of the accounting period to which they relate. There is no power to extend this deadline under any circumstances. Missing it means losing the relief permanently for that period.
If your accounting year ended 31 March 2024, you have until 31 March 2026 to submit a claim for that year. If your accounting year ended 31 March 2023, that deadline has already passed. Act on any open periods before turning to future planning.
Many software companies discover R&D relief late in their development. A company that has been trading for five years and never claimed may find that only the two most recent accounting periods remain open. The time to act is now, not after a reorganisation or a change of accountant.
Uplift Tax's first step with every new client is to establish which accounting periods are still within the two-year window and whether a retrospective claim is feasible. If a deadline is approaching, we escalate accordingly.