ICT organisations, and in particular software development companies, that are claiming the research and development (R&D) tax credit have witnessed an increase in the level and intensity of Revenue inspection into their R&D tax credit claims. As the legislation has matured and the number of claimant companies has increased, so too has the number of technical audits and aspect queries being carried out by Revenue.
“It is common for claimant companies to misunderstand aspects of the science test, or worse, fail to understand the qualifying criteria in the first place. The single most likely cause of claimant companies having to make adjustments are errors which relate to the question of eligibility”
advertisement 
This is true of all industries where R&D is carried out and the rules are no different for ICT and software, yet software seems to have been singled out by Revenue — why? There has been a view for a long time in software development that “new application features” is justification for R&D (for the purposes of tax) to have been undertaken, and this is simply not the case.
Common misunderstanding
In our experience, it is common for claimant companies to misunderstand aspects of the science test, or worse, fail to understand the qualifying criteria in the first place. The single most likely cause of claimant companies having to make adjustments are errors which relate to the question of eligibility.
For a software company to qualify for R&D tax credits, it must adhere to the following criteria as set out in Revenues guidelines circa April 2015:
- Activities must be systematic. That is to say, they must form part of a planned approach to achieve a specifically desired outcome. They must also be investigative or experimental in nature while maintaining contemporaneous documentation related to the activity. Both agile and waterfall methodologies in project management are acceptable to Revenue when evidencing a systematic approach.
- Activities must be undertaken in a recognised field of science/technology.
- A claimant’s activities must be either Basic Research, Applied Research or Experimental Development, (i.e. Experimental Development is systematic work, drawing on existing knowledge gained from research and/or practical experience, that is directed to: producing new materials, products or devices; installing new processes, systems and services; or improving substantially those already produced or installed). In our experience, the majority of software development claims are experimental development.
- A claimant must seek to achieve a scientific advancement, and in doing so seek to resolve scientific/technological uncertainty in the relevant field of computer science or mathematics.
Almost all software companies, by virtue of the way they manage projects, costs and time will feel that they meet the first three criteria. But what we continually see in software development is that the R&D performed by software companies, is often small subsets of qualifying activities within an overall project. That is to say that there tends to be pockets of qualifying R&D where technological uncertainties and advancements lead to new knowledge within the field of computer science or mathematics.
Some useful questions to ask of your project managers are:
- Are your development teams pushing the boundaries beyond the normal expectations and capabilities of competent professionals within their field?
- Are the developmental activities carried out not only difficult, but require experimentation to deliver, perhaps with some failure along the way?
- Have you achieved an output of new knowledge or understanding in the field of computer science or mathematics? Can this be evidenced by supporting documentation?
There are many motivations for software development to take place some of which include:
- New application development,
- Feature extensions,
- Version updates,
- Functionality additions / enhancements and updated versions,
- Platform changes etc.
Each development project which is undertaken by a company should be looked at under its own merit to make a reasonable determination as to its eligibility for R&D tax credits. Obviously, it is very difficult without specific project information to provide clarity as to what does and does not qualify but, in an attempt to provide an example that makes sense, let’s assume two scenarios, one high risk (i.e. not likely to qualify) and one low risk (i.e. likely to qualify).
High risk activities
General application maintenance such as updates, bug fixes, security and corrective maintenance and routine user interface (UI) development are the kinds of operational development processes that generally utilise existing architectures and commonly known methodologies. These activities are typically regarded as non-qualifying activities in relation to resolving technological uncertainty.
The same logic can be applied for the configuration of large and complex Enterprise Resources Planning (ERP) applications which can require substantial set up. Although this can be complex in nature as well as labour intensive, time consuming and expensive, these activities are generally not directed in attempting to resolve scientific/technological uncertainty.
There are many more examples of high risk activities, but hopefully the above provides a flavour of why these activities would not be deemed as eligible when we look for scientific uncertainty/advancement in the field of natural science and its allied fields of computer science and mathematics.
Low risk activities
The development of new constructs like new architectures, algorithms, or new database management techniques see a high percentage of qualifying R&D activity. Often a process of experimentation is required to resolve scientific uncertainties. This process of experimentation is designed to evaluate alternatives that relies on a scientific approach.
Again, there are many other examples that relate to low risk activities. However, with this in mind, the important thing to note is the actual scientific advancement made in the field. Also, to effectively showcase a scientific advancement, the claimant must recognise the current state of the art (i.e. base knowledge) in the correlating field of science, prior to undertaking any research and development activity. If a claimed advancement does not incrementally improve upon existing technologies (state of the art) within the field of computer science or mathematics, then it may be difficult to support the claim in the event of an audit by Revenue.
Conclusion
The rules of the R&D tax credit are the same for all industries with regard to the eligibility or otherwise of the activities. Companies must realise that the R&D tax credit is complex, administratively burdensome and can very often be subjected to investigation by Revenue. It is vital that the technological criteria for inclusion is understood and analysed as part of the claim process. It is also crucially important for a company to be able to demonstrate with contemporaneous evidence that the R&D investigations that took place over the claimed accounting period. A clear link must be drawn between the qualifying activities and financial costs being claimed.
The R&D tax credit is a valuable incentive for companies to undertake often costly and high risk activities. However, the claim process can be administratively burdensome, and understanding the complexity of the legislation difficult, therefore seeking out professional advices from the start is advisable.
Andrew O’Reilly is senior manager of Tax for Deloitte
Ltd
