With the pace at which the world of software development moves, and the complexity of the different jargon used, it was perhaps destined to be one of the trickiest areas for R&D incentives advisers to tackle when it comes to identifying R&D tax relief opportunities.
And they’re not the only ones that have been left confused by the R&D guidelines. HMRC themselves have drafted in their IT gurus to help their own specialist R&D incentives inspectors to ensure they stay up to speed on the industry’s advances and the IT gurus have also been helping to review claims.
During 2018, HMRC put their legislative foot down, getting together a specialist committee to draw up new guidance, fill in the gaps and add some warmly welcomed clarity. In summary, some of the key bits of guidance are as follows:
- HMRC said that each IT project, or ‘commercial project’ as they refer to them, may have none, one or many R&D projects within it.
- And R&D projects within a ‘commercial project’ must be identified at a more detailed level: It’s not about new functionality, outputs or overarching capabilities. Or even new applications, platforms or architectures. The R&D will be in advances sought, and uncertainties faced in the underlying technology.
I am an IT expert and therefore, not only do I understand the R&D legislation, I will also understand the technical jargon and will help you to identify the elements of your projects that qualify for R&D incentives relief.
The key parts or your projects to consider in respect of whether you will qualify for R&D incentives include:
Understanding the baseline of the project is key!
What was the capability and status of the underlying technology/software when you started? The advances are made against the baseline, rather than the commercial output or outcomes being the advance.
Which elements of the design or development process were readily available when you started? For example, software components, libraries, APIs and standard design patterns.
What was the gap in underlying technological knowledge or capability that you were trying to bridge?
What was new, or different? What were you trying to change or make better?
Did you struggle to understand whether something was feasible? Or was the issue a matter of practical application? Either could be R&D.
What did you do to try and bridge the gap? And why wasn’t it an obvious decision for you or your colleagues?
What was it about the technology that made you uncertain whether software could be made to do what you wanted it to?
Why was resolving the technological uncertainty not routine or obvious?
What’s the typical approach to resolving the uncertainty and why didn’t it work?
Despite the new guidance, what counts as software R&D hasn’t changed it has simply become easier to understand and apply. This makes it an ideal time to look into that claim that’s been on your mind, or even to revisit a claim from the past. If you think any of the guidelines above might apply to your business, get in touch.