R&D Tax Credits

What Qualifies as R&D in Software Development?

HMRC has a specific definition of R&D that many software companies misunderstand. Here is what actually qualifies, with examples.

HMRC's Definition of R&D

HMRC follows the Department for Science, Innovation and Technology (DSIT) guidelines. Under these guidelines, R&D for tax purposes occurs when a project seeks to achieve an advance in overall knowledge or capability in a field of science or technology through the resolution of scientific or technological uncertainty.

This is a higher bar than most people expect. It is not enough that the work is technically challenging or that it was new to your company. The advance must be in the overall field, and the uncertainty must be one that a competent professional in the field could not readily resolve.

The Three Key Tests

For software work to qualify, it must pass all three of these tests:

1. An Advance in Science or Technology

The project must aim to create something that extends the overall knowledge or capability in the relevant technical field. This could be a new algorithm, a novel approach to a known problem, or a system that operates at a scale or with constraints not previously achieved. Using existing tools, libraries, or frameworks in standard ways, even if the implementation is complex, does not constitute an advance.

2. Scientific or Technological Uncertainty

There must be genuine uncertainty about whether the desired outcome is achievable, or about how to achieve it. The uncertainty must be technological, not commercial or aesthetic. "Will users like this feature?" is not technological uncertainty. "Can we process 10 million events per second with sub-100ms latency on this architecture?" may be.

3. Not Readily Deducible

The solution must not be one that a competent professional working in the field could easily work out. If the answer is in the documentation, a textbook, or a well-known pattern, it does not qualify. The competent professional test is not about whether anyone in the world could solve it, but whether someone with standard professional knowledge in that specific field could.

Examples: What Qualifies and What Does Not

Likely Qualifies

  • Developing a custom real-time data pipeline that needed to handle a specific combination of throughput, latency, and ordering guarantees that existing tools could not provide out-of-the-box
  • Building a machine learning model for a domain where labelled training data was scarce, requiring novel data augmentation and transfer learning approaches
  • Creating a distributed consensus algorithm for a multi-tenant system with specific consistency requirements that existing solutions (Raft, Paxos) did not address
  • Developing a compiler or code analysis tool that needed to handle language features or edge cases beyond what existing parsers supported

Unlikely to Qualify

  • Building a standard web application using React, Node.js, and PostgreSQL, even if the business logic is complex
  • Integrating third-party APIs following their documentation
  • Migrating from one cloud provider to another using standard migration tools and patterns
  • Building a mobile app using React Native or Flutter following established patterns
  • Performance optimisation using well-known techniques (caching, indexing, CDNs, query optimisation)
  • Fixing bugs, even complex ones, in existing systems

The Grey Area: Where Most Software Companies Sit

In practice, many software projects contain both qualifying and non-qualifying work. A project to build a recommendation engine might involve qualifying R&D (developing a novel ranking algorithm for a specific data distribution) and non-qualifying work (building the API endpoints, the admin dashboard, and the A/B testing framework).

The key is to be honest about which parts genuinely involved technological uncertainty. Over-claiming is the fastest way to trigger an HMRC enquiry. Under-claiming leaves money on the table. Getting the balance right requires careful analysis of what your developers actually worked on.

How to Document Your R&D Activities

Since April 2023, all R&D claims must include an Additional Information Form (AIF) with structured technical narratives. For each qualifying project, you need to describe:

  1. The field of science or technology
  2. The baseline level of knowledge before you started
  3. What advance you were trying to achieve
  4. The scientific or technological uncertainties you faced
  5. How you attempted to overcome those uncertainties
  6. What you achieved (or did not achieve)

Your commit history, pull request descriptions, and technical design documents are valuable evidence. They show what decisions were made, what alternatives were considered, and what challenges were encountered in real time.

Automating the Analysis

CodeClaim reads your GitHub commit history and uses AI to identify commits that may represent qualifying R&D activity. It groups related commits into features, assesses each against HMRC's criteria, and drafts the technical narratives required for the AIF.

This gives your accountant or R&D adviser a structured starting point rather than a blank page, saving significant preparation time.

This article is for general information only and does not constitute tax, legal, or financial advice. Consult a qualified tax adviser before making any R&D tax credit claim. See our Terms of Service for full disclaimers.