Here is real example from a recent R&D enquiry letter:
In order to satisfy our request, please ensure you provide enough evidence and narrative, in layman’s terms, to ensure we have the information requested relating to your R&D claim under the SME scheme.
Sometimes they won’t use that exact phrase, but instead will ask you to provide the information “in a form understandable to the non-expert,” which means the same thing.
The question is – how do you do this? After all, it’s not always easy to turn reams of technical project information into a form that HMRC’s happy with.
Here are some top tips for communicating what your client has done in the simplest possible way.
Acronyms are useful shorthand for those with experience, but it’s all too easy to assume that your reader understands what they mean – and HMRC often don’t. If you really do have to use an acronym (e.g. CHAP), make sure you define what the acronym stands for (e.g. Challenge-Handshake Authentication Protocol) and also provide an explanation of what that means (e.g. “CHAP is an authentication protocol used to validate users.”)
In a similar fashion, it’s a good idea to spot and replace informal terms that have a specific meaning to those in the know. For example, software developers will be so familiar with a term like ‘refactoring’ that they won’t bother to explain it (it means reviewing, reorganising and restructuring software to make it easier to understand or maintain). Replacing jargon with plain-English alternatives makes it easier for HMRC to work out what’s going on.
Related tool: De-jargonizer
Structure your response clearly.
The information that HMRC looks for in each and every enquiry is essentially the same. They want to know:
- What technology existed within the industry at the time of the project
- What aspect of this technology was your client trying to improve
- Which technical issues could not be resolved by using publicly available information, engaging external consultants, or by taking sensible, logical steps towards a solution.
If the information you give HMRC matches this structure, you make it much easier for them to understand what the client was trying to do.
Ask questions yourself
The chances are, if you don’t understand the information that your client’s provided, then HMRC won’t either. Don’t be afraid to ask your client to explain what’s going on in simpler terms. Keep doing that iteratively until you’re able to work out which terms are central to the explanation. Omit the rest.
Get someone else to read your report
A second pair of eyes can see things that the first took for granted – or missed entirely. Getting a separate, and independent, perspective on a project narrative can throw a spotlight on logical fallacies, red herrings, confusing statements and ambiguities. For our members, we offer this as part of our Claim Support service too. Removing these kinds of errors can make a significant difference to the readability of the claim – and therefore improve the chances that it will be processed without too many questions.
What to do next?
Plain English, layman’s terms, non-technical language – however you describe it, it’s essential that your responses to HMRC during an enquiry are as clear and concise as you can make them.
Using the same approach to your technical narrative or report in your INITIAL claim can also help reduce the risk of an enquiry. There’s more advice on specific steps to take and errors to avoid in our free Red Flag checklist.