R&D Tax Credits for Software Development Companies

A Guide to Claiming R&D Tax Credits for Software Development

Table of Contents

• Does your software development project qualify?
• Costs that you can include in your claim
• Claiming for subcontracted development
• Calculating your claim
• Things to consider during claim preparation
• Tips for preparing your software R&D tax claims
• Frequently Asked Questions

1. Does your software development project qualify?

Software development projects are often experimental by nature and contain many technology unknowns at the outset. For these reasons they often present a good case for claiming under the R&D tax credit scheme.

Firstly, in order to qualify your company must be subject to UK corporation tax and it should be funding the development project that you want to claim for. This can come in the form of paying for developers’ salaries or subcontracting the development out. There are different rules for including full-time employees and subcontractors in a claim – more on this later.

Now that you have met the basic criteria, you can start to assess the eligibility of your individual projects. To qualify, your project must meet two criteria: A technological advance through the resolution of technological uncertainty.

PS. If you are completely new to R&D Tax Credits, you can head over to our R&D scheme overview page for a top-level summary of the scheme.

1.1. The Advancement of Knowledge

To meet this criterion, you first need to examine the technology baseline – the state of knowledge that is currently available in the industry. Then you compare this baseline to your project’s own technology goals. If you are attempting to surpass this baseline in some way or you are facing unique constraints that you need to overcome then you have met this criterion.

It’s also worth noting that developing something that already exists in the market does not disqualify you from claiming R&D Tax Credits. The scheme is more concerned with the methods that you use to reach an objective rather than the objective itself. In fact, your project does not even need to be successful or complete to qualify. Also, a project that makes appreciable improvements to an existing product can also qualify.

To summarise, the advancement of knowledge could be made by you developing  a new software product or platform, but it could also mean that you are adding to the industry’s knowledge in a specific development area such as development architecture, performance, integration, security and many other areas.

1.2. The Resolution of Uncertainty

Your project meets this criterion when your solution is not either "publicly available or readily deducible to a competent professional". In other words, it’s not in the public domain and it’s not obvious. You can meet this criterion in one of 3 ways:

• Your development project presents a technical challenge and it is not known at the outset whether this challenge can be solved by a competent professional. For example, this challenge could come in the form of performance, security, scalability or reliability.
• Your project presents a technical challenge and it is known that a competent professional can solve it but it is not clear how in practice to achieve the desired result. This uncertainty would then require experimental development to resolve it. For example, you may have to test different algorithms, protocols, development frameworks etc. until you are confident that you have reached the optimal solution.
• The third type of uncertainty is called ‘system uncertainty’. This uncertainty occurs when your development project has complexity due to many different systems or technologies interacting with one another, maybe because you are stressing those components beyond their normal capabilities or using them in a new or untested way. In this case, eligibility comes from the work that’s required to resolve conflicts in these interactions.

Now that you have a better understanding of the criteria for claiming, here are few examples of project-types that often qualify:

• Frontier AI or Machine learning
• Development of neural networks
• Algorithm design
• Developing programs that process big data
• Projects that include data science
• Software development for robotics, IoT and IIoT
• Blockchain development
• Firmware development
• Game design

However, it’s important to keep in mind there are countless other examples. Your project type is less important than meeting the criteria but bear in mind that if the problem can be solved by putting a few well-formed prompts into Claude Code, it will need serious consideration about whether you are actually resolving technological uncertainty - contact us.

⇧   Back to top

2. Costs that you can include in your claim

In your software development claims, the majority of costs typically come from paying technical staff who have directly contributed to meeting the above criteria. These are usually software architects, software developers, project managers, DevOps engineers etc.

Even tasks that are seemingly routine can still be included in a claim providing they directly contribute to the resolution of technological uncertainty. Testing is the usual example given but in software development, work performed on graphics or business logic may also be allowable where they are part of the process of resolving the technological uncertainty. In these cases it is important to give HMRC the context of these activities and to give some details on how and why they were performed.

