Avoiding the elephant traps when writing R&D reports

When making claims for R&D tax relief, most companies (or their advisors) will prepare a technical narrative to accompany the numbers. Ideally, this should give HMRC a clear idea of what the company is claiming for, and why it meets the criteria for relief.

Often, however, the company (or said advisor!) can fall into one of many elephant traps that are liberally sprinkled around the R&D tax credit landscape. We know that the last thing you need is to be looking up at the sky from the bottom of a dark pit (our metaphorical description of what it feels like to be facing an HMRC R&D enquiry), so have compiled this handy list of commonly made mistakes – and suggested how to solve them. Because we’re nice. And like elephants.

Trap Number 1 – Mixing up “research” with “research”.

Um, what now? Ok, I can see how this could be confusing. What we mean by this is that some companies confuse what is research for them with research as defined by HMRC’s guidelines (check out ‘HMRC CIRD81900’ for a fascinating ½ hour read).

Examples of this are companies writing things like “we’ve never done this before” or “it was difficult and required research because we didn’t know how to do this”.

The problem here is that the first question HMRC will ask is whether the company was operating outside its area of specialism. Just because they didn’t have the skills or experience to tackle the task, doesn’t mean that it is necessarily a challenge for the industry. An example of this could be an engineering company trying to claim for the development of a new IT system – they might be great at making shock absorbers, but lousy at software development.

So, if you find yourself writing ‘we didn’t know if we could do this’, be sure to explain why it was difficult and make it clear that you were operating within your sector of specialism (or if not, had at least engaged a competent professional able to recognise what is and isn’t R&D in the relevant field).

Trap Number 2 – Using the word ‘bespoke’

But wait, I hear you cry – ‘bespoke’ means unique, and unique means new, and new means eligible for R&D tax credits! Am I right?

Well, in some cases yes, but in many cases no.

The word ‘bespoke’ does indeed imply that the solution you developed is a one-off, but unfortunately that doesn’t necessarily make it eligible for R&D tax credits. Take the example of buying a bespoke suit – it’s beautiful, it’s fitted to you and only you, no other suit is exactly the same anywhere in the world.

The problem is that although the suit itself is a one-off, the process of making bespoke suits is well understood and carries no technical risk (in other words, there’s no ‘technical uncertainty’ associated with its production).

While this is a trivial example, the same principle can be applied to software projects. It’s common for companies commissioning a new IT system to think that because they’ve paid for the development of a system that’s exactly designed and configured to their specifications, that they can claim R&D tax credits for it. The issue here is that most often, the specification they set can be met by the IT company using existing techniques, methods and processes – so no R&D is involved at all!

Bottom line is, if you’re going to use the word bespoke, be prepared to explain which parts of the project or product advanced scientific knowledge. Being unique isn’t enough on its own!

Trap Number 3 – Get your boundaries right

We’ve seen some reports that are pretty expansive (or optimistic) about when R&D starts and stops. For example:

“The R&D began when the company first spoke to the client about the problem, and ended when the solution was implemented.”

Again, writing something like this is a red flag to HMRC’s Inspectors, who know that the early part of the project is likely to involve talking in more general terms about the project – its success criteria, costs and timings etc.

In contrast, the boundaries for R&D (for tax relief purposes) are defined as ‘when work to resolve the scientific or technological uncertainty starts’ and ends with ‘when that uncertainty is resolved or work to resolve it ceases’.  That’s a jargon-y way of saying that you must have met a significant new technical challenge in the project – and those challenges typically don’t pop up straight away (unless you’ve been specifically engaged to solve a problem that’s known to be R&D straight off the bat).

In summary, our advice is to be careful to show HMRC that you understand the start / stop conditions of R&D. A good way of doing this is to show in the report what the client did prior to any R&D, making it more obvious that the claimant is being respectful of the limits of the scheme.

Hungry for more? Read part 2 of our blog series: “Less is more – getting it right first time”.

Or find out more about writing a technical narrative and get some examples.