Can AI Help Prepare an R&D Tax Credit Claim? Narratives and Costs

Yes, for drafting and cross-checking. AI can turn engineering notes into a first-draft technical narrative, flag gaps in the evidence and check a cost schedule for arithmetic and consistency. It cannot decide eligibility. A specialist must confirm the project meets the scheme's tests and sign off every figure before filing.

Claims go wrong in two places: a narrative that reads like marketing instead of describing a technical problem, and a cost schedule that cannot be traced back to payroll and invoices. Those are exactly the two jobs where an assistant saves hours, provided it works only from documents you give it and every output is checked by a person who knows the rules.

Follow me on Instagram@sagnikteaches

What stays with the specialist, and why

Research and development incentives differ between jurisdictions, and they change. Some schemes pay a credit against tax, some give an enhanced deduction, some let loss-making companies claim a cash payment. The tests for qualifying activity, the list of qualifying costs, the forms and the deadlines all differ. A model trained on text from everywhere will blend them. So the first rule is to name the scheme at the top of every prompt and to treat everything the assistant says about the rules as a question to verify against the official guidance.

Connect on LinkedInSagnik Bhattacharya

The common thread across schemes, in plain words, is this: the project tried to resolve a technical or scientific uncertainty that a competent professional in the field could not readily resolve with existing knowledge, using a systematic process of trying things, rather than just routine work. The US research credit spells this out as a four-part test, applied separately to each business component (a product, process, piece of software and so on): the spending must be research expenditure in the experimental or laboratory sense, meaning it aims at information that would remove uncertainty about the capability, method or design of a product; the work must rely on technological information; it must be meant to develop a new or improved business component; and substantially all of it must be a process of experimentation aimed at function, performance, reliability or quality. The UK scheme frames the same idea as seeking an advance in science or technology by resolving scientific or technological uncertainty. Which framework applies to you is for the specialist to say.

Subscribe on YouTube@sagnikteaches

Three decisions stay with the specialist whatever tool you use:

• Eligibility of each project. Does it meet the scheme's tests, and does the company's tax position allow the claim?
• Eligibility of each cost. Which staff, contractors and consumables count, and in what proportion?
• The final figures and the filing. The signature is a human one.

UK and US claims: one project, two different files

The two schemes most claimants ask about show how far the detail diverges once you move past the shared idea. The summary below comes from the official guidance and form instructions as read in November 2026. Use it as a map for the conversation with your specialist, not as a substitute for one.

Two practical consequences for AI drafting follow. First, paste the right headings into the prompt. For a UK claim, ask for exactly the form's fields (field, baseline, advance, uncertainties, how they were tackled) so the draft drops into the boxes the reviewer reads. For a US claim for a tax year beginning in 2026 or later, organise both the narrative and the cost schedule by business component, because that is how Section G reports them, and a schedule kept by department will need rebuilding. Second, never let a model carry a rule from one scheme, or one invoice, to another. "Apply 65% to contractors" may be right for one invoice and wrong for a connected contractor or for work done abroad. The specialist sets the treatment invoice by invoice. The guidance also notes that the UK claim notification will no longer be needed for claims made on or after 1 April 2027, a reminder that these details move and should be checked each year.

The workflow: evidence first, narrative second, costs third

1. Collect the raw evidence for each project: tickets, design notes, test logs, meeting notes, failed prototypes.
2. Extract uncertainties and attempts with AI, working only from those documents.
3. Draft the narrative from the extraction, in the structure the scheme's form expects.
4. Build the cost schedule from payroll and invoices, with AI used for cross-checks, not for choosing what counts.
5. Specialist review of eligibility, narrative and costs, with a written note.

Step two: pulling uncertainty out of project notes

Technical teams rarely write in claim language. Their notes say "switched to a different queue because latency spiked" or "tried three adhesives, two failed at 40 degrees". An assistant is good at turning these into a structured list of what was unknown, what was tried and what happened, while leaving out anything not in the notes.

Below are the project notes for one project at a furniture maker (CNC and finishing line).
Do not add anything that is not in the notes. Extract:
1. The technical problem or unknown, in one sentence each (what could not be worked out
   from existing knowledge)
2. Each attempt: what was tried, the date if given, the result
3. What was still unresolved at the end
4. Any statement in the notes that is routine work rather than an attempt to resolve an
   unknown (list separately)
