Scientific or technological uncertainty exists when knowledge of whether something is scientifically possible or technologically feasible, or how to achieve it in practice, is not readily available or deducible by a competent professional working in the field. That definition, from the Guidelines that set out the meaning of R&D for tax purposes, sits at the centre of the relief: everything else in a claim, from the cost apportionments to the project narratives, is downstream of it.
What is not a technological uncertainty
The Guidelines are explicit that uncertainties which can readily be resolved by a competent professional working in the field are not scientific or technological uncertainties. That is the line most rejected claims fall the wrong side of. Work can be long, expensive, frustrating and commercially vital and still fail the test, because none of those things says anything about whether the answer was available. Where a competent professional could have found it in published knowledge, in standard practice, or by applying established technique with care, the problem was execution rather than uncertainty.
Several things get mistaken for it. Commercial risk, whether the market will buy the thing or whether it can be built to a viable price, is not technological uncertainty. Nor is market uncertainty. Nor is routine difficulty, the ordinary hard work of delivering something to a deadline with the people available. And the Guidelines exclude one more category in terms: improvements, optimisations and fine-tuning that do not materially affect the underlying science or technology. The question is never how hard the work felt; it is whether the knowledge existed.
Because the test is calibrated to a person rather than a project, who counts as a competent professional is not a side issue. The same problem can be a genuine uncertainty for one field’s professionals and routine for another’s, so the claim has to be written from the right vantage point.
Complexity and combination count too
Uncertainty does not have to attach to a single component; the definition itself says it includes system uncertainty. The Guidelines describe system uncertainty as scientific or technological uncertainty that results from the complexity of a system rather than uncertainty about how its individual components behave. They go further: work on combining standard technologies, devices and/or processes can involve scientific or technological uncertainty even if the principles for their integration are well known — there will be uncertainty if a competent professional working in the field cannot readily deduce how the separate components or sub-systems should be combined to have the intended function.
The Guidelines state the caveat alongside the definition: assembling components (or software sub-programs) to an established pattern, or following routine methods for doing so, involves little or no scientific or technological uncertainty. That is the line to hold in integration-heavy and software-led claims. “Every part of it already existed” does not end the analysis — but nor does “we combined many parts”. If a competent professional in the field could not readily deduce whether the parts would hold together at the scale, latency, tolerance or reliability the project required, the Guidelines say there will be scientific or technological uncertainty. The converse is stated more softly — assembly to an established pattern involves “little or no” uncertainty — which leaves room for the awkward case where a mostly routine integration throws up a genuine one. The burden simply shifts, and it shifts hard.
Identifying them, and showing they were genuine
Uncertainties are identified per project rather than per company, and for each project described on the Additional Information Form — all of them where you have up to three; at least three covering half the qualifying expenditure, capped at ten, where you have more — they have to be explained, including why the answer was not readily available or deducible. That last requirement is where thin claims give themselves away. Asserting that a project was uncertain takes a sentence. Saying what a competent professional would already have known, and pinpointing where that knowledge ran out, takes the professional.
Failed attempts are often the clearest evidence the uncertainty was genuine, which is why we ask about the approaches that were abandoned as closely as the one that worked. A dead end demonstrates the answer was not deducible in a way no narrative can. Our page on claiming for a failed project covers how that works in practice, and our guide to what counts as qualifying R&D sets uncertainty alongside the advance test it exists to serve.
If you are unsure whether your project’s problems clear this bar, that is the question to settle before a claim is prepared rather than after. We will give you a straight answer either way.
Written by Matthew Jones ACA CTA. Last reviewed July 2026.
Sources
- Guidelines on the meaning of R&D for tax purposes — paragraphs 13 and 14 on uncertainty and what can readily be resolved, and paragraphs 29 and 30 on system uncertainty and combining standard technologies.
- Help to see if your work qualifies as R&D for tax purposes (GfC3) — HMRC’s guidelines for compliance on identifying qualifying activities and the role of the competent professional.
This page describes the rules as they stood at the review date above, as general information rather than advice on your circumstances. For how that distinction works, see our terms; for an answer on your own facts, talk to us.