HMRC Updates their Guidance on Assessing Software-Related Claims

In the past 12 months, claim statistics show that there has been a significant increase in both the number of claims made and HMRC scrutiny of those claims. Our main specialism is in software R&D claims and this has been an areas of particular focus by HMRC.

Following on from the 5th October 2018 update to the HMRC CIRD manual with updated guidance given on software claims in R&D tax relief: conditions to be satisfied: BIS Guidelines (formerly DTI Guidelines) (2004) – application to software , at the end of 2018 HMRC released CIRD81980 which gives 4 fictitious software R&D claims case studies.

We set out some of the key points in the case studies in terms of how this affects R&D claims for software projects and begin by noting that there are a number of interesting features of the case studies chosen. Firstly, all four are in respect of claims that contain qualifying R&D projects that meet the criteria of seeking a technological advance through the resolution of technological uncertainty. In each case, different boundary aspects have been highlighted. These boundary areas are frequently the most difficult to ascertain, verify, and explain to HMRC in any claim.

Specifically, these are:

  1. Differentiating between the commercial project and the R&D project for tax purposes
  2. Determining when the R&D project for tax purposes starts and ends
  3. Differentiating between the parts of the R&D project that are allowable (i.e. those that directly contribute to the resolution of technological uncertainty) and the parts of the R&D project that are not allowable (almost anything else[1]).

While there may be concern that projects that specifically match the areas within the case studies (data and IT services cloud migration, big data analytics, machine learning, UI/UX experience and computer vision) will be subject to a more simplistic scrutiny by HMRC staff who try to compare the technical information provided with a claim to the case studies, we believe that this is unlikely to occur if the project qualifies and where the basis for eligibility is well explained in the supporting claim documentation. Where the basis for eligibility is not explained clearly, for example, if poor quality, or no, documentation has been submitted, then closer inspection could result in rejection of some or all of the claim.

As well as explaining why an R&D project is eligible (i.e. attempting a technological advance in terms of industry capability through the resolution of technological uncertainty) the three boundary areas highlighted above must be adequately explained in the supporting documentation or the claim is more likely to face increased scrutiny.

Having well-written and robust technical claim documentation is our specialty and while some claims are inevitably selected for a further review on a random basis, in our view a well-prepared claim  with strong supporting documentation is key to both having claims successfully accepted, and also, should an enquiry happen, being able to defend them.

As a long drawn-out HMRC enquiry can take as much as ten times as much effort as preparing a claim in the first place, with the volume of claims that we submit (more than 100 in 2018) our objective is to ensure that all claims are accepted on the strength of the supporting documentation, which must illustrate that the project meets the criteria as R&D for tax purposes, that the claim, and specifically, the mapping of the financial elements to the qualifying technical elements are prepared in accordance with the legislation. No less important is that this can be demonstrated to HMRC clearly and concisely.

The first, and most important question, is whether there is an eligible R&D project. The mistake that many companies make, highlighted in the case studies, is thinking, ‘well, we haven’t done it before so it must be R&D’ without considering the knowledge of the IT industry as a whole.

Once qualifying R&D is ascertained, there also needs to be a clear differentiation between the commercial project and the R&D project. As the BIS Guidelines make clear, there is no 1:1 mapping between the two and there may be one or more R&D projects (that may themselves be comprised of sub-projects) that are elements of a single wider commercial project, or conversely, a commercial project may form only a part of an R&D project.

In either case, the boundaries of the R&D project are formed by the presence of technological uncertainty (again, baselined against the industry as a whole) which determine when the project starts, when the project ends, and what can be included in the claim. All of this should be clearly documented when submitting a claim.

Finally, simply assuming that an employee was working 75% of the time on “development” and then claiming 75% of their salary will not withstand scrutiny unless it can be shown that it was qualifying development for tax purposes and that the percentage of the costs claimed was the proportion of time directly contributing to the resolution of technological uncertainty.  The mapping of the technical eligibility to the qualifying costs and explaining clearly to HMRC how this has been done is therefore the key element here.

It is worth a further comment on where these case studies have come from. Our claims attract a very low rate of enquiry and we have a 100% claim success rate. However, sometimes there may be a referral of the technical elements of the claim by the HMRC compliance officer in the R&D unit to the HMRC CTO unit who act as in-house IT consultants.  The style of these published case studies, while fictitious, is extremely similar to the actual reports produced by the CTO office which provide an opportunity for HMRC’s to give an opinion on the technical validity of the work.

Frankly, many who have been in this industry since the beginning are unsurprised by this approach. In the US and Canada for example, having technical specialists who audit R&D claims has been standard practice for decades. The intangible nature of software has meant that is often difficult for non-technical HMRC inspectors to understand what is being claimed for and whether work meets the legislation.

In the past 12 months, we have seen an increase in companies who approach us for assistance with a claim having been told they are eligible, and who we have to turn away, quite simply because they do not meet the requirements of carrying out R&D for tax purposes. This has been exacerbated by non-specialist firms with aggressive telemarketing campaigns who will target, for example, all software companies in a certain geographic region, offering “bargain basement” fees, and promising that they are entitled to a rebate from HMRC.

It takes no skill to write an incorrect unsupportable number in the R&D claim box on the tax return, the same as filling in any other box but in the event of HMRC enquiring a claim, and rejecting some or all of it, it is the claimant company, not the agent, who is liable for repayment, plus potentially penalties of 25% (if the claim is deemed careless) and interest. Furthermore, the rejection of a project as qualifying R&D may result in earlier years’ returns being opened, where the monies received have been long spent.

It is only a matter of time until HMRC begin to target all claims of a particular type that have been submitted by ‘high-risk’ agents, using their own statistics to identify claims prepared where eligibility is suspect, boundaries between qualifying and non-qualifying work are not drawn correctly and where the costs claimed do not match the technical work carried out.

While this ‘weeding out’ process of ineligible claims is on-the-whole good news for genuine R&D performers, it is unfortunately accompanied by a greater likelihood of enquiries where, although work may genuinely qualify for the scheme, the claim has either not been correctly calculated with respect to the technology boundaries of the R&D project, or simply inadequately presented to the point where HMRC cannot see it.

[1] With the exception of Qualifying Indirect Activities which are outside the scope of discussion here