5. What is missing from the notes that a reviewer would ask about
[notes pasted here, client and supplier names removed]

An illustrative output for a finishing-line project: unknown, "whether a water-based lacquer could cure evenly on oak without raising the grain at line speed"; attempts, "three formulations, tested on 12 panels each, results recorded in the batch log"; routine items, "ordering samples, cleaning the spray booth"; missing, "no record of the control panels or the cure temperature". What you fix: the unknown. Assistants sometimes state the unknown in a way that sounds scientific but is not what the notes describe. Compare it with the original and rewrite in the team's own terms.

Interview the engineer, then paste the transcript

Notes are often thin. A 20-minute recorded conversation with the lead engineer, with their agreement, produces richer material. Transcribe it, then ask the assistant to list every statement of "we didn't know whether" and "we tried". The engineer then reads the extraction and corrects it. This is how you find the sentence that makes the claim: "we had no idea whether the sensor would hold calibration after three hours at that temperature."

Step three: drafting the narrative

A narrative should be specific enough that it could only describe this project. Structure it the way the form or the specialist wants it, usually: the project's aim, the baseline (what existed or what was known), the uncertainty, the work done to resolve it, and the outcome including failures. Give the assistant the extraction, not the raw notes, so that every sentence has a source.

Write the technical narrative for this project in 350 to 450 words, plain and factual, third person.
Sections: Aim; Baseline; Technical uncertainty; Work carried out; Outcome.
Use only the extraction below. Do not use promotional language ("innovative",
"cutting edge", "novel") unless the extraction uses it. Where a section lacks evidence,
write [EVIDENCE NEEDED: what]. Do not state any figure not in the extraction.
[extraction pasted here]

A realistic first draft, illustrative: a tidy 400 words with two [EVIDENCE NEEDED] flags, such as "[EVIDENCE NEEDED: cure temperature for panels 5 to 8]". Those flags become a task list for the engineer. What you fix in the draft: any adjective that claims novelty, any sentence that says the problem was "complex" without saying why, and any outcome that sounds like success where the notes show a partial result. Honest narratives that admit what failed read as more credible than polished ones.

A before and after

Before (AI first pass): "The company developed an innovative finishing process that
significantly improved quality."
After (specialist edit): "The company did not know whether a water-based lacquer could cure
evenly on oak at line speed without raising the grain. Three formulations were tested on 12
panels each; two showed grain-raising above the accepted tolerance and were abandoned."

The second version names the unknown, the number of attempts and the result. Nothing in it is promotional, and every clause can be traced to a log.

Step four: the cost schedule and where AI checks it

Which costs qualify, and in what proportion, is a scheme question. Typical categories include staff costs for people working directly on the project, some share of contractor costs, and consumable materials used in the work, with scheme-specific rules on software, data and overheads. The specialist sets the rules; your job is to apply them consistently, and that is where AI helps with checks.

Build the schedule in a spreadsheet from payroll and invoices, with one row per person or supplier and a column for the source document. Then ask the assistant to audit it. Paste the table (with names replaced by staff codes) and the specialist's rules.

Here is a draft cost schedule and the rules the specialist has set (below).
Check and list, do not change:
1. Rows where the project percentage times the salary does not equal the claimed amount
2. Staff whose percentages across all projects add to more than 100
3. Rows with no source document reference
4. Supplier rows whose description sounds like general running costs, not project work
5. Totals that do not equal the sum of the rows
[table and rules pasted here]

A worked check, illustrative: a car repair garage's six-person team building a diagnostic tool. Engineer E3 has a salary cost of 54,000 and 40% allocated to the project, claimed at 21,600. That is correct. Engineer E5 has 60% on this project and 55% on another, a total of 115%. The check flags it. The specialist asks the manager, who confirms 45% on the second project, and the schedule is corrected before anyone files. A supplier row for "office broadband" is flagged as general running cost and the specialist removes it.

What you fix after the AI check: nothing automatically. The assistant lists issues, and a person decides. Models are unreliable with long arithmetic, so recompute totals in the spreadsheet itself and treat the assistant's maths as a prompt to look, not as a result.

Time records are the weak point

Many claims depend on estimates of how much time each person spent. A percentage with no record behind it is the first thing a reviewer questions. If timesheets are not kept per project, reconstruct the estimate from calendars, ticket histories and commit logs, ask each person to confirm their percentage in writing, and record how the estimate was made. AI can help summarise ticket histories into a per-person activity list, which the person then confirms. See AI time tracking for small teams for ways to capture hours going forward.

