Most of the software work we do for SMEs qualifies for R&D tax relief under the UK scheme. Most of the SMEs we work with had no idea this was true before we started telling them.
The result of that gap, multiplied across hundreds of software projects each year, is a meaningful amount of money that small UK businesses are leaving with HMRC because they don't know they can claim it back.
This post is a plain-English version of what we tell clients about R&D tax credits — what qualifies, what doesn't, and what to do about it. It is not legal or tax advice; we work with a specialist firm for the actual claim. But the rules are not as obscure as the consultancy industry has made them sound.
The short version
If your business has paid for software development this year, part of that cost is probably claimable as R&D relief. For an SME, the relief can be worth up to roughly 27% of qualifying development costs (the exact figure depends on the current rate, which changes — but it has been in this range for years).
A £100,000 development project might therefore reduce your tax bill by ~£27,000. Or, if the business is loss-making, deliver a cash credit at a slightly lower rate.
For most of the SME clients we work with, this is a not-small amount of money. And nearly all of them were unaware of it before we mentioned it.
What HMRC is actually asking
The legal language is about "advancing science or technology" by "resolving technological uncertainty." That sounds intimidating. In plain English, it boils down to one question:
At the start of the project, was it clear how to build the thing?
If yes — if every part of the system was a well-trodden pattern your team had built before, with off-the-shelf components, no custom work, no genuine engineering judgement — then probably not, or only small parts qualify.
If no — if at the start of the project there were technical problems you didn't have a known solution for, that you had to investigate, prototype, sometimes fail at — that's R&D. The work of resolving that uncertainty is the qualifying part of the project.
This is much broader than people think. "Resolving uncertainty" doesn't mean inventing a new field of computer science. It means making decisions where the right answer wasn't obvious in advance.
Things that usually qualify
From projects we've actually claimed on:
- Designing a domain model from scratch for a business with no prior software encoding of its workflow. The exploration, the trade-offs, the iterations — that's R&D work.
- Integrating with a third-party system whose documentation is incomplete. Working out what the API actually does, in practice, when it's different from what the docs say — that's resolving uncertainty.
- Performance work to make something feasible that wasn't obviously feasible at scale. Profiling, redesigning, benchmarking.
- Offline-first or sync architecture where the conflict-resolution rules have to be designed for a specific business context. There is no off-the-shelf "sync" you can buy.
- AI/ML integration where you're working out which model, which prompts, which retrieval approach, which evaluation criteria — almost all of which is genuine exploration.
- Replatforming a legacy system where you have to reverse-engineer behaviour that exists only in code and people's heads.
For a sense of scale: roughly 60-80% of the development hours on most of our line-of-business projects end up qualifying. It's not a small slice.
Things that usually don't qualify
Be honest with yourself about these:
- Re-skinning an existing system, or doing standard UI work on a CRUD app.
- Configuring an off-the-shelf product (CRM, ERP, e-commerce platform). The configuration is not R&D, even if the result is valuable.
- Routine maintenance, bug fixes, security patches.
- Training and project management time, generally — though specific PM time spent on technical uncertainty can sometimes be included.
- Hosting and infrastructure costs are not directly claimable (some related costs are).
The dividing line is whether the work involved genuine technical investigation. "Hard" isn't the test; "uncertain at the outset" is the test. Difficult work that follows a known recipe doesn't qualify. Easier-feeling work that required figuring out the recipe does.
Why most SMEs leave the money on the table
Three reasons we encounter repeatedly:
- "I thought R&D meant inventing a new technology." The Hollywood version of R&D — labs, white coats, patents — is what people imagine. The HMRC definition is much broader and explicitly includes software development.
- "My accountant didn't mention it." Many general-practice accountants don't routinely handle R&D claims. They know the relief exists; they don't necessarily prompt clients to consider it.
- "It sounded like a lot of paperwork for not much money." This is the one that costs the most. The paperwork is real but proportionate, and "not much money" is wrong for any project of meaningful size.
What documentation you actually need
The technical documentation HMRC wants — assembled by you, your developer, or a specialist firm — is essentially:
- What was the technological uncertainty at the start of the project? What didn't you know how to do?
- What did you try? Including the things that didn't work.
- What was the outcome? What did you learn?
- Who worked on it, and roughly how much time did each person spend on the qualifying work versus the non-qualifying work?
This is not a heroic amount of documentation. It is dramatically less than a typical project's design docs. The trick is to capture it as you go, not to reconstruct it eighteen months later from memory.
We've started building a lightweight "R&D notes" habit into every project: a short note appended to each sprint summary about what was uncertain, what we tried, and what we learned. By the time the claim comes around, the documentation has already been written.
When to use a specialist, when to DIY
Most SMEs we know use a specialist R&D tax firm to prepare the claim. The firm typically charges a percentage of the resulting credit — call it 15-25%, depending on the firm and the claim size.
This is worth it, in our view, for two reasons:
- The technical narrative writing is a skill, and specialists are good at framing the work in language HMRC accepts.
- HMRC has been scrutinising claims more closely in recent years. A specialist firm is better placed to defend a claim under enquiry than a one-off effort.
That said, for a small claim from a sole developer, doing it yourself is viable. The HMRC guidance is online, the form is not complicated, and for a £10-20k claim the specialist fee is a meaningful share of the credit.
[YOU: confirm — we work with a specific R&D specialist firm we trust. Worth naming them here? Or leaving it deliberately neutral so the post doesn't read as an advert for them?]
What we actually do for clients
Our involvement is on the technical side, not the tax side. Specifically:
- We flag projects where R&D relief is likely to apply, at the start of the engagement.
- We document the technological uncertainty in a way that's useful for a future claim, as part of normal project work.
- We work with whichever R&D tax specialist the client picks to provide the technical narrative for the claim.
- We do not charge for any of this — it's not a service line, it's a thing we do for clients because the money belongs to them.
We're not R&D tax advisers. We're software engineers who've seen enough of these claims to know what works and what doesn't.
The takeaway
If you've paid for software development in the last two years and you have not looked at R&D tax relief, look at it. The window for claiming is two accounting periods, so claims for older work are usable but time-bounded.
For a UK SME spending £50k-£500k a year on development, this is meaningful money. The work of capturing the documentation, well, the work has already been done — it lives in the project itself. Most of what's needed is just being deliberate about telling HMRC what you already know.
Red Owl IT is a Microsoft software consultancy in Bath. We help SMEs identify and document qualifying R&D work as part of normal project delivery. If you're not sure whether your project counts, we'd happily take a look.
This post is general information, not tax advice. Talk to a qualified adviser before claiming.