“Does this activity qualify for R&D?”
This is one of the most common questions we are asked by clients and accountants, and often the answer is not easily arrived at. Software development is no exception in this regard. In fact, in a sector where new technologies can emerge, gain prominence and fade into obsolescence in the time between two world cups, answering the question becomes all the more difficult.
Whether a given piece of software development constitutes R&D for tax purposes is rarely an easily answered question, even by software developers themselves. In fact, in our experience software developers are often worst-placed to answer that question about their own work. Instead they will often dismiss their work or the problems that they had to overcome, because it couldn’t be “real R&D”.
This commonly encountered underselling shouldn’t really be a surprise. The vast majority of the programming R&D that we come across involves using well-known programming languages, which are built on hard and clear rules and on which there is plenty of documentation, to try to develop some functionality. If a coder adheres to the rules and slowly builds up a complex solution using existing building blocks, lines of code that individually look simple and (hopefully) readable, can that really be R&D?
The answer, of course, is a resounding yes.
On that there is no doubt. HMRC in its own case studies, and in an inquiry into a successfully defended R&D claim, have told us that. But not all such development will qualify, as HMRC are naturally quick to remind us. Routine software development, or problems that could be readily overcome by way of discussions with colleagues (or rubber ducks, for that matter), will not.
In trying to establish whether a given piece of software development is qualifying R&D or not, often the destination is not as significant as the journey itself. In assessing software development for R&D, we have a series of questions about the development process that might be indicative:
- Were there functionalities or features that were unable to be implemented?
- Were large restructures or refactors required part-way through development?
- Was Stack Overflow lacking in relevant help?
- Was there significant performance optimisation required?
- Were there long periods of trial and error to find the right solution?
- Were there multiple development paths available with no obvious best choice?
- Did development take far longer than was planned for reasons other than incomplete specifications?
If any of the answers to these is yes, there might be the basis for an R&D claim. We have performed claims for software companies of varying sizes, from single-employee businesses to large multinational powerhouses. Projects claimed for vary from lightweight (but complex!) internal administrative software or innovative mobile apps to scalable global communications networks and governmental department software .
To find out more, please visit www.ianfarley.com or call Ian on 07752 386484 to arrange a no-obligation discussion.