To claim R&D tax relief, your project must have delivered an advance in science or technology. Qualifying R&D activities are those that directly contribute to achieving that advance through the resolution of “scientific or technological uncertainty”.
But what does the phrase “scientific or technological uncertainty” actually mean? And how should you go about assessing your projects?
In this accessible guide, we explore the key definitions and resources, and share practical examples of what might and might not qualify.
What does ‘scientific or technological uncertainty’ mean?
The meaning of ‘scientific or technological uncertainty’ is covered in the DSIT Guidelines on R&D tax relief. In summary, it exists when it’s unclear how to achieve a desired outcome using existing technologies or methods.
The definition, however, contains detail and nuance. It is set out in four key paragraphs. Two under the heading “scientific or technological uncertainty” (13 and 14) and two under “system uncertainty” (29 and 30). Paragraph 13 sets out what scientific or technological uncertainty includes, while 14 defines what’s excluded (see below).
What it is
According to paragraph 13:
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. This includes system uncertainty. Scientific or technological uncertainty will often arise from turning something that has already been established as scientifically feasible into a cost-effective, reliable and reproducible process, material, device, product or service.
When considering your project in the context of paragraph 13, ask yourself which category it falls into. Is the project seeking to establish that something is scientifically possible or technologically feasible, or attempting to achieve an already possible/feasible concept in a new, practical context? This latter scenario is very common. If you have a project which falls into that category, be clear about what the associated challenges were and ensure that they’re clearly documented as part of your claim.
What it isn’t
Paragraph 14 of the guidelines is key to understating what doesn’t qualify as scientific or technological uncertainty. It states that:
Uncertainties that can readily be resolved by a competent professional working in the field are not scientific or technological uncertainties. Similarly, improvements, optimisations and fine-tuning which do not materially affect the underlying science or technology do not constitute work to resolve scientific or technological uncertainty.
In other words, projects that wouldn’t qualify are those based on challenges and complexities that a competent professional would expect on a project of this nature. To qualify, they need to be genuine and non-trivial.
Examples of projects that would not represent technological uncertainty include:
- Routine software development using well-established methods and technologies.
- Customising or configuring existing software or hardware solutions to meet specific client requirements without developing new technologies or knowledge. (This is a technology selection exercise.)
- Incremental improvements or trivial changes.
- Bug fixing and maintenance.
- Lack of in-house capability, ie this is not technologically uncertain in the wider field.
- Aesthetic or cosmetic changes such as interface redesign without introducing new technological processes. This can undoubtedly be difficult, but often not fundamentally technologically uncertain.
- Market research, business strategy or user experience design.
Key point
If the challenges encountered on a project can be easily resolved by an expert in the field (either from their own experience, information within the public domain or existing tools) then it is unlikely to represent technological uncertainty. Key indicators that uncertainties existed (and that the solution was genuinely non-readily deducible) would be extended periods of prototyping, multiple iterations in response to unforeseen issues and notable failures or wrong-turns.
System uncertainty
Paragraphs 29 and 30 of the DSIT Guidelines offer further insights on scientific and technological uncertainty in the context of system uncertainty.
Paragraph 29 describes “system uncertainty” as “scientific or technological uncertainty that results from the complexity of a system rather than uncertainty about how its individual components behave.” It provides an example of electronic devices, whereby the characteristics of individual components or chips are fixed, but uncertainty still exists about the best way to combine those components to achieve an overall effect. However, assembling a number of components to an established pattern, or following routine methods for doing so, involves little or no scientific or technological uncertainty.
Paragraph 30 goes further:
work on combining standard technologies, devices, and/or processes can involve scientific or technological uncertainty even if the principles for their integration are well known. There will be scientific or technological uncertainty if a competent professional working in the field cannot readily deduce how the separate components or sub-systems should be combined to have the intended function.
Key point
System uncertainty refers to the unpredictability that arises when trying to combine different parts or technologies to work together as a whole. Even if each part is well understood on its own, figuring out how to put them together effectively can be complex, unclear and require novel solutions.
What this looks like in reality
In practical terms, there are several things that you and your competent professional can do to demonstrate that you meet the defined criteria. You must present:
- the R&D process followed
- the time taken to achieve it
- any failed attempts you have made in the process.
This helps to demonstrate to HMRC that the solution was “non-readily deducible”.
Also worth keeping in mind is that the scale of the improvement identified by the competent professional needs to have been “genuine and non-trivial”. This should be evidenced in the advance, but optimisations and fine-tuning typically take place after the advance has been achieved and the uncertainties resolved, so would not represent qualifying R&D activities.
To support an R&D claim, HMRC will be looking for material advances in the underlying technologies to provide additional evidence and for you to demonstrate that the solution could not have been readily deducible. This could, for example, be in software, frameworks, libraries or infrastructure components that have been non-trivially extended or possibly combined in unusual ways.
Insights into HMRC’s current approach to enquiries
The compliance landscape has evolved in recent years and HMRC now conducts far more enquiries into R&D claims than five years’ ago. Many of these enquiries will be opened at random, so it is important to ensure that your claim is robust and project descriptions accurate.
During an enquiry, a HMRC caseworker will likely assess whether the solution for which you’re claiming relief would have been readily deducible to a competent professional. Therefore, careful consideration needs to be given to the research you’ve conducted and the technological landscape at the time. Context is key, especially in software, where technology moves so fast that capabilities that are well established now might have been less mature or well understood during the claim period (which may only be a couple of years’ ago).
Example of scientific or technological uncertainty
Example: Development of an AI-powered predictive maintenance framework for industrial machinery
Scope: Developing a system to predict equipment failures within industrial machinery ahead of time to minimise downtime and reduce overall maintenance costs.
Uncertainties in a project like this would be the following:
The system relies heavily on historical and real-time data from various sensors embedded in machinery. This data is exposed via low level and poorly documented communication protocols. There is uncertainty about the quality, consistency, and completeness of this data, which is crucial for training accurate predictive models, and this cannot be readily deduced from information available within the public domain. As such, the team must develop their own methods to clean, pre-process and augment the data.
Developing machine learning models that can accurately predict failures across different types of machinery and operating conditions is likely to present significant technological uncertainty. The uncertainty lies in the ability to create models that generalise well and provide reliable predictions in diverse environments, which would require novel approaches in feature engineering and model architecture.
The predictive maintenance system must integrate seamlessly with existing enterprise resource planning (ERP) systems and other operational technologies. There is uncertainty about the interoperability and compatibility of the AI system with these legacy or proprietary third-party systems, which may require atypical solutions for data exchange and system communication which could not have been readily deduced at the project outset.
The system needs to process large volumes of data in real-time to provide timely predictions. There is uncertainty in achieving the necessary computational efficiency and scalability, especially as the number of monitored machines increases. This might involve exploring emerging technologies in distributed computing and real-time data processing or combining techniques and approaches in previously untested ways.
Ensuring that the AI system complies with industry regulations and maintains data security and privacy is another area of technological uncertainty. The team must develop new protocols and security measures to protect sensitive data and meet compliance requirements, which may not have established solutions.
Checklist and questions to ask yourself
Here are a few things to consider when thinking about whether your project constitutes an advance in science and technology.
- Is the solution known at the outset? ie, can a competent professional readily deduce the solution using existing knowledge and techniques (either from their own accumulated experience or from information available within the public domain)?
- How has the lack of established methodologies or technologies been established? Need to show a good understanding of existing capability and its limitations.
- Is there a need for experimentation or prototyping? This shows the final solution could not have been readily deduced at the outset.
- Is there uncertainty around performance or integration? Is there a lack of knowledge regarding how well the eventual solution will perform or integrate with other systems or technologies?
- Is there a risk of failure? If there is significant risk that the project might not succeed due to technological challenges involved, this helps to demonstrate that the work is non-trivial and fundamentally uncertain.
- Could parts of the solution be open-sourced or distributed to the developer community, or has the technological solution been written about? This isn’t required by the guidelines (and is perhaps more relevant to the advance), but helps to demonstrate a genuine technological gap that could not have been readily deduced from information within the public domain prior to the project commencing.
How to document your work
Good R&D record keeping is essential for demonstrating that your work sought to advance the overall level of scientific or technological capability in your field. Comprehensive records will also help you:
- Show a systematic approach to R&D activity.
- Account for all qualifying expenditure.
- Back-up any apportionments you have applied to calculate qualifying R&D expenditure.
- Stay on top of filing requirements such as the additional information form and claim notification.
- Evidence the validity of your R&D claim should it be enquired into by HMRC.
The Guidelines for Compliance for R&D tax reliefs (GfC3), provide guidance on accurately documenting R&D and are a must read for all competent professionals.
Ready to start your R&D claim?
ForrestBrown’s multi-skilled team combines tax, legal and industry expertise to help you determine whether your project qualifies as R&D. If you would benefit from a project review, get in touch to discuss how we can help.