A robotics prototype qualifies for R&D tax relief when it is built to resolve technological uncertainty: when, at the point of design, a competent engineer could not say whether the system would meet its targets, or how to make it do so. A prototype built to demonstrate or sell technology that already works does not qualify, however impressive the machine. In robotics, the qualifying uncertainty usually lives in three places: system integration, control, and the gap between the lab and the operating environment.
This article takes each in turn, then covers the evidence that makes iterative prototype work stand up to HMRC review. The general definition sits in what counts as qualifying R&D.
Is building a prototype automatically R&D?
No. The question is what the prototype is for. A prototype built as an experiment, to answer a technical question the team could not answer on paper, sits squarely inside a qualifying project. A prototype built as a demonstrator, to show investors or customers a design whose technical questions are already settled, sits outside it.
The same discipline draws the project boundary in time. The R&D ends when the uncertainty is resolved or abandoned, so the third prototype that finally holds its accuracy across the operating envelope may be the last qualifying build. The pre-production units made afterwards for marketing, customer pilots of proven capability, and cosmetic and enclosure work belong to the commercial project around the R&D, not the R&D itself. Drawing that line precisely, rather than claiming every unit ever built, is what keeps a robotics claim defensible.
Why does integration count as uncertainty?
Because a robot is a system, and system behaviour is not deducible from component datasheets. The motors, sensors, grippers, compute modules and vision stacks in a typical build are individually well documented. What the field often cannot predict is whether they will work together as a whole within the machine’s constraints: timing interactions between perception and actuation, vibration and thermal behaviour under load, electromagnetic interference between subsystems, and weight and power budgets that every component fights over.
This is recognised in the DSIT-based definition: combining components that are each well understood can still involve genuine technological uncertainty where the field cannot predict whether or how they will work together. The flip side holds too. Routine integration, assembling a cell from a vendor’s catalogue by the vendor’s instructions, does not qualify, however skilled the work. The honest test is whether a competent robotics engineer could have specified the working system in advance. If the answer was no, and the prototypes existed to find out why, the integration work is the R&D.
Where is the uncertainty in control systems?
In making the machine behave correctly across its whole operating envelope, not just in the demo. Concept-level examples of control problems that regularly carry genuine uncertainty:
- keeping a controller stable across the full range of loads, speeds and configurations the machine must handle, where established tuning methods cannot be shown in advance to cover the envelope
- fusing noisy, conflicting sensor inputs into state estimates reliable enough to act on in real time
- motion planning around dynamic obstacles within hard latency limits on constrained onboard compute
- characterising the behaviour of learned components inside a safety-relevant control loop, where the field has no settled method for bounding what the model will do
That last category overlaps with machine learning development, and the dividing line for ML work has its own article: when machine learning development qualifies as R&D.
What about the gap between the lab and the real world?
The lab-to-field gap is often where the hardest, and most clearly qualifying, uncertainty sits. A system that performs in simulation and on the bench meets conditions in deployment that neither fully represents: changing light, dust and weather, unstructured and cluttered spaces, surfaces and objects that vary in ways the training environment never captured, and people behaving unpredictably around the machine.
Where the field cannot predict whether a system will hold its performance under those conditions, the structured field trials run to find out, and the redesign work they force, are part of resolving the uncertainty. The boundary discipline still applies: a field trial designed to answer an open technical question qualifies; routine site acceptance testing of a proven system does not.
What evidence do the iterations need?
Records that show the iteration was systematic rather than trial and error: what question each build was asking, what the tests showed, and why the design changed in response. In practice that means design revisions with reasons, test logs and failure reports, and short notes on abandoned approaches. Failed prototypes are strong evidence, not something to write out of the story: an uncertainty that took three builds to resolve was self-evidently real. Hardware teams usually generate this material anyway; the discipline is keeping it, and keeping it dated, because a claim assembled years later from memory reads exactly that way to an inspector.
The cost side rewards the same records. Staff time apportioned to the qualifying work, materials consumed in building and testing prototypes, and software used in the R&D can all enter the claim; the categories and their rules are set out in which costs qualify for R&D tax relief.
What is a robotics claim worth?
For a pre-revenue robotics SME still in prototype iterations, often the maximum the system offers. A loss-making SME whose relevant R&D expenditure is at least 30% of its total relevant expenditure claims under ERIS, worth up to 26.97p per £1: on the standard example, £100,000 x 186% x 14.5% = £26,970 as a payable cash credit. Companies outside ERIS claim the merged scheme’s 20% credit, worth £15,000 net per £100,000 at the 25% corporation tax rate and £16,200 for loss-makers.
HMRC checks roughly one in six R&D claims, and hardware claims are examined on exactly the points above: whether the prototypes resolved genuine uncertainty and whether the boundary between R&D and productisation was drawn honestly. The iteration evidence described here is what a claim leans on if HMRC opens an enquiry.
Where to go next
The wider sector picture, including how AI and robotics claims fit together, is on our AI and robotics sector page. If you are mid-programme and unsure which builds and trials belong in the claim, talk it through with a chartered adviser: boundary questions like these are quicker to settle before year end than after it.
Written by Matthew Jones ACA CTA. Last reviewed July 2026.
Sources
- DSIT Guidelines: meaning of R&D for tax purposes — the tests of technological advance, scientific or technological uncertainty and the competent professional.
- Merged scheme & ERIS guidance — the merged-scheme and ERIS rates under which qualifying prototyping work is claimed.
This article describes the rules as they stood at the review date above. The rules change: for the current position, start with our guides or talk to us.
