The HMRC Technological Uncertainty Test — Explained
Software R&D — Qualifying vs Non-Qualifying: Real Examples
| Activity | Qualifies? | Why |
|---|---|---|
| Building a new web app with React and Node.js following established patterns | ❌ No | Using known frameworks and established patterns. No technological uncertainty. |
| Developing a custom machine learning algorithm to detect financial fraud with novel approach | ✅ Yes | Novel algorithm — competent professional cannot readily know if approach will work. |
| Integrating Stripe payment processing using their documented API | ❌ No | Standard integration following documented procedures. No uncertainty. |
| Building a new approach to real-time multi-player state synchronisation not documented elsewhere | ✅ Yes | Novel technical problem without established solution. Experimental work required. |
| Implementing OAuth2 authentication following the RFC specification | ❌ No | Standard protocol implementation. Documented, known approach. |
| Developing a new approach to privacy-preserving machine learning compliant with GDPR Article 22 | ✅ Yes | Novel combination of ML technique and regulatory constraint not previously solved in documented way. |
| Rewriting a legacy PHP application in Python | ❌ No (usually) | Usually: known techniques, no uncertainty. Exception: if the migration involves solving novel technical problems. |
| Building an NHS FHIR R4 integration using documented NHS Digital APIs | ❌ No (usually) | Following documented standards. Exception: novel approaches to mapping clinical data models. |
| Developing a novel approach to reducing p50/p99 latency in a distributed system by 80% | ✅ Yes | If novel techniques beyond industry standard are used to achieve unusual performance targets. |
| Training a custom LLM fine-tuned on proprietary domain data with novel training methodology | ✅ Yes | Novel training approach, uncertain outcomes. Well-documented experimentation required. |
How ClickMasters Documents R&D Activities
Sprint-level technical narrative: at the end of each sprint, we document the specific technological uncertainties we addressed, the approaches we tried (including those that failed), and how uncertainties were resolved.
Architecture Decision Records (ADRs): formal documentation of every significant technical decision — including the alternatives considered and why they were rejected. This demonstrates systematic investigation.
Developer time tracking: granular records of time spent on qualifying R&D activities vs standard implementation work.
Technical narrative summary: at project completion, a summary document formatted to support your R&D tax claim — written by a technical team member, not the finance team.
ClickMasters includes R&D documentation as a standard deliverable on all qualifying projects. This is unique in the UK market — no other agency we know of does this as standard practice. Our approach:
Frequently Asked Questions — Qualifying R&D for Software UK
Related Guides & Services
Qualify Your Project for R&D Tax Credits Book a free consultation to assess whether your software project has qualifying R&D activities. ClickMasters documents R&D as standard — giving you the best possible starting point for your claim. → Book Free R&D Consultation: clickmasterssoftwaredevelopmentcompany.co.uk/contact/
👤
AUTHOR
ClickMasters R&D Documentation Team
HMRC R&D qualifying activities specialists — chartered accountant reviewed
This guide reflects ClickMasters' direct experience documenting qualifying R&D activities for HMRC claims across 30+ software projects. Always consult a qualified R&D tax specialist for advice specific to your situation.