The costs of software license can also be included if the use of the software contributed to the overarching goals of an eligible project.

⇧   Back to top

3. Claiming for subcontracted development

Under the SME scheme, you can also use your subcontracted software development costs to claim R&D tax credits. There are a few things to keep in mind about claiming for subcontracted software development:

• You can only include 65% of subcontracted development costs vs. 100% of the costs of salaried employees.
• In most cases you (as the company who is funding the eligible project) will hold the right to make an R&D claim but there are some exceptions.
• If you are a loss-making company that is subcontracting a large portion of your development to a connected company, you may be subject to a recent PAYE cap that introduced by HMRC as an anti-abuse measure. Read more about this topic here.

You can read more about the topic of subcontracted R&D in our article: R&D Claims, Subcontractors and Externally Provided Workers.

⇧   Back to top

4. Calculating your software development claim

Once you have determined exactly what projects and activities should be included in your claim and you have attributed the correct amount of time and qualifying costs to each project resource, you are ready to calculate the benefit that you can expect from your claim.

• For accounting periods from 1/4/24, you will claim under either the Merged Scheme or ERIS.

For more detailed information of how various R&D claims are calculated, click here.

⇧   Back to top

R&D Tax Credits for Software Development: Key Takeaways

1. What Actually Counts as R&D in Software

HMRC focuses on technological uncertainty, not commercial novelty or project size. For software, this usually falls into three categories:

1. Technical feasibility uncertainty

You genuinely don’t know if a solution is possible within your constraints, even for a competent professional.

• Example: Achieving sub-millisecond latency on real-time data streams within a specific architecture and hardware budget.

1. Method uncertainty

You know the problem is solvable in principle, but not how to achieve the required outcome in practice.

• Example: Finding an encryption and storage strategy that preserves query performance for a huge healthcare dataset while meeting strict security and compliance requirements.

1. System uncertainty

Complexity arises from multiple systems/technologies interacting in ways that are not well understood or documented.

• Example: Integrating a legacy ERP, real-time IoT pipeline, and ML inference engine where interactions cause unpredictable behaviour that must be systematically investigated.

The uncertainty must exist in the field, not just within your team.

2. Work That Typically Qualifies

You are likely within R&D territory if you are:

• Developing novel algorithms (data processing, optimisation, search, ML) where the solution was not known at the outset.
• Building systems to meet demanding performance, security, scalability, or reliability targets that require experimental development.
• Creating AI/ML models where there was genuine uncertainty about achieving required accuracy, robustness, or fairness, and you had to experiment with:
• Architectures
• Feature engineering
• Training regimes / hyperparameters
• Data representation and augmentation
• Integrating complex systems where component interactions caused unpredictable issues that required systematic investigation.
• Developing new frameworks, libraries, or tools that extend existing platforms beyond their demonstrated capabilities.
• Solving infrastructure challenges (high availability, distributed systems, real-time or edge computing) where standard patterns were insufficient.

In all cases, you should be able to show:

• The uncertainty you faced.
• The hypotheses/approaches you tried.
• The experiments and iterations you ran.
• The knowledge gained, even if the project partially failed.
• The AI prompts that you tried, what was returned and why that didn't resolve the uncertainty.

3. Work That Typically Does Not Qualify

You are unlikely to be doing qualifying R&D if the work is mainly:

• Implementing existing frameworks/platforms following documentation, even if it’s your first time using them.
• Building standard websites, apps, or internal systems using known patterns and tools, even if the product is commercially new.
• Customising/configuring off‑the‑shelf software (CRMs, ERPs, CMSs, etc.).
• UX/UI and front‑end work where the challenge is aesthetic, usability, or content‑driven rather than technological.
• Routine bug fixing, maintenance, refactoring, and performance tuning using standard techniques.
• First‑time use of a well‑established technology that is new to your company but not new to the industry.

New-to-you ≠ R&D. The question is: was there a genuine technical unknown in the wider field?

