In Get Onbord Limited (in liquidation) v HMRC [2024] TC09238, the First Tax Tribunal (FTT) considered the meaning of R&D as whether a project heavily reliant on Open Source coding and software to develop a streamlined and AI-automated process for onboarding new clients under the Money Laundering Regulations (MLR) was actually engaged in 'research and development' in terms of the BEIS Guidelines. The FTT also advised future claimants on their approach to case management.
Get Onbord Limited (GOL), a Small or Medium-Sized Enterprise (SME) claimed a surrenderable loss in respect of its qualifying expenditure on Research & Development (R&D).
- Its R&D project was to develop a novel, automated Artificial Intelligence (AI) analysis process for ‘Know Your Client’ (KYC) verification and risk profiling.
- The main objective of this project was "to develop AI-enabled holistic analysis of a new counterparty during a financial services customer onboarding process that could achieve a superior outcome to human analysis and meet all regulatory and legislative requirements.”
HMRC investigated the R&D claim and then challenged it because the expenditure was not qualifying R&D. It did not meet the BEIS Guidelines for R&D relief. In essence, HMRC argued that the company was not undertaking scientific or technical activities that were unique in any way, they were using Existing open-source code, AI, and APIs on their data in a way that could be done by any competent professional working in the field.
The company appealed HMRC's decision to the FTT.
R&D, as defined for tax purposes, generally follows accepted accounting practice, but that definition is modified by the BEIS Guidelines: the Meaning of R&D for tax purposes.
The tribunal followed 'a narrow approach' in interpreting the guidelines, using earlier tribunal decisions.
HMRC did not provide an expert witness: its officer dealing with the case did not have a software specialist or developer background.
It was up to the company to present its evidence and this was given by the company's director at the time. The company's software engineer did not, to the tribunal's disappointment, give evidence.
- Mr. Cahill, the company director, was a credible witness who has worked for more than 25 years building models for investment banks. He had written code and described himself as an expert in building models to analyse risk.
- He described his project as creating knowledge and capability using open-source material. The company was looking to see if it could develop an AI system that could do this more effectively than humans.
- Mr Cahill’s evidence, reflected in the company's R&D report, argued no system in the market did this and in consequence, it was uncertain whether it would be possible to build a system that could do all that was required.
- Examples show new features being created and experimented with and improved. None of these pieces of work appear to be routine or readily deducible developments.
- Mr Cahill also said that he could not see technology being used this way anywhere. No bank had developed a system like this that he knew of (the market solution being to throw bodies at the task) and (as he put it) he would not waste years of his life trying to do something anyone could easily achieve.
- GOL had not sought to protect its software and stored its code on GitHub
The FTT found that the evidence was that GOL was trying to work out whether it was technologically feasible to build an AI system to deal with KYC verification and risk profiling.
- It accepted that using existing code (including from a code library) or other existing technologies (for example, using existing programming languages, frameworks and tools) is common in the software development world.
- It could see that for itself in the way the non-profit OpenAI organisation works and had evidence from Mr Cahill about one of the uses of GitHub.
- It did not consider that, of itself, the use of Open Source, or other existing materials indicates that a particular development is routine or readily discernible from publicly available materials.
- The question of whether a development is an overall advance is a question to be answered on a case-by-case basis (by asking whether the development is a routine advance or otherwise readily discernible), but it is not necessary for each component part of the solution to be novel or bespoke to the project in question.
- As Mr Cahill observed, given the amount of Open Source software/AI material available, if complete novelty were the test, no software project would ever amount to R&D. That is quite clearly not the case as the BEIS Guidelines themselves contemplate that an appreciable improvement to an existing process can amount to R&D.
In light of all this, the FTT was satisfied, that GOL had an R&D project on the balance of probabilities:
- GOL had a project with a defined aim;
- The technology GOL sought to develop and incorporate in the project was not already publicly available or readily deducible.
- The technology it sought to develop to achieve the project’s aims amounted to more than 'routine' copying or adaptation of an existing product or process.
- The project required the resolution of technological uncertainties which a competent professional working in the field could not have readily resolved.
The FTT's final words were:
"Before concluding we would like to add a few words about process. It will be readily apparent that this case has turned on the question of the scientific/technological quality of GOL’s project, putting the point very (possibly too) simply 'Was it a routine development or a real, meaningful scientific/technological advance?' We consider that these proceedings would have been much more straightforward (and possibly could have been avoided) if, at an early stage, both parties had “put their scientific cards face up on the table”. Ideally, GOL would have produced a single document in which it marshalled all its scientific/technological evidence, including evidence from a competent professional (which is clearly highly desirable, whether or not it is strictly necessary), and HMRC would then have replied to that document with details of its own scientific analysis and evidence. It is not for us to tell other people how to run their cases, but our experience in this case would lead us to suggest this as an approach which might usefully be considered where similar issues arise."
Editorial comment
This is an FTT decision and does not set any legal precedents. The case illustrates the problem for HMRC in dealing with cases involving the use of Open Source software.
Recent changes to the legislation have changed the nature of the SME R&D claim, but it is now a requirement that a company makes an Advanced Notification to HMRC before submitting any new claim.
Useful guides to this topic
Research & Development relief
Visit our R&D Zone: how to make a claim, what qualifies as R&D, new claims process, what is the new RDEC variation?
What is Open Source Software?
What is Open Source software? How is Open Source software used? What is the best Open Source software? Where is Open Source code stored? What Open Source AI is available?
R&D: Meaning of Research and Development: BEIS Guidelines
What is Research and Development for tax purposes? What is the meaning of Research and Development for Tax? What are the BEIS guidelines on Research and Development?
Need assistance with an R&D Claim?
Contact Nichola and her team at the Virtual Tax Partner service for assistance in making a claim, assistance in dealing with an R&D enquiry, assistance in planning R&D projects and reporting.
External links
Get Onbord Limited (in liquidation) v HMRC [2024] TC09238
