What is scientific or technological uncertainty?

Q: What is scientific or technological uncertainty?

Scientific or technological uncertainty exists when knowledge of whether something is scientifically possible or technologically feasible, or of how to achieve it in practice, is not readily available or deducible by a competent professional working in the field. Uncertainty that such a professional could readily resolve is not scientific or technological uncertainty, however real it felt to the people doing the work.

The two kinds of uncertainty

The definition covers two distinct situations, and it helps to keep them apart when you describe a project.

Whether it can be done at all. Nobody knows whether the outcome is achievable—whether a material can hold a property at a given temperature, whether an algorithm can produce a result within a time bound, or whether a process can meet a tolerance. This is the cleaner case and easier to evidence, because the project either resolves it or it doesn’t.

How to do it in practice. The outcome is known to be theoretically possible, but no one can say how to achieve it in a working system. This includes system uncertainty: individual components may be well understood, but combining them in a particular way produces behaviour that cannot be predicted from what is known about the parts. System uncertainty is a legitimate ground, and it is also the ground most often asserted without support, so it needs the most careful description.

What “readily deducible” means

The word doing the work in the definition is “readily”. Something is readily deducible if a competent professional could work it out from existing knowledge without significant effort. HMRC’s compliance guidance draws the line at information obtainable by routine means — standard reference material, published literature, vendor documentation, the ordinary sources of the field.

That is a lower bar than people expect. Uncertainty is not established by showing that the answer took work to find. It is established by showing that the answer could not have been found by looking it up or reasoning it through in the ordinary way. Plenty of demanding engineering fails this test, and there is no shame in that — it is simply not what the relief is for.

What uncertainty is not

Commercial uncertainty. Whether customers will buy it, whether the price point works, whether a competitor will get there first, whether the funding will hold. None of these is scientific or technological uncertainty, and none of them becomes so by being written in technical language.

Uncertainty about time and cost. Not knowing how long something will take, or how many people it will need, is project uncertainty. It only counts when the doubt is that nobody knows whether the technical approach works.

Your own inexperience. If the knowledge exists in the field and your team did not have it, the uncertainty was yours, not the field’s. Learning something that a competent professional already knows is training, not R&D.

Difficulty. Hard work is not uncertainty. A project can be long, expensive, technically demanding and entirely predictable to someone who knows the field.

Regulatory and compliance risk. Not knowing whether an approval will be granted is not technological uncertainty, even where the approval is technical in nature. The exception is where meeting a standard itself requires an advance that no one knows how to make.

When the uncertainty starts and stops

These boundaries decide how much of a project’s cost is in the claim.

It starts when there is a project — a method or plan — aimed at resolving an identified uncertainty. HMRC’s guidance is direct: there cannot be a qualifying project before a plan or method existed to resolve identified uncertainties. Work that produced a useful discovery outside such a project is not claimable, although work to develop the discovery afterwards may be.

It stops when the uncertainty is resolved, or when work to resolve it ceases. That is a technological event, not a commercial one. It is usually the point at which the approach is shown to work reliably — not the point at which the product ships, passes certification or reaches a customer. Work continuing after that point, including fine-tuning and optimisation that does not materially affect the underlying technology, is outside the claim even where it uses the same people, the same rig and the same budget line.

Position for accounting periods beginning before 1 April 2023

The earlier guidelines, issued in 2004 and updated in 2010, define scientific or technological uncertainty in the same terms, and the tribunal decisions on uncertainty apply to both. There is no boundary issue here beyond the general one on the scope of mathematics.

Worked example

Illustrative. A company developing a continuous-flow chemical process to replace a batch process.

Question asked during the project	Uncertainty?
Will the market accept a product made this way?	No — commercial
Can the reaction be run continuously at all, given the exotherm, when published work covers only batch?	Yes — feasibility
Which supplier’s pumps should we buy?	No — procurement
How do we hold residence time distribution within tolerance at scale, where the published models break down?	Yes — how to achieve it in practice
Will the regulator accept the process?	No — regulatory
Once the rig runs stably, how do we cut the changeover time from 40 minutes to 30?	No — optimisation after the uncertainty was resolved

The R&D runs from the point the team set out to establish continuous feasibility to the point the rig held residence time distribution repeatably. On this project that was eleven months of an eighteen-month programme. The last four months, spent on changeover time and on regulatory documentation, are outside — and including them would put the whole claim in play rather than just those four months.

Where claims go wrong

Uncertainties written after the fact. The single most damaging pattern. Where the uncertainty first appears in a document produced for the claim, and nothing in the contemporaneous record shows anyone recognised it at the time, tribunals have not accepted it. Uncertainty is a state of knowledge at a moment, and you cannot reconstruct it later from the fact that the work was hard.
Requirements dressed as uncertainties. “The system needed to handle 10,000 concurrent users” is a specification. It becomes an uncertainty only if nobody in the field could say how to achieve it. A list of requirements with the word “uncertainty” at the top of it is transparent, and HMRC reads a lot of them.
No evidence from a competent professional. A tribunal has dismissed a claim on the basis that there was no evidence from a competent professional as to whether there would in fact have been any uncertainties. The company’s own belief that the work was uncertain is not the test.
Claiming to the end of the project. Carrying the claim through certification, pilot production and launch is common, and it is wrong. It also converts a defensible claim into a disputed one, because the boundary error invites HMRC to test everything else.
One uncertainty stretched across many projects. Where a single technical difficulty is used to justify a claim spanning several unrelated workstreams, the claim usually collapses at the first request for a project-by-project breakdown.