The Additional Information Form (AIF) is the gate between your company's qualifying R&D work and the relief you can claim on your Corporation Tax return. Without a valid AIF submitted to HMRC first, the claim is removed. This guide walks through every section of the form, explains what HMRC is looking for in plain terms, and works through a software project example so you can see the difference between a narrative that holds up and one that does not.
What the AIF is, and why it is not optional
The Additional Information Form is a detailed submission that must reach HMRC before the R&D claim on the CT600. Claims filed without a valid AIF are removed by HMRC. The form is therefore the gate to any relief, not a supplementary document you attach afterwards.
HMRC introduced the mandatory AIF to address the volume of low-quality and non-qualifying claims that grew in previous years. The effect is that you must articulate the qualifying nature of your R&D work in structured form before the financial claim is processed. A weak claim does not get corrected; it gets removed.
The AIF is submitted online through the HMRC portal. You will need your company's Corporation Tax reference and, if you use an agent, their details. The form is separate from the CT600 itself.
Where the AIF sits in the R&D claims process
For first-time claimants (and anyone who has not claimed in the prior three years), there is a step before the AIF. You must file a claim notification within 6 months of the end of the accounting period. Missing that window makes the claim invalid regardless of the AIF. If this is your first claim, check that deadline before anything else. See the companion guide on the 6-month notification deadline for the full process.
Once notification is in place (or confirmed as not required for a repeat claimant), the sequence is:
- Submit the AIF through the HMRC portal.
- File the CT600 with the R&D claim box completed.
The AIF must come first. Filing in the wrong order results in the claim being removed.
| Step | What it is | Deadline |
|---|---|---|
| 1. Claim notification | Tells HMRC you intend to claim (first-time claimants only) | Within 6 months of the accounting period end |
| 2. AIF | Detailed project and cost information submitted to HMRC | Before the CT600 claim |
| 3. CT600 R&D claim | The financial claim on your Corporation Tax return | Standard CT600 filing deadline |
For more on how the claim sits inside the wider R&D framework, see the merged R&D scheme explained and the ERIS route for R&D-intensive loss-making SMEs.
What HMRC asks for, section by section
The AIF has several distinct sections. Each has a specific purpose. Treating them as a single free-text box is one of the most common reasons an AIF fails to support the claim properly.
Contact and agent details
Your company details, Corporation Tax Unique Taxpayer Reference, and (if applicable) your agent's name, address and agent reference. This section is administrative. Get it right but do not confuse it with the substance of the form.
Project descriptions
For each R&D project you are claiming for, you provide a structured narrative. HMRC wants to understand: what advance in science or technology the project was seeking, what the baseline state of knowledge was at the start, what specific scientific or technological uncertainties arose, and how you attempted to resolve them. Each project gets its own narrative. If you have multiple projects, you must describe each one separately.
The advance in science or technology
This is the qualifying test in HMRC's R&D manual. Your project must seek an advance in overall knowledge or capability in a field of science or technology, not just an advance for your company. The distinction matters. Implementing a known technique in a new context is not an advance. Developing a technique that did not previously exist, or combining existing knowledge in a way that was not previously known to work, can be.
The technological uncertainty
You must identify the specific uncertainty that a competent professional in the field could not readily resolve using existing knowledge. This framing is precise and deliberate. The test is not whether it was hard for your team; it is whether someone who knew the field well would have found the answer readily available. If the answer was in a textbook, a framework's documentation, or a Stack Overflow thread, it is not a qualifying uncertainty.
Qualifying cost breakdown
The AIF requires a breakdown of your qualifying costs by category: staff costs (salary, employer NIC, pension contributions for employees directly engaged in R&D), subcontractor costs, consumables, and cloud computing costs. You do not need to submit payroll schedules at AIF stage, but the figures must be supportable. Confirm detailed apportionment rules for your specific cost mix with us before filing, as the rules differ between cost types and between the merged scheme and ERIS.
AIF section-by-section checklist
| AIF section | What HMRC wants | Common pitfall |
|---|---|---|
| Contact and agent details | Company UTR, registered name, agent reference if applicable | Using the wrong UTR or omitting agent details when an agent is filing |
| Project name and description | A plain label and a brief summary of what the project was trying to achieve technically | Describing the product or feature rather than the underlying technical work |
| Advance in science or technology | The specific advance in overall knowledge or capability being sought | Framing the advance as "new to us" rather than as an advance in the field |
| Baseline state of knowledge | What was already known at the start; why the advance was not already available | Skipping this section, which makes the uncertainty claim unsupportable |
| Technological uncertainty | The specific uncertainty a competent professional could not readily resolve | Describing integration complexity or project risk rather than scientific/technical uncertainty |
| Resolution attempt | What you tried, including what did not work | Describing only the successful outcome; HMRC expects to see the investigative process |
| Qualifying cost breakdown | Staff, subcontractors, consumables and cloud costs apportioned to R&D | Including non-qualifying costs (e.g., marketing, product management time) in staff apportionment |
How to describe a software project so it reads as genuine R&D
Most software companies face the same structural problem on the AIF. The work that qualified as R&D (the technical investigation, the failed attempts, the uncertainty) happened months before anyone thought about the tax claim. By the time the AIF is being drafted, what people remember is the shipped feature, not the process of figuring out how to build it.
HMRC's test, set out in CIRD100000, requires an advance in science or technology and a technological uncertainty that a competent professional could not readily resolve. Routine software development does not qualify. That phrase is doing a lot of work.
What routinely does not qualify for a software project:
- Integrating third-party APIs using published documentation
- Building UI components or product features using established frameworks
- Choosing between off-the-shelf solutions or configuring known software
- Performance tuning within known parameters
- Bug fixing on known software behaviour
What can qualify:
- Developing a novel algorithm where the computational approach was not previously known to work at the required scale or accuracy
- Solving a problem in distributed systems where no existing technique could reliably handle the failure modes you faced
- Developing a new machine-learning approach where the architecture or training method was genuinely experimental and the outcome uncertain to a competent professional
- Combining existing techniques in a way that was not documented to work in your specific technical context
The honest framing in the AIF is not "we built X". It is "we sought to advance the state of knowledge in area Y, the baseline was Z, the specific uncertainty was A, and here is what we tried and what we found." See also the guide on software R&D eligibility in detail.
Worked example: an AIF project narrative for a software company
This example is illustrative. It shows the structure and framing HMRC expects, not a template to be copied verbatim. Your narrative must reflect your actual project.
Project name: Real-time anomaly detection engine for distributed event streams
Advance sought: The project sought to advance the state of knowledge in statistical anomaly detection applied to high-velocity, schema-variable event streams. Existing published techniques for real-time anomaly detection assumed fixed schema and moderate data velocity. Our stream involved events whose schema changed dynamically and arrived at sustained rates that exceeded the throughput bounds documented for existing open-source implementations.
Baseline state of knowledge: At the outset, available anomaly detection libraries (including well-documented open-source implementations) operated on fixed schemas and had published throughput ceilings that were below our target operating parameters by an order of magnitude. No published technique addressed the combination of schema variability and the required throughput simultaneously.
Technological uncertainty: It was uncertain whether a sliding-window statistical model could be adapted to handle dynamic schema changes without model retraining, and whether the adapted model could sustain the required throughput without unacceptable false-positive rates. A competent professional in statistical data processing could not have determined in advance whether this combination was achievable within the latency and accuracy constraints we needed, because it had not been demonstrated in the literature or in production systems we could reference.
Resolution attempts: We first trialled a fixed-schema model with a schema-mapping layer. This produced unacceptable false-positive rates when schema changes were rapid. We then developed a lightweight schema-fingerprinting mechanism that allowed the model to treat schema changes as a signal variable rather than an error condition. This required a novel adaptation of the base model's feature vector, which was not documented in prior work. We iterated through four model variants, two of which failed to meet throughput targets, before the fourth variant met both the throughput and accuracy requirements. The work involved genuine scientific and technical uncertainty throughout and was not derivable from existing documentation.
Cost apportionment in the AIF
The AIF requires you to attribute qualifying costs to R&D activity by category. At a high level, the categories are:
- Staff costs: Salary, employer NIC and pension contributions for employees directly and actively engaged in R&D. Where a staff member splits their time between R&D and other work, only the R&D proportion counts.
- Subcontractor costs: Payments to external parties carrying out R&D work on your behalf. The qualifying rules differ between the merged scheme and ERIS, and between connected and unconnected subcontractors. Confirm your specific position with us before including subcontractor costs.
- Consumables and cloud computing: Materials consumed in R&D, and cloud computing costs attributable to R&D activity. Cloud costs became qualifying under the merged scheme; confirm the apportionment approach for your infrastructure.
The AIF does not require payroll schedules or invoice lists at submission stage. But the figures you enter must be supportable if HMRC opens an enquiry. Maintain the underlying records (timesheets, payroll reports, cloud billing exports, subcontractor agreements) before filing, not after.
Detailed apportionment percentages and caps (particularly for subcontractors and split-role staff) are fact-specific. Confirm the right approach for your cost mix with our R&D claims service before finalising the AIF figures.
Common AIF mistakes that get claims removed or queried
These are the patterns that cause the most damage, either by triggering an HMRC enquiry or by resulting in the claim being removed entirely.
- Filing the CT600 before the AIF. HMRC removes the claim. The AIF must arrive first, not simultaneously.
- Describing product features instead of technical uncertainty. "We built a recommendation engine" is a product description. "We sought to advance the accuracy of collaborative filtering under sparse data conditions, where existing techniques produced unacceptable cold-start error rates" is a technical description of an advance and an uncertainty.
- Treating project risk as technological uncertainty. Budget overruns, schedule slippage and market risk are not technological uncertainty in HMRC's sense. The uncertainty must be scientific or technological.
- Including routine development costs in the staff apportionment. Product management, UX design, content work and testing of known functionality are not qualifying activities. Attributing a full engineering headcount to R&D when only a fraction of their time was on qualifying work will not survive an enquiry.
- One narrative for multiple distinct projects. If you worked on two or three genuinely separate R&D workstreams, each needs its own narrative. Bundling them into a single vague description makes it harder to defend any of them.
- Omitting failed attempts. HMRC expects to see the investigative process, including what did not work. A narrative that describes only success reads as a product description, not a scientific investigation.
If you are preparing your first AIF or if a previous claim has been queried, the right point to get input is before the AIF is submitted, not after. The R&D claims service covers AIF preparation as part of the claim process. To pin down which of your workstreams generate qualifying costs in the first place, read software R&D eligibility: what qualifies.