A worked claim: a small manufacturer, two projects, one deadline

Take an illustrative furniture maker with 18 staff and two projects in the year: the finishing-line process above, and a software tool that turns customer measurements into cutting lists. The accountant has set the filing date. Here is the plan.

Week one. The finance lead gathers batch logs, the engineer's notes and an exported ticket history. Two recorded conversations, each 20 minutes, with the finishing lead and the software developer. About 6 hours of internal time.

Week two. The assistant extracts uncertainties for each project. The engineers correct them, about 2 hours each. Missing evidence is listed: cure temperature records and a test log for the cutting-list tool.

Week three. Narratives drafted, about 400 words per project, edited by the finance lead and the engineers. Four [EVIDENCE NEEDED] flags become four documents requested. Cost schedule built; the AI check flags 7 issues, of which 5 are real.

Week four. The specialist reviews eligibility, rules out the cutting-list tool's quoting module as routine, trims two cost rows, and signs the review note. The claim is filed with time to spare.

A rough sum, illustrative: preparing both projects by hand might take 40 hours of internal time; with this workflow, 25 to 30. The saving is in extraction, first drafts and cross-checks. The specialist's review time does not shrink, and a clear evidence pack may make it shorter and so cheaper, though fees are for the adviser to set.

Rehearse the reviewer's questions before anyone else asks

Once the narrative and schedule are drafted, use the assistant as a hostile reader. A tax authority's enquiry letter is a list of questions; you can predict most of them. Paste the narrative and the cost summary and ask for the ten questions a sceptical reviewer would ask, then answer each from your evidence pack. Anything you cannot answer from a document in the pack is a gap to close before filing.

You are a sceptical reviewer of a research and development claim. Using only the narrative
and cost summary below, list the ten questions you would ask, most damaging first.
For each, say which document would answer it. Do not answer the questions yourself.
[narrative and cost summary pasted here]

Illustrative output for the finishing-line project: "What was the tolerance for grain raising, and who set it?"; "Which panels were control samples?"; "Why was a supplier's published cure guide not enough to resolve the question?"; "Which employees ran the trials, and what percentage of their time was it?" The third question is the sharpest, because it goes to whether the uncertainty was real. If the answer is that the supplier's guide covered oak at line speed, the project may not qualify, and you would rather learn that now than in an enquiry. That is a case for the specialist, not for the assistant.

Contractors, software and the costs people argue about

Three cost types cause most of the disputes, so give each its own line in the schedule and its own question for the specialist.

Contractors. Usually only part of a contractor's invoice counts, and it depends on who they are, whether they are connected to you and where the work is done (the table above shows the 65% figure both schemes use for unconnected contractors, and the conditions around it). Ask the assistant to produce a list of contractor invoices with a one-line description of the work and a column for whether the supplier is connected, then send the list to the specialist and let them decide the treatment. Never let the model apply a percentage itself.

Software and cloud costs. A tool used only for the project, such as a licence bought to run simulations, may be treated differently from the company's general email subscription. The UK scheme lists data licence and cloud computing costs as a category of their own; the US credit has a narrower line for certain rental or lease costs of computers located off your premises. The schedule should show the invoice, the project use and a note of how much was project-only. An online clothing store building a recommendation tool, for instance, would separate the cloud spend for training experiments from its normal website hosting.

Staff who split their time. The person who is half engineer and half support is the usual trouble. Ask for a written statement from the person and their manager describing what they did on the project, in the person's own words, and keep it with the schedule. The assistant can help turn a rambling email into a clean two-paragraph statement, which the person then checks and confirms is accurate.

Four small cases from other kinds of firm

A pest-control firm trialling a new monitoring trap. The notes show 14 weeks of field trials, with the sensor failing in cold conditions. The extraction picks out that failure as the uncertainty. The specialist later decides that the part of the work on routine installation scheduling does not qualify, and the narrative drops it.

A car repair garage building a diagnostic dashboard. The developer's notes are mostly Git commit messages. The assistant summarises 200 commits into six themes, and the developer confirms which two involved real unknowns (reading a vehicle's data reliably across model years) and which were routine screens.

