Software Development R&D claims have always been a difficult area, for those involved, to make the correct judgements.
It is complex area for a single blog to put right. I will focus on finding where in the project the claimable R&D is found. This is an area I have seen companies get wrong when they claim without experienced advice.
The software application functionality relates to/advances a non science or technology business field. The software development in itself while it involved a lot of specification, and production was routine.
Is this R&D for tax relief purposes? No.
The key reference for qualifying R&D activities is CIRD 81900 known as the BIS Guidelines. Paragraph 6 describes the advance in Science or Technology. An advance in a non science or technology application is therefore not an advance. This is a hard one for many businesses to take from there perspective. It is about what they do commercially, and what matters to them. But it is how R&D is defined for tax relief purposes that matters. The tax definition. Business process improvement/commercial activity is not R&D on that basis.
So for example the smartest most comprehensive insurance quote software on the market, cannot qualify on the basis of the comprehensive way it handles the insurance industry, and data around quotes and compliance. This type of achievement is not scientific or technological but commercial.
The same CIRD also covers scientific or technological uncertainty. These have to be the opposite of routine they have to be “not readily available or deducible by a competent professional working in the field”P13. As standalone work the software development does not qualify in this example.
Neither aspect of this project qualifies. I often hear the case: software to do this (functionality) did not exist before the project, is not creating it advancing the capability of software? Unfortunately, no. Software could do what was achieved in the project, simply nobody had actually done it. But it could have been done as the software development was routine. R&D is about pushing boundaries of what software can do not routine production.
As before the Software application functionality relates to/advances a non science or technology business process. But the software development is not considered routine by the competent professional.
Is this R&D for tax relief purposes? Partly.
We have explained why research outside a field of science or technology does not qualify. BIS Guidelines paragraph 6. So for example the research work done by a skilled insurance operative with the job title “Head of Global Markets” would never qualify. He or she are not advancing science or technology.
But in this case we are saying the software development was not routine, it was not “readily deducible”. This is always a hard area in which to make judgements. All anyone considering those can do is behave reasonably and follow the Guidelines as a whole.
So suppose at the point in time our insurance software was produced two large software changes were relatively new and not broadly documented in the public domain, lets say running large business applications in the cloud, and micro services architecture. Implementing those two new technologies led to the development of new knowledge and capabilities in about those technologies. Completely divorced from “insurance” but very much about information technology. The developer through experimentation gained new knowledge that was not codified in academic circles or blogs, and created new capabilities that could be applied to different types of software applications. Software Development R&D is being undertaken and can be claimed if it meets all the Guidelines. The narrative supporting the claim would need to make these points in detail.
The functionality of the software directly contributes to a broader R&D project that qualifies under the BIS Guidelines. The software development in itself was routine but directly contributed to the larger R&D project.
Is this R&D for tax relief purposes? Fully.
The functionality is about contributing to qualifying R&D. The software development work qualifies as a claimable cost part of the larger project.
In this example what the software does qualifies as it contributes to a qualifying project, unlike the first two examples, it ticks all the boxes in the BIS Guidelines. For example the project is about improved battery life in mobile phones, part of that involves the software to manage the battery life. You cannot reasonably experiment with different battery designs without running them in prototypes and the routine software development is part of that prototype build.
A second example might be software developed or bought to manage data in a clinical trial. The software development qualifies as part of a larger qualifying project, not in its own right. But this enough.
Potentially the functionality of a project might involve science or technology but not meet the conditions in the Guidelines. It might be about routine/known science or technology. The labels “scientific” or “technological” are not enough on there own. It boils down to the Guidelines. In those cases you would need to look at the project as just being about the software and judge if the software development qualified. The final example is where both the application area and the software qualifies the best type of software project to claim! Or at least equal best with example 3 in terms of the boundary of claimable costs being the largest.
Here is a table which shows the scenarios covered:
|Example||Nature of software project||Application Area/Functionality work/costs||Software Development|
|1||Application area not Science or Technology. Routine software development.||Does not qualify as R&D. Costs don’t qualify.||Does not qualify as R&D. Costs don’t qualify.|
|2||Application Area not Science or Technology. Software development meets the threshold for R&D in the Guidelines.||Does not qualify as R&D. Costs don’t qualify relating to market research or the commercial aspect of the project.||Qualifies as R&D. Costs relating to technological uncertainty qualify.|
|3||Application Area is Science or Technology & qualifies as R&D. Software development is routine but part of the R&D in the first sentence.||Qualifies as R&D. Costs relating to technological or scientific uncertainty qualify.||Qualifies as a claimable cost in larger R&D project.|
|4||Application area is Science or Technology, but no R&D involved. Software development is routine.||Does not qualify as R&D. Costs don’t qualify.||Does not qualify as R&D. Costs don’t qualify.|
|5||Application area is Science or Technology, but no R&D involved. Software development meets the threshold for R&D in the Guidelines.||Does not qualify as R&D. Costs don’t qualify.||Qualifies as R&D. Costs relating to technological uncertainty qualify.|
|6||Application Area is Science or Technology & qualifies as R&D. Software development meets the threshold for R&D in the Guidelines & is also part of the larger project. This is the “double lock”.||Qualifies as R&D. Costs relating to technological or scientific uncertainty qualify.||Qualifies as R&D. Costs relating to technological uncertainty qualify. Plus even if that was not the case as part of a larger R&D project|
Summary of key points.
- Not all software development qualifies. Only if it advances fields of science or technology.
- Improvements in functionality don't in themselves qualify. You must qualify as per the BIS Guidelines. The common mistake is to claim an advance that does not relate to scientific or technological fields as defined in the Guidelines.
- If you are going to claim for software R&D the judgement of the competent professional is key. This is about how the project relates to the Guidelines. Trying to make an R&D claim without the input of the key technical staff is an incorrect approach.
- The cost of routine software development, usually does not qualify, but can qualify if part of a larger qualifying project as a claimable cost.
I have worked on thousands of software R&D project narratives and have seen hundreds of millions of pounds in qualifying costs. Where an experienced consultant can help is simplifying what is quite a complex set of claim conditions. This saves time which is crucial when working with R&D staff. If you would like to discuss your software R&D claim please get in touch. A free assessment is a lot easier than trying to work out the Guidelines from scratch.
Christopher Toms, Director RandDTax