4. AI & Machine Learning: How to Frame Your Claim

AI/ML projects are often eligible but heavily scrutinised. HMRC expects you to clearly set out:

1. The specific technical uncertainty

Examples:

• Whether a particular architecture could reach a target F1 score on noisy, imbalanced data.
• Whether you could achieve real‑time inference on edge devices with strict memory/CPU limits.
• Whether a privacy‑preserving training approach (e.g. federated learning, differential privacy) could meet both accuracy and compliance requirements.

1. Why existing approaches were insufficient

You should be able to explain:

• Which published methods, libraries, or pre‑trained models you evaluated.
• Why they failed or were inadequate (e.g. accuracy, bias, latency, resource usage, regulatory constraints).

1. The systematic approach you took

For example:

• Iterating over architectures (CNN vs. transformer, depth/width changes, attention mechanisms).
• Hyperparameter searches and training regimes.
• Data cleaning, augmentation, feature engineering experiments.
• Evaluation methods and how you decided what to keep or discard.

Simply saying “we implemented AI” or “we used machine learning” is not enough.

5. Cloud Computing & Data Costs: What You Can Now Include

For costs incurred from 1 April 2023, you can include cloud and data costs that are directly attributable to qualifying R&D, such as:

• Compute and storage for training ML models.
• Infrastructure for performance, load, and scalability testing of R&D systems.
• Development/staging environments used exclusively for R&D.
• Data processing pipelines used as part of R&D activities.

You cannot include:

• Cloud costs for production systems.
• Infrastructure for general business operations.
• Shared environments where you cannot reasonably apportion the R&D element.

You should be able to segregate or apportion R&D‑related cloud usage (e.g. by project tags, accounts, or environments).

6. The Merged R&D Scheme (From 1 April 2024)

For accounting periods starting on or after 1 April 2024:

• Headline credit rate: 20% of qualifying R&D expenditure.
• Net benefit (after 25% corporation tax): roughly 15p per £1 of qualifying spend.
• Example:
• £250,000 qualifying spend → ~£50,000 credit → ~£37,500 net benefit.

For loss‑making, R&D‑intensive companies (R&D ≥ 30% of total expenditure):

• You may qualify for ERIS (Enhanced R&D Intensive Support).
• This can provide a payable credit of up to 27% of qualifying R&D spend.
• Particularly relevant for pre‑revenue SaaS, deep‑tech, and AI/ML startups.

7. Qualifying Cost Categories for Software Companies

You can typically include:

1. Staff costs

• Salaries, employer NIC, and pension for:
• Software engineers, data scientists, ML engineers
• Architects, DevOps/SRE, QA engineers
• Technical leads and engineering managers (for their R&D time)
• Only the proportion of time spent on qualifying R&D should be claimed.

1. Subcontractor costs

• UK‑based freelancers, specialist consultancies, or outsourced teams doing R&D on your behalf.
• Under the merged scheme, generally 65% of eligible subcontractor costs can be claimed.

1. Cloud computing and data (from 1 April 2023)

• AWS, Azure, GCP, etc. directly used for R&D.
• Data acquisition costs where the data is used specifically for R&D.

1. Software licences

• IDEs, testing tools, CI/CD tools, profiling tools.
• Specialist software used in modelling, simulation, or data processing.

1. Consumables

• Physical materials consumed in the R&D process (rare for pure software, but possible in embedded/IoT contexts).

Overseas restriction (from 1 April 2024):

• Subcontractor and externally provided worker costs for R&D performed outside the UK are generally not eligible.
• If you use offshore teams, you must separate UK vs non‑UK work; only the UK portion qualifies.

8. Common HMRC Challenges for Software Claims

Expect scrutiny in the following areas:

1. Overclaiming staff time

• Claiming 100% of a developer’s time when they also handle routine activities.

2. "I could put that into ChatGPT and get the same thing"

• the rise of AI coding needs to be addressed proactively and contemporaneously.