R&D tax credits for software startups: what still qualifies

The test has not moved. You need a project that sought an advance in science or technology, and that advance had to be uncertain to a competent professional in the field. The two words doing the work are advance and uncertainty.

Advance means the underlying capability improves, not your product. Building a better checkout flow for your own customers is commercial progress. Building a way to reconcile event streams at a volume and latency that published approaches do not handle is a technical advance, even if the end result is still your checkout.

Uncertainty means a capable developer in your field could not have told you at the outset whether it would work, or how. If the answer was on Stack Overflow, in the framework documentation, or available from a vendor for a monthly fee, there was no uncertainty. The fact it took your team three weeks to find it does not change that.

HMRC also wants the competent professional named. Not the finance director, not the adviser. The person who was in the code and can explain why the obvious approach failed. We ask for that name in the first conversation, and if nobody can give us one, that is usually the whole answer.

In our experience these are the areas where software claims hold up when someone reads them carefully:

• Performance or scale problems where the standard approach breaks down and the solution is not documented anywhere you can point to.
• Integration between systems that were never designed to talk to each other, where the constraint is technical rather than a matter of writing more connectors.
• Novel use of machine learning where the work is in making a model behave reliably on your data, not in calling an API.
• Data architecture built to handle volumes or consistency requirements that off the shelf tooling does not meet.
• Security or cryptographic work where the method itself had to be developed.

Note what these have in common. In each case you can describe a thing that did not work, a reason it did not work that is technical rather than commercial, and an attempt at a solution with an uncertain outcome. That is the shape of a defensible claim.

The costs follow the project, not the company. Staff time for the people doing the qualifying work, a share of the time for those directly supporting them, software and cloud costs consumed by the project, and externally provided workers subject to the current restrictions on overseas spend.

We say no more often than founders expect, and we would rather say it before a claim is filed than after HMRC asks.

Building your product with established tools does not qualify, however hard it was. A React front end, a Postgres database, a Stripe integration and six months of late nights is a business being built, and that is not what the relief is for.

Configuration is not development. Setting up a CRM, wiring together no-code tools, or tuning someone else’s platform to fit your process sits outside the definition, even when the result is genuinely clever.

Design, user research and testing against a specification are support activities. They can be claimed where they directly support a qualifying project, but they cannot be the project.

And then there is the claim written by a claims company that has never met your developers. We see these when a founder comes to us after an HMRC enquiry. The narrative describes commercial ambition in technical language, nobody is named as the competent professional, and the cost apportionment is a round percentage of payroll with no working behind it. Those are the ones that fall apart.

The single biggest difference between a claim that goes through and one that drags on for months is whether the evidence existed before the claim was written.

You do not need a formal R&D logbook. You need enough to reconstruct what happened: ticket histories that show the problem being investigated, commit messages, architecture notes, the Slack thread where two engineers argued about whether the approach would hold at scale, a rough record of who spent what proportion of their time on which project. Most startups already generate this. Very few of them tag it in a way that makes it findable a year later.

The practical fix takes about twenty minutes. Agree a label in your issue tracker for work that is attacking a technical unknown, and ask the team to apply it as they go. At year end you have a list, dated, in the engineers’ own words, written at a time when nobody was thinking about tax.

Every claim now needs the additional information form submitted before the CT600 goes in, with the project narratives and cost breakdown, and the CT600L alongside the return. We prepare both in house, with the same person who does your year end, so the numbers in the claim and the numbers in the accounts agree.

R&D relief reduces the cost of building the thing. Patent box reduces the tax on what the thing earns once it is making money. Founders who look at one and ignore the other usually leave the bigger number behind.

Where a patent is registered and the profits are attributable to that IP, patent box can take corporation tax on those profits from 25 per cent down to 10 per cent. For a software company with a protectable technical method and a few years of growth ahead, that is a bigger long-run number than the R&D claim that funded the work in the first place.

It is not for everyone. You need something patentable, you need to actually file, and the profit attribution calculation takes real work. But the time to think about it is while you are still doing the R&D, not three years after launch when a competitor has shipped the same idea. We cover this in more detail in our post on patent box relief explained for founders.