A claim stands or falls on the baseline: what the field could already do when the project began, and whether the work went beyond it. The test turns on the technology rather than the market — whether the work sought an advance in computer science or software engineering, through uncertainty a competent professional could not readily resolve. A product being new to the market carries no weight on its own. That distinction, applied honestly, decides most software claims.
This guide covers the baseline and the guidance behind it: where to set it, how to record it, and what HMRC expects to see. For the wider picture — where software work qualifies, where it does not and what the relief is worth — start with our software sector page.
Where do you set the technological baseline?
At the point the project starts, not when the claim is prepared. Software moves fast, and a claim is judged against what the field could do at the time. The baseline is the state of technology across the industry when your project began, and your claim has to show the work went beyond it.
Be specific about what published techniques, frameworks and benchmarks existed in the relevant accounting period, and avoid hindsight: a problem that looks routine two years later may have been genuinely unresolved when you faced it, and the record needs to show that.
What does HMRC’s software guidance actually cover?
HMRC publishes guidance specifically on software projects, prompted by years of inflated claims in the sector. It sets out which software activities can qualify, gives worked sector examples, and hammers the distinction between commercial and technological progress. Every software claimant, and every adviser preparing a software claim, should work from it.
Is commercial innovation enough to qualify?
No. New features, market disruption and customer value are commercial achievements, and they carry no weight in the qualifying R&D test. HMRC’s guidance is explicit that the advance must be in science or technology, not in the product.
Claims written around product innovation rather than the underlying technology are a leading cause of rejection and enquiry. The same field-advance logic governs machine learning work; we cover it in when machine learning development qualifies as R&D.
How do you evidence a baseline you cannot point at?
Software R&D is abstract: there is no prototype on a bench. The people who can locate the qualifying work are your competent professionals, the developers and architects who understand where the real technical difficulty sat. Involve them directly.
Their account needs to answer the questions the Additional Information Form asks: what specific technical hurdles could a competent professional not readily resolve, and how did the project set about resolving them? HMRC cares less about the finished product than about the systematic process of experiment, iteration and failure analysis behind it.
What makes the record hold up in practice?
Five habits, in order of value:
- Start early. Record baselines and uncertainties during development, not months later.
- Use a regulated specialist with genuine software claim experience.
- Put your tech leads in the room. They articulate the uncertainty better than anyone.
- Be specific: algorithms, architectures, data handling. Vague narratives invite HMRC enquiries.
- Structure documentation around baseline, uncertainty and advance so the AIF writes itself.
If you are unsure whether your development work clears the bar, talk it through with a chartered adviser. A short technical conversation usually settles it.
Sources
- CIRD81960: Guidelines applied to software — the advance must lie in the underlying technology, not the product.
- DSIT Guidelines: meaning of R&D for tax purposes — the tests of technological advance, uncertainty and the competent professional.
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.
