R&D tax credits: Gathering project information for the new Additional Information Form

If you work in the field of R&D tax credit claims, you’ll be aware that HMRC have brought in the new Additional Information Form online as part of the claim submission. As of tomorrow (8th August 2023) this will be compulsory for all new claims.

In this article, I go through the information required by the form, particularly focussing on the project details, and as this can be particularly tricky – I highlight a few cautionary things to be aware of, and also outline how I and my colleagues at Articulate R&D can help in this specialist area in getting and articulating the relevant information in the most robust way for your claims.

Overview

The aim of HMRC, no doubt, is to attempt to bring consistency to claim submissions and capture a base level of information to make claims easier to assess. From the claimant’s side, it does impose an additional step, and for some claimants and their accountants / agents, the level of detail and coverage is new – but if the result is that long-term a claimant can be more confident that they have provided the right information and appropriate level of justification, then the principle is a positive one.

It is worth noting that you can partially complete and come back to the form multiple times. But it is time-limited, and arguably isn’t the most appropriate way to be sharing information and collaborating with the claimant as you collate and articulate the information. You may choose to produce and share a report with your client for this purpose, which also means that you have a record of the details of the submission ongoing – I would certainly suggest doing this.

Claim information

In the form, there is some basic information about the claimant business including UTR, PAYE reference, VAT number and SIC codes, as well as contact and agent details. Then there is information relating the accounting period, the scheme being claimed against (SME and/or RDEC), qualifying expenditure and qualifying indirect activities. I won’t go into detail around this here as we are focussing on the project details in this article.

Project details

HMRC want details of between three and ten of the largest projects being claimed for, covering at least 50% of the expenditure. Of course, if just one or two projects are being claimed for by a company, then details will need to be provided for just these.

On the face of it, having these questions defined for us by HMRC is great – it would seem that they have already given us a set of questions to ask the competent professionals (lead scientists, engineers, software developers, etc.) However, qualifying the projects, activities and other costs associated with each project, and capturing the project details is often not straightforward. With the rules of the scheme, including what does and doesn’t come under the definitions of what R&D is for tax purposes, defined in the BEIS Guidelines and using definitions from the CIRD manual, capturing and documenting the right things to an appropriate level of detail in terms that HMRC will want to hear is not always easy or intuitive. Getting all the relevant details can require some industry-specific conversations with the experts themselves about the nuances of the industry and their work.

The following are the questions that the form requires for each project:

Main field of science or technology: This should be relatively specific, and not be in one of the fields that are excluded in the BEIS Guidelines (e.g. social sciences). For example, “software” is arguably too vague – something like “software / single-page web application development” would be better. Caution: If the field of science or technology is not the claimant company’s own industry, be sure to state the area of advance rather than the claimant’s own industry (e.g. if they are an book ecommerce retailer and have made an advance in ecommerce, the advance in technology isn’t in the field of “book retailing”, but within “ecommerce software”).

Industry baseline: This is what the current state of science or technology was before the R&D was undertaken. As you will later be justifying that the project advanced science or technology, you need to outline what the project was advancing upon. How did competent professionals within this field do things before the advance was sought? Caution: This needs to be the baseline in science or technology. It is common to hear about commercial baselines, e.g. “no one else has developed an ecommerce application doing these things within the book retail industry” – because the advance needs to be in science or technology, the fact that something might be commercially new doesn’t necessarily mean that it requires anything new in science or technology. It is important to ask the right questions to focus the answers in the right area.

Advance in science or technology: This is what the project sought to advance. Paragraphs 6 and 9 of the BEIS Guidelines define and advance, and talk about the four different types of advance that are recognised. A description of the advance should be quite specific – for example, a statement that it was “an advance in software” is too vague – “an advance in single-page web app development through the development of a new architectural approach and framework” would be better. Be very careful to make sure it is articulated in a way that makes it clear that it is an overall advance and not just an advance in knowledge or capability for the company. Caution: This can be tricky to articulate.  It is common to hear of commercial advances (what it is that the project advances) – e.g. “no one has developed a web app that does thing in our industry before” – this would suggest a novel product, but doesn’t say anything about the underlying technology. Mentioning this is vital to point towards the underlying advance in science or technical.

Scientific or technological uncertainties: These are the moments of significant head-scratching that the competent professionals could not overcome using standard approaches, method and tools. It has to go over the bar of what would be considered routine or readily deducible (i.e. it took some thought but could be figured out using standard approaches by others competent professionals in that field). Caution: It is common to hear about non-scientific or technical uncertainties, and it is important to filter these out. For example, things that often come out that wouldn’t qualify as R&D might be understanding requirements for a project and documenting them (even if there is complex business logic that needs to be thought through), design consideration, prototyping for user testing or commercial viability testing. There can be an art in asking the right questions, teasing out the relevant uncertainties of the competent professionals who are in a particular industry or field of science or technology to a relevant level of detail, with some understanding of that industry being very helpful.

How the project sought to overcome the uncertainties: This explains how the competent professionals attempted to resolve the uncertainties described above. This should be sufficient to get across the steps taken and demonstrate that it was not readily deducible by a competent professional in the field (i.e. not just the scientists or engineers at the company, but also against their comparable experienced and qualified colleagues in the industry). Caution: It is common to hear that the competent professionals sought to “resolve uncertainty A by implementing solution Z” – but that does not say anything about why they implemented Z, what process they followed to achieve Z, challenges along the way, what worked and didn’t work, etc. It is better to have something more along the lines of “we encountered uncertainty A, so followed the step B which failed due to C, then attempted step D which resulted in E … all of which led to the result of Z” – this explains the process by which the competent professionals sought to resolve the uncertainty, not just the uncertainty and the eventual solution.

Getting support for completing the project details – how we at Articulate R&D can help

This is where we can help. Articulate R&D was born out by us a group of experienced industry professional each with years of experience in R&D claims and supporting many hundreds of claims – with a mission to support the R&D claim process by capturing and documenting project details from claimants. We do this by supporting accountants and R&D specialist firms as they work on claims with their clients. We typically work with and ask the claimant’s lead scientists and engineers the right questions to get to the nub of the R&D efficiently, helping to ascertain what is and isn’t qualifying R&D based on the HMRC’s guidelines, and articulating right information the most robust way to include in the claim submission. We also support HMRC enquiries, gathering further details from the competent professionals and re-presenting the information as the HMRC require it. Our experience covers software (software product and service companies, digital agencies, companies developing systems to support their business), engineering, architecture, product development and construction. We are always happy to have a chat to see if and where we can help.

Philip Clarke
Philip Clarke
Articles: 5