Software-based R&D claims can be one of the trickier types of claims for accountants to understand as, unless they also have a background in computer science, being able to tell a complicated, non-qualifying software project from a qualifying one can be difficult.

This means that often once the accountant has explained what their understanding of qualifying R&D is, their client is left to write the technical project details which the accountant then uses as the basis of their claim, without ever really knowing if the included project(s) qualify or not.

This approach is seriously flawed, as a lot of accountants are currently finding out due, to HMRC opening an enquiry into their client’s software R&D claim and them finding it impossible to successfully defend a claim they don’t really understand.

We have been asked to assist with over a dozen enquiries into software-based R&D claims in the past month, with most being invalid, so hopefully this guide will help accountants understand how to better advise their software clients and give some pointers on the questions to ask, BEFORE submitting a claim to HMRC.

To start with, let’s take a look at some of the common misconceptions that people, including accountants, have about software projects in relation to R&D tax relief.  Each of these we have heard numerous times over the last 10+ years.

“All software development qualifies for R&D tax relief”

Not true, in fact most software development doesn’t qualify for R&D tax relief as it still must meet the same criteria as any other type of claim.

“No software development qualifies for R&D tax relief”

Not true, as whilst most software development doesn’t qualify for R&D tax relief there are some projects which do.

“If you are creating computer software that doesn’t already exist, this qualifies for R&D tax relief”

Again, not true as simply creating new computer software isn’t enough for a project to be considered as qualifying for R&D tax relief.

The different types of software project

Software development projects tend to fall into one of three categories:

Easy projects – These are where the developers know how to create the desired software and how to easily overcome any technical challenges. Not to say they won’t take some time, but the outcome of the project is known at the start.

Complicated projects – These tend to take a while and there may be specific technical challenges for the developer to overcome which will require some research as they don’t know off the top of their head how to do it, but fairly quickly they will find some information, usually online, to help.

Qualifying R&D projects – As with complicated projects, these tend to take a while and there will be specific technical challenges for the developers to overcome with the difference being that no publicly available information on how to overcome these challenges exists, meaning their research will return no useful information.

The first two types of software project do not qualify for R&D tax relief, it’s only the third kind which does.  Whilst the project information for a complicated and qualifying project will look very similar, it’s the way in which the project’s technical challenges were overcome, either by using some existing knowledge, or having to create new knowledge, which define which type of project they are.

Why do accountants find software-based R&D claims so hard?

The main reason is that accountants and software developers speak two quite different languages, accountants talk about EBITDA and double entry bookkeeping, whilst developers talk about APIs and hosted server stacks, which can make it difficult for them to understand each other.

Just like accountants, developers will also often use industry specific terms when providing project information.  They may also believe that they should try and make their project information sound as complicated as possible as it will help their case, which it doesn’t.

All that happens is an accountant will see the information and think “that all sounds very techy, so it must qualify” which is often not the case.

For example, if a developer wrote the following, would you be able to tell if it would appear to be part of a qualifying R&D project?

“To create our software, first we had to setup and configure a LAMP stack in a hosted environment, including design of the SQL tables and custom queries, we then developed a custom back end using an agile methodology which included numerous, complex, API connections to a variety of 3rd party systems.

Once this work had been completed, we developed a custom data extraction engine and started development of our front end.”

Yes? No? Not sure… well let’s see if explaining what the words in bold mean helps.

LAMP stack is simply when developers use four very standard technologies (Linux, Apache, MySQL, and PHP) as their development environment.

Linux is the operating system, a free alternative to commercial operating systems like Microsoft Windows.

Apache is a web server which allows the developers to publish webpages users will use to access the system.

MySQL is a database used to store information. Think of it as being lots and lots of Excel spreadsheets containing information, with each spreadsheet being called a table which you can then run searches on (aka queries) to get the information needed to run reports etc.

PHP is a programming language, which the developers will use to create their software.

Hosted environment  just means that rather than having your servers at your own premises they are “hosted” by someone else, usually in a data centre which is just a building used to house lots of servers.

Front end is the bit the user sees, for example when you are using Xero, it’s the dashboard, the bit with all the menus where you can select reports and perform functions like bank reconciliation.

Back end is the bit behind the scenes the user doesn’t see, for example when you request a Profit and Loss report in Xero, the back end is what goes off and gets all the necessary information for the report from the database, it then passes this information to the front end which displays it in a nice layout for you.

