What HMRC really means by “technological uncertainty”
Are you describing genuine technological uncertainty clearly enough in your R&D claims?
One of the most common reasons R&D claims fail is misunderstanding what HMRC means by technological uncertainty.
It is not about whether a project felt difficult.
It is about whether the solution was not readily deducible at the outset.
For R&D tax relief, an uncertainty exists where competent professionals cannot readily determine how or whether a desired outcome can be achieved using existing scientific or technological knowledge.
That distinction matters.
What does not create technological uncertainty
- the work is new to your business,
- the project is complex or time-pressured,
- the solution hasn’t been tried by your team before.
HMRC looks beyond internal capability and focuses on the wider knowledge base available at the time.
When technological uncertainty arises
- existing methods fail when applied in practice
- known solutions don’t scale, integrate, or perform as expected
- trade-offs between performance, stability, compliance or safety cannot be resolved using established techniques
- unpredictable behaviour emerges during implementation
Resolving the uncertainty
- evaluate multiple approaches,
- test hypotheses,
- adapt or abandon methods,
- and learn through experimentation.
That process of resolving uncertainty, not the outcome, is what qualifies. Importantly, success is not required.
Projects that are abandoned, partially completed, or fail outright can still qualify if the uncertainty was genuine and the work was systematic.
Where claims struggle is when uncertainty is described in broad or commercial terms, rather than technological terms.
Statements like “the client wanted something unique” or “there was no product on the market” do not, on their own, establish R&D.
What HMRC expects you to explain
- what was known at the outset,
- what specifically could not be worked out,
- and why professional judgement alone was insufficient without further technical work.
Pause for thought
If your technical team had to work things out through testing and iteration, rather than applying a known solution, that’s often where qualifying R&D starts.