A realistic mistake. A drafter asks the assistant to "make the narrative stronger". It adds that the new process "reduced scrap by 30%". Nothing in the notes says 30%. The reviewer catches it on the evidence check. Rule: never ask for stronger; ask for clearer, and forbid numbers not in the extraction.

A before and after for a cost row. Before: "Engineer time, development, 38,000". After: "Engineer E2, 55% of 69,000 salary and employer costs, finishing-line trials, 1 February to 30 June, timesheet export attached: 37,950". The specific row survives a question; the round figure does not.

Where AI-prepared claims fail

Generic narratives. A draft that could describe any firm's project is a warning sign. Add the numbers, dates, materials and names of things (without client names) that only your project has.

Overclaiming. Assistants like to describe work as "novel" or "groundbreaking". Strip it. Claims should describe the uncertainty, not advertise.

Invented evidence. If a draft cites a test result or a date that is not in the notes, delete it. Any "[EVIDENCE NEEDED]" that gets quietly filled with a plausible number is a serious defect.

Mixed rules. A model may blend two schemes in one answer. Always name the scheme, and have the specialist review any rule the assistant states.

Confidentiality. Project notes may be commercially sensitive. Use a business plan with training off, and remove client and supplier names before pasting.

The review note: what the specialist signs

Ask for a short written note per claim, kept with the file. It should record which projects were included and why, which were excluded and why, which cost categories were included, the basis for each time percentage, the version of the narrative approved, and the date and the person. If a tax authority later asks questions, the note shows that a qualified person made the decisions and what evidence supported them. If AI tools were used in drafting, say so in the file in a line; there is no shame in it, and a clean record of who verified what protects everyone.

For related reading, whether building an AI tool qualifies deals with a common claimant question, and tying a return back to source documents shows the same tie-out habit applied to tax workpapers. If narratives are your main time sink, using AI to write grant applications covers technical writing for funders. The AI hub lists the rest of the professional-services series.

How to check it worked

Judge the process on three measures after your first claim: how many hours of internal time it took compared with the previous year, how many questions the specialist raised about narratives and costs, and how many were about missing evidence rather than judgement. If most questions were about evidence, collect records earlier next year, during the project instead of after. If they were about wording, tighten your prompt's style rules. And if the tax authority asks questions after filing, note how long it took to find the supporting document for each answer. That is the real test of whether the evidence pack works.

Questions claimants ask about AI and R&D tax claims

Can AI decide whether a project qualifies?

No. Eligibility turns on the specific scheme's tests, the facts of the project and the tax position of the company. AI can line a project's notes up against a checklist of the tests and show where evidence is thin, but a qualified specialist makes the call and carries the responsibility.

Is it safe to paste project notes into a chatbot?

Project notes often contain unpublished technical detail and client names. Use a business plan that does not train on your content, remove client and supplier names, and check whether any contract or non-disclosure agreement limits sharing. Keep the original notes in your own records.

Will tax authorities accept AI-written narratives?

They look at the content, not the tool, but unsupported or generic narratives draw questions. A narrative must describe real uncertainty, real attempts and real people. If an AI draft could describe any company's project, it is not specific enough to file.

What records should I keep for an AI-assisted claim?

Keep the original project notes, the timesheets or time estimates, the cost schedule with its sources, the specialist's review note and each narrative version. A reviewer should be able to trace every figure and statement back to a dated source document.

Do claims work the same way everywhere?

No. Schemes differ in how qualifying activity is defined, which costs count, what forms are needed and how the benefit is delivered. Always use the guidance for the jurisdiction where the company files, and have a specialist for that jurisdiction review the claim.

Further reads

• AI for UK Tax Advisers: Research Notes, Client Letters and Checks — How tax advisers use AI for research notes and letters.
• Can AI Do My Business Taxes? What It Can Safely Prepare — What AI can safely prepare for business taxes.
• How Accountants Use AI to Spot Errors in Client Books — Using AI to spot errors in client books.
• Construction Job Costing With AI: Find Which Jobs Actually Made Money — Job costing from time records, a close cousin of project costing.
• How to Back Up Every Claim AI Writes in Your Marketing — A method for backing every AI-written claim with evidence.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Instructions for Form 6765 (December 2025 revision: four-part test, qualified research expenses, Section G) and the regulation defining research expenditure in the experimental sense; official guidance on the UK merged scheme and enhanced support, qualifying costs, claim notification and the additional information form. All read 4 November 2026. Check the current guidance for your jurisdiction before filing.