When is a software development project routine, and when is it genuinely innovative and deserving of R&D Tax Credits?
The question was put to the test recently, when an Irish IT services company (mostly) won a Tax Appeals Commission case against Revenue. The case centred around whether or not the company’s expenditure on developing a new ‘aggregated service desk’ and portal qualified as R&D for tax purposes.
The full determination can be found on the Tax Appeals’ website. It makes for interesting reading, especially for anyone working on innovative software development projects of their own.
Below, we provide an overview of the case and its implications.
What was Revenue’s case for refusing the claims?
The claimant company had tried to claim 25% of the project’s qualifying expenditure, which came to €86,011 for their R&D work in 2012, and €117,803 in 2013, but Revenue refused both of the claims, arguing that the project failed to meet the definition of R&D for tax purposes.
Revenue’s definition says that a project must:
- be systematic, investigative, or experimental
- seek to make a technological advancement
- involve basic research, applied research, or experimental development
- seek to achieve a scientific or technological advancement
- resolve either a scientific or technological uncertainty.
Revenue didn’t strongly dispute the first three points (with some caveats – see the section below on ‘Agile’), so the main reasons for the rejection were whether the project made a technological advancement, and if it resolved a scientific or technological uncertainty.
Their expert witness argued that he “saw no evidence of attempts to achieve technological advancement, where that advance was an advance in overall knowledge or capability in the field.” 1
Revenue’s witness also argued that it was common to see uncertainties during software development projects, but “uncertainty, on its own, cannot be taken as an indicator that R&D activity is taking place” especially when they crop up during the “routine development of software products”. 2
Revenue also objected to the impartiality of the company’s first expert witness, because he’d written a ‘letter of support’ for the company in 2017, and co-authored a ‘position paper’ setting out the company’s case in 2019 (the commissioner agreed with these objections, so evidence from this individual was not part of the determination).
What was the company’s case for challenging Revenue’s decision?
Today, such cloud-based support applications, where multiple users can securely access the same software application online, are common, but the company’s expert witness put forward that when they developed their software in 2012 and 2013 “multi-tenancy in the cloud was a new technology”. 3
They maintained that they faced a host of technological uncertainties. Security was a big concern, as they had to work out how to protect virtual machines from hacking. There was also no SLA by Microsoft, so they had to develop failover and disaster recovery solutions. They also needed to find a way to upload large amounts of data from virtual machines.
They said that these challenges, which needed R&D to overcome, came from the fact that Microsoft’s Azure platform was “immature” and “in beta” when they began their R&D activities. As there was no solution available at the time, development work was needed for them to achieve their objectives.
They argued that these were significant uncertainties because: “There was no reference architecture, recommended approach, how to do this with Microsoft technology. So, you know, there was no booklet you could follow. There was no online documentation you could go to and say this is exactly what we need to do this…” 4
Is Agile suitable for software development R&D?
During the case, Revenue claimed that the company’s Agile approach, which involved scrums and sprints, wasn’t a suitable methodology for R&D. 5
If true, this might impact countless potential R&D claims as Agile is widely regarded as the industry standard in software development. With this in mind, the company’s expert witness had strongly argued that the IT company’s Agile approach was “in effect, the only method” for this type of software R&D. 6
Fortunately, the Commissioner agreed that Agile was systematic and therefore eligible for R&D claims (in fact, they pointed out that Revenue’s own guidelines on R&D Tax Credits say that Agile development methodologies “are systematic in nature”).
But that doesn’t mean that all Agile projects are eligible for R&D credits, it just means that it can be used to satisfy the ‘systematic’ test. One of the issues during the case was that the record keeping wasn’t part of their Agile process, and records are vital for making successful R&D claims. Other companies using Agile should take serious note of the fact that the Commissioner warned that the “project team could and perhaps should have kept more detailed records of their work”. 7
What was the outcome?
In the end, the Tax Appeals Commission determined that R&D had indeed taken place.
A key part of this decision was the Tax Appeals Commission’s acknowledgement that: “There was as of 2011, when the project commenced, no remotely accessible aggregated service desk hosted on an IaaS cloud platform”. 8 The Tax Appeals Commission believed that Revenue hadn’t given this fact enough weight when they initially rejected the company’s claim.
They also felt that the company’s solution, created through an iterative development process, was “no small achievement of software development brought about by routine procedures”. 9
The company received €76,795 for the 2012 claim and €100,590 for 2013, covering approximately 89% and 85% of their original claims.
They didn’t receive the full amount because two employees’ contributions were found not to have ‘wholly and exclusively’ contributed to the R&D project. One had focused on project management, while the other simply advised on IT support processes and systems, rather than being involved in the actual R&D work.
What does this determination mean for other software development R&D projects?
The question of whether a software development project is routine or innovative might put off some companies from claiming R&D Tax Credits, but if their work is eligible, such companies could be missing out on hundreds of thousands of euros in tax credits.
The risk of being challenged by Revenue is also something that most companies would naturally want to avoid (especially if it takes over ten years to resolve, as it did in this case). But it’s important to recognise that the company could have presented a stronger claim. Their record keeping could have been more detailed, they should have only claimed expenditure that ‘wholly and exclusively’ contributed to the R&D, and they should have made sure that all of their expert witnesses were completely independent and impartial.
While it’s fairly clear that they met criteria for claiming R&D Tax Credits, some of these mistakes were avoidable, and might have contributed to Revenue’s decision to refuse their initial claim.
How Leyton Ireland can help
Have you been working on a software development R&D project, but you’re not sure if it’s routine or innovative? We can help.
We’re not just tax specialists, many of our team have come from industry backgrounds, meaning that they have years of expertise in the software sector.
Their deep knowledge of recent innovations in software development, can guide you on what’s genuinely new and what’s already standard practice, paving the way for a successful R&D Tax Credits claim.
We can handle all the heavy lifting, including preparing a robust technical report that captures all of the relevant project information as well as a comprehensive financial breakdown of qualifying R&D expenditure. We’ll work with you to identify every aspect of your project that qualifies for the credit (in fact, we often uncover qualifying expenditure that wasn’t considered previously).
We’ll also make sure that the complexities of your project, and the scientific and technical context of your advancement, are clearly explained to Revenue, giving your claim the best possible chance of being understood and accepted.
If you enjoyed this article, you might also like:
[1] Page 16, clause 48.
[2] Page 26, clause 85
[3] Page 120, clause 460
[4] Page 119, clause 456
[5] Page 121, clause 469
[6] Page 120, clause 461
[7] Page 144, clause 558
[8] Page 136, clause 529.10
[9] Page 143, clause 555
