Technological vs Commercial Uncertainty: What Qualifies?
Quick Answer
Technological uncertainty exists where a competent professional cannot readily deduce whether something is feasible, or how to achieve it. Commercial uncertainty, such as whether a product will sell, is not R&D, and most projects contain both inside the same problem.
One of the most common misconceptions about R&D tax relief is that a technically demanding project must involve qualifying technological uncertainty. It does not follow, and the gap between the two is where most claims are won or lost.
Most explanations of this subject present two lists. Technological uncertainty on one side, commercial uncertainty on the other. Sort your activities into the correct column and you have your claim.
That is not how projects behave. In the work we review, the two are rarely separate activities sitting side by side. They are different uncertainties inside the same hurdle, described in one sentence by the same person. “We could not get the cycle time down” is one problem to the business and at least two questions to the legislation, and the job is not sorting. It is decomposition.
This blog sets out what the statutory test asks, how to pull the two apart when they are tangled, the case where a cost problem is genuinely a technological one, and why two outwardly similar projects can reach different answers.
Who this applies to
Engineering, manufacturing and software businesses running development programmes where technical and commercial risk are genuinely entangled. It is most useful if you have a project that was hard, expensive and late, and you are not sure whether that makes it R&D.
It also applies if you have been told your work does not qualify because it was “just engineering”, or that it does qualify because it was “really difficult”. Neither statement engages with the test.
What the legislation actually tests
The definition sits in the DSIT Guidelines on the meaning of R&D for tax purposes, issued on 7 March 2023 to replace the 2004 guidelines, and reproduced in HMRC’s manual at CIRD81910.
Paragraph 13 is the operative passage. 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. It expressly includes system uncertainty.
Paragraph 14 closes the back door. Uncertainties that can readily be resolved by a competent professional working in the field are not scientific or technological uncertainties, and improvements, optimisations and fine-tuning which do not materially affect the underlying science or technology do not constitute work to resolve them.
Paragraph 28 then lists activities that do not directly contribute to resolving uncertainty, and first on that list is the range of commercial and financial steps necessary for innovation and for the successful development and marketing of a new or appreciably improved process, material, device, product or service.
The starting point, then, is not how difficult the project was. It is what was already known or readily deducible in the relevant scientific or technological field. Only once that baseline is established can you determine whether the project sought a qualifying advance, and which activities fall within the scope of R&D. Both halves matter: the project and its boundaries are part of the test, not just the uncertainty.
“Readily deducible” does not mean “straightforward”
This is the most useful line in HMRC’s own guidance and it is routinely skipped. In Part 4 of its Guidelines for Compliance, HMRC explains that readily deducible means able to be worked out from existing knowledge without significant effort, and then warns directly: be careful not to treat “readily deducible” as meaning “straightforward”.
Read those together and the failure in both directions becomes obvious. A problem can be extremely laborious and still readily deducible, because the method was known and the work was execution. A problem can look modest and not be readily deducible, because existing knowledge did not reach the case. Effort is not the variable. Knowledge is.
One corollary is worth stating, because it is where confident claims often go wrong. The absence of a published solution does not by itself establish technological uncertainty. A competent professional may well be able to deduce a workable answer from existing knowledge even where no specific method has been documented for your exact case. The question is not “is it written down somewhere”. It is “could a competent professional in this field have worked it out from what is available, without significant effort”. Those are different tests and only the second one counts.
Two uncertainties inside one hurdle
When a project runs into trouble, the business experiences one obstruction. Underneath it there are usually at least two distinct questions.
- Will it work? Whether the thing is feasible at all, or achievable in practice, given what the field knows. This is the technological question.
- Will it pay? Whether it can be delivered inside the budget, to the date, priced acceptably, accepted by the customer, or approved by the board. These are commercial questions, however technical the vocabulary used to describe them.
A team that cannot hit a tolerance may be facing a genuine gap in what the field knows, or may be facing a machine that is not accurate enough and a capital request that was refused. Both get described as “we could not hold the tolerance”. One may be R&D. The other is a procurement problem.
This is why sorting activities into columns does not work. The two are often not separate activities at all. They are two readings of one activity, and establishing which reading is correct requires knowing what the field already knew.
The case that breaks the simple split
If the paragraphs above were the whole story, any project driven by cost would be out of scope. That is not right, and the error is common enough to be worth isolating.
Paragraph 13 goes on to say that scientific or technological uncertainty will often arise from turning something that has already been established as scientifically feasible into a cost-effective, reliable and repeatable process, material, device, product or service.
That sentence matters enormously to manufacturers. A company may know perfectly well how to produce a component in the laboratory or as a one-off, and have no idea how to produce it economically, consistently and at volume with the knowledge available. The commercial pressure is what makes the problem worth solving. The technological uncertainty is whether it can be solved at all with current knowledge.
So the distinction is not between cost problems and technical problems. It is between a commercial constraint on its own, and a commercial constraint that can only be met by resolving a genuine technological uncertainty. “We need this cheaper” is not R&D. “No known process route produces this at that cost, reliability and volume, and we had to find one” may well be.
Same hurdle, two readings
| As described by the business | Commercial reading | Technological reading | What decides it |
|---|---|---|---|
| “We could not get the cycle time down” | Not enough machine capacity, or capital spend refused | No known process route achieves that cycle time at that tolerance | Whether a competent professional could deduce the route from existing knowledge |
| “The integration kept failing” | Supplier late, specification kept moving | System behaviour at that throughput could not be predicted from what was known | Whether the interaction had to be discovered or could be deduced |
| “We could not make it at a viable cost” | Margin pressure, supplier pricing, volume assumptions | Turning a feasible method into a cost-effective, repeatable process was not deducible | Paragraph 13: this one can qualify, and often does in manufacturing |
| “It took six months longer than planned” | Resourcing, sequencing, scope creep | Repeated approaches failed because the answer was not known | Whether the iteration was systematic investigation or rework |
| “Nobody had built one like this before” | New to this company, or new as a commercial proposition | New relative to overall knowledge or capability in the field | Paragraph 22: routine adaptation does not advance the field even when new to the company |
Two projects that look alike from the outside
Here is why a project file alone will not answer the question.
Take two firms running outwardly similar programmes. Three engineers each. Fourteen weeks. The same shape of Gantt chart with two slipped milestones. Two failed prototypes apiece. Similar spend. Both teams frustrated, both projects late, both eventually delivered.
Nothing observable separates them. Not the plan, not the hours, not the failures, not the outcome. Put the two folders side by side and you could not tell which one qualifies.
What separates them sits outside both companies: whether a competent professional working in that field could have deduced the answer from existing knowledge without significant effort. One team was resolving a genuine gap. The other was rediscovering something deducible, or working around a constraint that was about money and time rather than knowledge.
The practical consequence is worth stating plainly. You cannot establish qualification by looking harder at your own records. The records tell you what you did. The test asks what the field knew. That is why the competent professional matters so much, and why we spend the first part of any review on the baseline rather than on the project. Our blog on identifying your competent professional covers who is qualified to answer that question.
Where system uncertainty sits
Paragraph 13 expressly includes system uncertainty, which matters for integration-heavy work where every component is well understood on its own and the difficulty lies in how they behave together.
It is not a loophole. HMRC’s position in Part 4 is that system uncertainty can qualify, but that assembling components to an established pattern, or following routine assembly methods, does not. The question is the same as everywhere else: was the interaction something a competent professional could have predicted from existing knowledge, or did it have to be discovered?
Worked example: outwardly similar, different answers
Two manufacturers each develop a sealed housing for a high-vibration application. Assume an accounting period beginning after 1 April 2024, so the merged scheme applies, and Corporation Tax at the 25% main rate. Assume also that each has identified £95,000 of staff and consumable costs attributable to the activities in question, and that in Firm B’s case all of that expenditure has been tested and found to relate to qualifying activity. That second assumption is doing real work, and is addressed below.
Firm A. The sealing method is established and documented, and a competent professional could specify it for this application without significant effort. The uncertainty is whether the tooling budget will stretch to the required volumes and whether the customer will accept the resulting unit price. Two prototypes fail on cost grounds rather than performance.
Firm B. The required combination of vibration profile and temperature range falls outside the operating envelope of any documented method, and the firm’s competent professional concludes that performance in that regime could not be deduced from existing knowledge without testing. Three approaches are worked through before one holds. Two prototypes fail on performance.
| Firm A | Firm B | |
|---|---|---|
| Programme length, team, failed prototypes | 14 weeks, 3 engineers, 2 | 14 weeks, 3 engineers, 2 |
| Nature of the uncertainty | Cost, volume and customer acceptance | Whether performance in that regime was achievable at all |
| Readily deducible by a competent professional | Yes | No |
| Expenditure attributable to qualifying activity | Nil | £95,000 on these assumptions |
| Gross expenditure credit at 20% | Nil | £19,000 |
| Approximate net benefit after Corporation Tax | Nil | Around £14,250 |
A note on that fourth row, because it is the step most often got wrong. A qualifying project does not make every pound spent on it qualifying expenditure. The boundary runs around the activities that directly contribute to resolving the uncertainty, plus the qualifying indirect activities listed at paragraph 31 of the Guidelines. Work that continues after the uncertainty is resolved, production, marketing and the commercial wrapper around the project all sit outside it, and costs have to be apportioned accordingly. In practice a programme of this kind rarely yields a clean 100%.
The figures are illustrative and rest on the assumptions stated. The point is the first row read against the last. On everything observable the two programmes are alike, and the difference in outcome is roughly £14,250 on a single project. The variable is not visible in either project file.
Five questions to ask before treating a project as qualifying
These are scoping questions rather than eligibility rules, and they work in the order given. If you cannot answer the second, the rest will not hold.
- What scientific or technological advance were we attempting to achieve? Stated as an advance in the field, not as a benefit to the business.
- What was already publicly available or readily deducible in that field when we started? This is the baseline, and it is the question most claims never ask.
- What uncertainty prevented a competent professional from readily achieving that advance? Named specifically, not described as general difficulty.
- What work was undertaken specifically to resolve it? Which approaches, in what order, and why each changed.
- When was the uncertainty resolved, and which activities and costs fall inside the boundary? Work after that point, and the commercial wrapper around it, sits outside.
A project that answers all five has a claim that can be explained. One that cannot answer the second has a cost schedule looking for a justification.
Why this gets decided too late
Because the distinction is invisible in the records, it tends to get made at the wrong moment by the wrong person. A finance team assembling a claim after the year end looks at the cost base, sees a hard project that ran over, and reasonably concludes that something that difficult must have involved uncertainty. Nobody asks what the field already knew, because by then the people who could answer have moved on.
The decomposition is cheap at the start and expensive afterwards. At the start, the engineer can tell you in ten minutes what they considered and why it did not reach the case. Two years later, reconstructing that is slow, less convincing, and sometimes not possible. Our nine-part framework for R&D project records sets out what to capture while it is still easy.
How Lexmore approaches this
We start with the baseline rather than the project. Before looking at a plan or a cost schedule, we establish what was publicly available or readily deducible in the relevant field when the work began, with the competent professional for that field. Only then do we look at what the company did, because the second question has no answer without the first.
Where a hurdle contains both kinds of uncertainty, which is the normal case, we draw the boundary around the part that is technological and apportion the costs to match. Claims under the merged scheme are tested on that boundary more than on anything else.
If you are unsure whether your development activities involve qualifying technological uncertainty, we can help establish where the boundary sits, which activities fall inside it, and what evidence supports them. Contact Lexmore to discuss your projects.
Lexmore’s View
Not every technically demanding project qualifies for R&D tax relief. Commercial uncertainty, operational complexity and technological uncertainty frequently overlap within the same programme, and the legislation draws distinctions between them that are easy to miss from the inside. The question that feels natural to the people who lived through a project is how hard it was. The question the test asks is what was known.
Our role is to establish precisely where those boundaries sit: recognising a genuine technological advance where there is one, identifying the activities that contributed to resolving the uncertainty, and excluding expenditure that falls outside the qualifying criteria. A robust claim is certainly not the largest claim. It is the one that reflects the qualifying work actually undertaken and holds up when it is examined. What was known. What was not. Where the line falls.
References
Related Services
Lexmore advisory areas covered in this article.
Check Your Eligibility
Not sure if you qualify? Take our quick eligibility assessment to find out.
Frequently Asked Questions
Is a tight deadline a technological uncertainty?
No. A deadline is a commercial constraint. Paragraph 28 of the DSIT Guidelines puts the range of commercial and financial steps necessary for development and marketing outside the definition. A project can be late, over budget and genuinely painful without containing any technological uncertainty. The question is whether the knowledge existed, not whether there was enough time to apply it.
We needed to make it cheaper. Can a cost problem ever qualify?
Yes, in the right circumstances, and this is widely misunderstood. Paragraph 13 states that uncertainty will often arise from turning something already established as scientifically feasible into a cost-effective, reliable and repeatable process, material, device, product or service. So a manufacturer that knows how to make something but cannot make it economically at volume with available knowledge may be facing a genuine technological uncertainty. The distinction is between a commercial constraint on its own and a commercial constraint that can only be met by resolving a technological uncertainty.
There was no published method for our situation. Does that prove uncertainty?
No. The absence of documentation is not the test. A competent professional may be able to deduce a workable solution from existing knowledge even where no method has been published for your exact case. The test is whether the answer was readily available or readily deducible without significant effort, which is a higher bar than “we could not find it written down”.
Does uncertainty have to be novel to the whole field, or just to us?
To the field. Paragraph 22 is explicit that the routine analysis, copying or adaptation of an existing process, material, device, product or service does not advance overall knowledge or capability, even though it may be completely new to the company or the company’s trade.
If the project qualifies, can we claim everything we spent on it?
No. A qualifying project does not make all of its expenditure qualifying. The boundary runs around the activities that directly contribute to resolving the uncertainty, plus the qualifying indirect activities listed at paragraph 31. Work continuing after the uncertainty is resolved, production, marketing and the commercial wrapper sit outside, and costs are apportioned accordingly.
Does the uncertainty need to have been written down at the time?
It does not have to have been, and HMRC accepts that a qualifying project can be identified after the work has finished. But a contemporaneous record of what was considered, why it did not reach the case and what was tried is considerably more persuasive than a reconstruction, and reconstruction gets harder as people leave.