Just in time for Christmas (on 14th December, according to the email we got from them), HMRC has published new software case studies that clarify its position on what does and doesn’t qualify as software R&D. Naturally, given that many of GrantTree’s clients develop software, this has been of specific interest to us. Here are my thoughts on what the case studies say, and what impact they might have.
As usual with HMRC, it’s impossible to predict exactly how this will be used. HMRC is often unpredictable and inconsistent in its application of the CIRD (a natural, unfortunate consequence of operating on very limited resources). But there are some fairly obvious trends visible in this update, which are worth noting. Whether or not they are applied consistently and predictably, when it is being applied, this new guidance clearly goes in the direction of making software claims narrower and excluding things that were, in our experience, previously claimable.
The Russian Roulette Effect
Now, part of the difficulty in offering this advice is what I like to call the Russian Roulette effect. You see, HMRC doesn’t enquire into every claim (did I mention the unpredictability?). This can lead people who self-claim, or claim with their accountants, to build an overly rosy picture of what passes and what doesn’t. In fact, the unacknowledged (even by most accountants and specialists) reality of filing tax credits claims is that the vast majority of claims are barely glanced at. This means that egregiously wrong claims can frequently sail through. How frequently? Try six times out of seven, in some cases we observed. Almost like the empty chambers in a seven-shooter with one bullet in.
What happens when the chamber is loaded, if you’ve been claiming for things that don’t qualify for the last six years, can be quite uncomfortable to say the least. At best, a shattering of a comfortable illusion about how much was actually claimable, and how much cash can be relied on in the future. At worst (though we’ve not seen this happen except in cases where the claims were shamelessly boosted with obviously non-qualifying costs, or where the company was miscategorised as an SME), a reopening of previous claims and serious cash hit.
At GrantTree, we file many hundreds of software claims a year, so we don’t have the luxury of playing Russian Roulette. If we did, we’d take dozens of bullets every year. So, our advice is based on the perspective of minimising enquiries and ensuring that when there is an enquiry, we always win. This is how we maintain an enquiry rate well below 1% (and for the two enquiries we had in 2018, we won them with 98% and 100% of the respective costs accepted).
I’m sharing this to emphasise that if you’re making a claim for software, there’s a fair chance it will not be looked at in great detail, and so you may be tempted to think that the advice here is overly conservative. You’ll have to decide your own level of comfort with the Russian Roulette situation, and draw the line where you’re comfortable having it. The purpose of this article is to give some clarity about how HMRC might end up reacting, when they do eventually get around to looking at your claims – which may be ten years from now, or today.
Tighter Restrictions
The fairly clear direction of this update, then, is towards restrictiveness. Fewer costs are likely to qualify. More projects are likely to be rejected, particularly if they’re not presented or defended well enough.
In our experience, most HMRC inspectors are not software experts. Therefore, the way they are likely to apply the guidelines is first of all through pattern matching. So, for example, when a technical narrative includes discussion of benchmarking different tools for performance, it is likely to match against this example from case study 1:
Work undertaken to implement and test 3rd party certification systems for secure connection authentication was not considered to represent a technological advance (para 6), as it was not addressing a technological uncertainty in terms of the feasibility of having security certificates, or their practical implementation (para 13), but was carried out for the purposes of benchmarking performance of different commercial offerings only, rather than testing of baselining overall technological capability.
Does this mean that all performance benchmarking is now off limits? Well, not exactly. You see, in practice, benchmarking of third party tools is often not a very time consuming or central part of any R&D project. How long does it take to test which messaging queue you’re going to use? For most tech startups, this is an afternoon’s work – a tiny proportion of any claim. However, a sloppily written technical narrative might make the mistake of focusing on benchmarking as if it was a central part of the project (maybe because it’s one of the bits of “trial and error” that the CTO remembers while drafting the claim and it’s easy to write about).
What is time consuming in the world of “benchmarking” is doing deep performance optimisation work to meet technical requirements, which might result in a new messaging queue being installed after a bit of benchmarking, but might also include, for example, putting together a new, bespoke communications protocol that meets the unique needs of the product.
In this case, it’s all about the presentation. Our advice would be to avoid the word “benchmarking” if possible, which would pattern match to this case study.
Let’s take another tidbit:
The identification and assessment of existing generic ML solutions for potential deployment was not considered to be qualifying activity, as it did not seek to advance overall technological knowledge or capability (para 6) but was using existing technology (para 8 & CIRD81960 Section 2).
This is interesting. Traditionally, HMRC has been very clear about the extremes of what qualifies and doesn’t qualify. Developing a new way to do neural networks that results in academic papers and patents, for example, would be in the “clearly qualifying” box for HMRC. Downloading and installing WordPress, and customising it a bit, would be in the “clearly not qualifying” box.
All well and good. But in claims that we’ve seen, occasionally this gets muddled up when “AI stuff” is mentioned. HMRC is as vulnerable as VCs (if not more so) to being bamboozled with the latest technical mumbo jumbo to come out of the tech scene. One such vulnerability has been around “machine learning”. Machine learning sounds very technical and very fancy, and so has had a tendency to sail through even when enquired. That will probably no longer be the case, with ML frameworks now joining WordPress in the naughty corner.
This means that, for example, simply setting up Amazon ML, training it on a data set and integrating it into your application is not going to make your project qualify “because of machine learning”.
This doesn’t mean that everything to do with ML is now off limits. It does mean that a claim that centres around machine learning needs to be very clear about how it is different from just applying ML, and how it extends the state of the art of AI in some way, in order to be approved or to pass an enquiry.
Let’s look at a third bit, from case study 3:
Aspects concerning the optimal balancing of processing between the client and server to avoid overstretching mobile devices’ processing and battery capacity, or producing bottlenecks in the network, were not considered qualifying R&D activities, as these were viewed as design constraints (Para 41), and so did not contribute to resolving a technological uncertainty (Para 4, 13, 27c, CIRD81960 Section 2).
This is a more concerning update. Mobile device processing and battery capacity and network bottlenecks are very genuine technical constraints, not merely “design constraints”. “This technology needs to be good enough to run on a spotty 3G network” is not just a cosmetic consideration. If it is, then one must wonder about the DTI guidelines examples, which state:
D3. An advance in science or technology need not imply an absolute improvement in the performance of a process, material, device, product or service. For example, the existence of high-fidelity audio equipment does not prevent a project to create lower-performance equipment from being an advance in science or technology (for instance, if it incorporated technological improvements leading to lower cost through more efficient circuit design or speaker construction) (paragraph 9(d)).
Is lower cost a design constraint or a technical constraint? One wonders.
This last one is not yet resolved, so we’ll have to see how it plays out in actual cases. Chances are, HMRC will eventually adopt a reasonable position on this (otherwise they would invalidate most of the software world, where much R&D is based on meeting technical constraints, and we do not think that this is their intention).
It’s beyond the scope of a single article to delve exhaustively into these new case studies, but what we can say is that we will be spending at least part of the Christmas break poring over these new guidelines and squeezing as much learning as possible out of them, and we’ll be keeping our eyes out for any matching shifts in how HMRC handles enquiries over 2019 and beyond.
Quality versus expediency
HMRC’s new case studies do bring some welcome clarity as to what qualifies and what doesn’t. Some of this clarity will translate in improved best practice of how to write successful technical narratives. Some terms should be avoided or handled carefully to avoid pattern matching enquiries (i.e. enquiries based on recognising a term mentioned in the “not allowed” categories, rather than on a genuine mismatch). Other areas are now more clearly out of scope.
Overall, we believe the net effect of these case studies will be to raise the bar of how good a technical narrative needs to be to pass without enquiry, and make enquiries markedly more difficult to win.
Obviously, as a company, GrantTree has a self-interest in supporting better quality technical narratives – it’s one of our areas of expertise, after all. Working closely with HMRC as we do, we definitely want to promote a situation where claims pass not because they randomly win the Russian Roulette, but because they are engaged in genuine R&D that is presented in a way that HMRC can easily understand and approve efficiently with their limited resources.
That said, there is a balance between being overly demanding in terms of raising that bar (which imposes a cost on claiming companies), and the good that tax credits do by rewarding qualifying companies. Does this move raise the bar too high? We don’t think so. But time will tell of course.
In the meantime, it will come as no surprise that, given this latest move, we would advise all software companies considering making R&D claims to get some specialist advice and assistance in the process. The most likely effect of this change is that there are now two bullets in the software claim barrel.
