Professional reviewing technical R&D documentation

The definition in plain English

HMRC defines technological uncertainty as a situation where the answer to a technical or scientific problem is not readily deducible from existing knowledge — even by a competent professional in that field. In other words: if a skilled expert in your area would have known the answer without needing to experiment, it does not qualify. If even an expert would have had to try things, test approaches, and risk failure to find out — it does qualify.

The key phrase is "not readily deducible." This sets the bar at a practical level, not a research laboratory level. You do not need to be inventing entirely new science. You need to be solving a problem where the outcome was genuinely uncertain and where experimentation was a necessary part of finding the solution.

Why this matters more than any other test

Every other aspect of an R&D claim — the costs you include, the staff time you apportion, the subcontractor payments you claim — depends entirely on whether the underlying activity involved resolving genuine technological uncertainty. If it did not, the claim fails regardless of how well the rest of it is structured. This is the first question HMRC asks when reviewing any R&D claim, and it is where the majority of challenged or rejected claims fall down.

What passes the test and what does not

✓ Likely to qualify

  • Building a system that had to handle a combination of requirements no existing solution could address
  • Developing a new material or formulation where the outcome of the process was unknown until tested
  • Creating software architecture to solve a performance problem where established approaches were insufficient
  • Adapting a process for a new environment where the adaptation required experimentation to get right
  • Developing a novel algorithm where the approach was not established in existing literature or practice

✗ Unlikely to qualify

  • Building a website or app using standard, established frameworks and tools
  • Configuring off-the-shelf software to work with your existing systems
  • Reproducing existing technology in a slightly different form without technical novelty
  • Routine product development where the approach was known and the outcome predictable
  • Business process changes that do not involve a scientific or technological problem

The "competent professional" standard

HMRC's guidance refers to whether the uncertainty could have been resolved by a "competent professional in the field." This is a useful anchor when assessing your own work. Ask: if you had hired the most experienced person you know in this technical area, would they have immediately known how to solve the problem — or would they have needed to experiment too?

If the answer is that even an expert would have needed to try things and accept the possibility of failure, you are in qualifying territory. If the answer is that any competent contractor could have done it in a straightforward way, you are probably not.

Partial qualification — a common situation

Many projects involve a mix of qualifying and non-qualifying work. A software development project might include some genuinely novel algorithm work (qualifying) alongside substantial routine development using established methods (not qualifying). Only the time and cost attributable to the qualifying activity can be claimed.

This partial qualification is extremely common in SME R&D claims and is entirely legitimate — you do not need a project to be entirely novel to claim. You need to identify and ring-fence the parts that genuinely involved technological uncertainty and claim on those parts only.

One practical tip: contemporaneous documentation makes a significant difference. Notes from the time showing what you were trying to solve, what you tried, and what did not work are far more convincing to HMRC than a claim narrative written retrospectively. Even informal records — commit messages, internal emails, meeting notes — count.

How HMRC tests for it

In a compliance check, HMRC will typically ask for a project-by-project description of the technical challenges involved, what was uncertain at the outset, what approaches were tried, and what the outcome was. They may also ask about the qualifications and experience of the staff involved, and whether the technical challenges were documented at the time.

The best defence is a clear, specific narrative — not one that uses vague language like "we developed innovative solutions" but one that describes the specific technical problem, why existing approaches were insufficient, what was tried, and what was learned. A specialist R&D adviser writes claims in this way as a matter of course; a generalist accountant often does not.

Not sure if your work qualifies?

Our free grader assesses your eligibility based on your specific business and activities — 7 questions, instant result.

Check eligibility free →