Agile methodology is a way of programming and simply means that rather than documenting all of the features that the software will have at the start of the project, you start developing with some basic ideas and then add new features as you go.

API stands for Application Programming Interface and whilst it might sound very high tech, it’s really not and is just a way for computer systems to transfer data between themselves.

Remember the old days of Sage Line 50? When you wanted to perform a bank reconciliation you had to download a CSV file from the bank, then import that into Line 50.  An API allows you to do that without needing to download a CSV file.

Custom data extraction simply refers to the process of analysing lots of data, often from various sources, to combine it into a useful format.

In the same way, when looking at a company’s finances you might look at the P&L, Debtor Ledger etc. then take various parts from each to include in a report, data extraction in computer systems does the same thing, with custom just meaning it was something you had to configure for your purposes.

So, let’s look at our example project again.  Broken down it just means that the developers had to:

Setup their development environment (Setup and configure a LAMP stack).

Which they did on server(s) not on their premises (in a hosted environment).

Then they configured their database (design of the SQL tables and custom queries).

The back end was then developed (we developed a custom back end using an agile methodology).

This included obtaining data from other systems (numerous, complex, API connections to a variety of 3rd party systems).

They then created a way of collating the data collected (we developed a custom data extraction engine).

Then they started to develop the web page which users will access to use the system (started development of our front end).

Does it make more sense now? Have you changed your mind as to if the development would qualify for R&D tax relief?

For clarity, nothing in the list above would qualify for R&D tax relief, as whilst it may have been complicated and taken some time there is nothing there which isn’t quite common when it comes to computer science.

So, what software development does qualify for R&D tax relief?

The criteria for a qualifying software-based R&D claim is the same as with any type of claim in that it has to be “attempting to create an advance in a field of science or technology via the resolution of scientific or technological uncertainty”.

It’s the last part of this qualifying criteria which actually tends to cause most software-based claims to fail, as a lot of software developers like to share knowledge so if they find out a new way to do something, or they find the solution to a common problem then they will share this information online to help others – if you can find out online how to do whatever it is you are trying to do then there is no uncertainty.

There are also countless code libraries available online.  These are bits of software written by developers to perform all manner of tasks from sorting data, to playing music in a webpage and these can be used by others looking to do the same without them needing to manually write their own code.

At the start of any software project, there will usually be things that the developers know they can technically achieve and things they are not sure about.  This could be because they haven’t done it before themselves, or it could be that no one has ever done it before.

The things they know they can achieve do not qualify and if they can do some research, usually online, to find ways of doing what they are not sure about, the project does not qualify as this would be considered “readily deducible”.

It is only once they have done some research and found nothing which will tell them if technically what they are attempting is possible does the project potentially qualify for R&D tax relief, as the required uncertainty would exist.

Questions to ask yourself before submitting a software-based R&D claim

Q. Did a competent professional work on the project?

A competent professional in terms of software development would likely be someone with at least a degree, or some other valid qualification, in computer science and who has spent 5+ years working in a software development role.

If no competent professional worked on the project, then no qualifying R&D can have taken place and the project doesn’t qualify.

Q. Do you understand the technical information provided by your client?

If not, there is a high chance that anyone at HMRC reading the information also won’t, and this can lead to an enquiry being opened as HMRC request that all technical information sent to them is in “layman’s terms”.

So, the information should be rewritten using simpler terms.

Q. Are the projects’ uncertainties and the advance being sought clearly described? And are you sure they are industry wide? Or just in relation to this project?

When HMRC check an R&D claim, the uncertainties and advances sections are what they most look at, as these are the things which help them determine if a project was the unqualifying complicated kind, or if it meets the criteria for R&D tax relief.

If these sections are missing, or don’t make sense, then they should be rewritten

Q. Is the advance being sought in computer science?

This is a common issue we see in software claims where the listed advance is related to a specific industry and not computer science.

For example, developing a new piece of software for the accountancy industry might create an advance for accountancy firms, but unless it also creates an advance in Computer Science then the project does not qualify for R&D tax relief.

Q. Were the project’s uncertainties overcome using existing technology – some code the developers found online, for example?

If the answer to this question is ‘Yes’, then the project won’t qualify, as simply using existing technology to overcome uncertainty does not qualify for R&D tax relief.

If you have any questions on this blog or anything R&D related, please contact us at [email protected].

Posted: 13 Jun 2023