Yes, building an AI tool can qualify for R&D tax relief or a research credit, but the label "AI" does not qualify it. The relevant work must meet the scheme's test for a technological advance or uncertainty and a documented attempt to resolve it. Routine prompts, integrations and configuration usually need a different treatment.
Start with the technical problem, not the project budget. Ask what a competent specialist could not readily work out at the outset, what alternatives the team tested, and where the experimental work stopped. A useful tool can be commercially valuable yet contain no qualifying research. A failed experiment can be more relevant than a successful routine deployment.
Why the product name is a poor eligibility test
"We built an AI assistant" can describe anything from joining two existing services to creating a genuinely new method of handling an unresolved technical constraint. Tax schemes assess activities, not marketing labels. A project may contain eligible experimental work, ordinary software engineering, user research, data cleaning, deployment, training and sales. One line on the project invoice should not sweep those different activities into a single claim.
In the UK's published R&D meaning guidelines, the sought advance must be in overall science or technology, not only in one company's own capability. The uncertainty must not be readily resolved by a competent professional in the field. The guidelines also distinguish routine copying, adaptation and optimisation from work that resolves a scientific or technological uncertainty. Those distinctions are more demanding than "new to our firm".
For a US research credit, the official Form 6765 instructions describe a four-part test for each business component: costs eligible to be treated as research or experimental expenditure under section 174A, research to discover technological information, an intended new or improved business component, and a process of experimentation relating to function, performance, reliability or quality. They impose additional conditions for software primarily used for internal administrative functions. Australia's software-sector guidance likewise warns that a technically difficult or commercially novel build is usually not a core R&D activity when known tools and methods can achieve the outcome. A hypothesis-driven experiment addressing an unknown technical outcome is the stronger signal.
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowRun an activity test before discussing money
| Question for the technical lead | Weak answer | Evidence worth examining |
|---|---|---|
| What exact capability was uncertain? | "We had never built an AI tool." | A specific performance or reliability obstacle that existing knowledge could not resolve. |
| What did a competent specialist know already? | "We did not know which vendor to choose." | Contemporaneous review of known methods and why they fell short. |
| What alternatives were tested? | "We tried several prompts until one looked good." | Planned methods, controlled tests, measurements and recorded conclusions. |
| Where did experiment become delivery? | "Every hour after the kick-off was R&D." | Dated boundary between uncertainty resolution and ordinary build or support. |
This is a triage table, not a legal definition. The project can fail one scheme while meeting another, and the precise cost rules also differ. A developer's unfamiliarity with an API is a training or implementation problem if a competent professional could follow established documentation. Customer uncertainty, such as whether clients will pay for the tool, is a business risk. Neither becomes technological uncertainty because the project used a model.
Illustrative negative example: an HR consultancy buys a standard applicant-tracking product, writes prompts to summarise CVs, connects an inbox and adjusts the output format after staff feedback. The work may need privacy, bias and accuracy controls, but those controls do not by themselves demonstrate a new technological advance. If the team's record consists of licence invoices and a screenshot of the finished workflow, the owner should budget this as implementation and ask a tax adviser before claiming anything.
A small-business build examined line by line
Consider an illustrative mortgage broker that wants an AI tool to extract figures from mixed scanned lender documents while preventing one client's data from contaminating another's output. A competent software specialist first tests existing document extraction and isolation patterns. The specialist documents that normal configuration meets the extraction target on clean files but fails a defined combination of poor scans, conflicting tables and strict isolation requirements. The team's proposed advance is a more reliable extraction-and-verification method for that class of documents, not simply "an AI broker assistant".
The team defines a test set of 120 consented or synthetic documents: 60 ordinary scans, 40 with altered table layouts and 20 with contradictory figures. The initial method correctly identifies the specified fields in 86 of 120 documents. Two alternative pipelines are designed before testing: one uses a layout-aware extraction stage and a second uses independent retrieval and rule-based validation. Each receives the same documents, target fields and scoring method. These numbers are illustrative experimental planning, not a claim that either method is novel or eligible.
Suppose the first alternative produces 99 correct documents but misattributes values in five of the contradictory cases. The second produces 105 correct documents and no cross-client retrieval in the controlled test, yet takes too long under the team's target latency. The team combines a constrained candidate-selection stage with independent verification and repeats the same evaluation. It records the exact versions, false matches, latency and failure cases. A reviewer can now see a technical question, alternatives, observations and a conclusion. Whether the work meets a particular tax scheme still requires expert judgement about the existing state of knowledge and each scheme's rules.
The project ledger shows 60 hours on investigation and controlled experiments, 110 hours on ordinary application integration, 30 hours on interface design, 25 hours on deployment and staff handover, plus a separate computing bill. At an illustrative internal cost of $75 per hour, those labour buckets are $4,500, $8,250, $2,250 and $1,875 respectively, totalling $16,875. The computing bill adds $600, making the project total $17,475. That is not the claim amount. The tax adviser must decide which activities and cost categories are allowed, which employees or contractors qualify, whether the computing cost is eligible, and whether any limits or exclusions apply.
The candidate research period might end when the technical uncertainty is resolved in week six even though the commercial product launches in week twelve. The remaining build can be essential to the business without being part of the experiment. Conversely, a later release may expose a genuinely new technical uncertainty; record it as a new question with its own start, tests and conclusion. Do not relabel ordinary bug fixes after launch as research solely to extend the period.
Five nearby builds with different answers
An interior design studio builds a moodboard generator by connecting an existing image service to a client portal. The owner spends 35 hours choosing prompts and another 20 hours arranging layouts. The tool is original to the studio, but the technical approach uses documented features. The owner should not infer R&D from the number of hours or the originality of the visual result. The no-code versus custom-build decision is a better first discussion for that project.
A financial adviser commissions a system that answers client questions using approved documents and cites the source passage. If the main task is installing a known retrieval pattern, the engineering may be routine. If the team faces a documented reliability obstacle no competent specialist can readily resolve with available methods, isolates that obstacle and tests genuinely different approaches, a subset may merit specialist review. Client-facing risk and regulated advice controls are vital, but risk alone is not evidence of a tax-qualifying experiment.
A bookkeeper uses AI to classify 2,000 historic supplier invoices. The business tests three standard prompts, picks the one with the fewest errors and then manually corrects the rest. That is a useful comparison for operations, but a prompt contest is not automatically a technological advance. The results measure which existing option suits this dataset. To argue otherwise, the technical lead would need to identify a field-level uncertainty and a method of investigation that goes beyond choosing from known configurations.
An HR consultancy tries to develop a privacy-preserving method that lets several client firms evaluate a shared model without exposing their underlying records. It documents why established approaches fail a stated technical target, designs two alternative protocols, records security and accuracy tests and shows what was learned when one method failed. This is a stronger candidate for assessment because it identifies a technical obstacle and experimental resolution. It is still only a candidate: the existence of published methods or the exact legal scheme may change the answer.
A mortgage broker pays a developer to connect a document upload screen, an existing OCR service and a CRM. The initial test fails because an API key was stored in the wrong environment. Fixing the configuration and rerunning the test does not turn the whole build into research. A meaningful project log would record that failure as a deployment defect, not call it a scientific uncertainty. Separating defects from experiments protects the credibility of the genuinely hard work.
Finally, suppose the broker's extraction experiment never meets its target and the project is stopped. That does not erase the earlier technical work. The UK guidelines recognise that an attempted advance may fail; Australian guidance likewise focuses on hypothesis, experiment, observation and conclusion. The team should preserve the failed test results and the decision to stop. Inventing a success narrative would be less useful than a candid record of why the proposed method did not work.
The UK question: advance beyond your own firm
A UK company considering relief should ask its technical lead to write a short field-specific explanation: what was known at project start, what overall technological capability it aimed to advance, why a competent professional could not readily deduce the answer, and what work attempted to resolve that uncertainty. The published expectations for claimants ask for those points. "Our first AI automation" answers none of them. An external developer's opinion should be tied to concrete methods and dates, rather than a sales promise that every AI build qualifies.
The same guidance distinguishes the wider commercial project from its experimental part. A team might seek to improve document extraction and also design a customer dashboard, buy licences, train staff and write marketing copy. Only the work that directly addresses the technological uncertainty, and certain defined indirect activities, is even in the R&D discussion. Keep a boundary record: "Uncertainty opened: 4 February; baseline test: 7 February; experimental variants: 11–26 February; result reviewed: 3 March; routine product build from 4 March." Dates are illustrative, but the boundary is essential.
The current UK claim process also needs an additional information form for each relevant accounting period, submitted before or on the same day as the company tax return, with the form first if both are sent on one day. As of November 2026, a recently announced simplification is future-dated: the claim-notification requirement is scheduled to end for claims made on or after 1 April 2027, while changes to the additional information form are due to take effect from autumn 2027. Do not apply a future rule to a current filing. Ask the company's tax adviser which notice and filing steps apply to its period and claim date.
The US and Australian questions differ
The US Form 6765 instructions require the research-credit tests to be considered for each business component. A business component can be a product, process or software, rather than the entire company's "AI programme". The instructions say internal-use software for general administrative functions faces an additional high-threshold-of-innovation test. A payroll, HR or finance assistant built for the firm may therefore need a different analysis from software developed for sale or for third-party interaction. A US tax professional should also assess qualified expenses, contract terms and the filing form; an owner should not apply a headline credit percentage to a developer invoice.
Australia's software development guide explicitly discusses AI. Its core R&D concept centres on an outcome that cannot be known or determined in advance and a systematic progression of hypothesis, experiment, observation, evaluation and conclusion. The guide cautions that applying established tools to a commercially novel task is generally routine. Supporting activities and expenditure have their own tests. A small firm should write the technical hurdle and experiment first, then ask a registered tax adviser to check entity, expenditure and registration requirements.
These three systems share a useful practical habit, but their legal tests are not interchangeable. A UK claim needs an advance in overall capability; a US internal-use tool can face extra conditions; Australian core activity requires a particular experimental progression. This is why a generic online calculator that asks only "How much did you spend on AI?" cannot determine a credit. Use the calculator, if at all, for budgeting after a specialist has established what activities and costs may qualify.
Keep evidence that existed during the build
Create a project folder before experiments start. Store the baseline of publicly known methods, design notes, dated hypotheses, test data provenance, evaluation rules, code versions, results, failures and conclusions. A retrospective paragraph written at year-end may be accurate, but it is weaker than dated records showing what the team knew before it tested anything. Preserve meeting notes where the technical lead explained why a standard solution failed. Save negative results as carefully as the winning run.
A filled-in illustrative log entry could read: "12 February; question: can the system isolate each client's records while retaining correct table extraction on poor scans? Existing approach: 86/120 correct; proposed alternative: independent candidate extraction plus validation; target: at least 105/120 correct with zero cross-client retrieval in test set; method: same 120 documents, fixed scoring sheet; outcome: 105/120, zero observed cross-client matches, latency above target; next test: reduce retrieval stage time." This is an operational record, not a conclusion that the activity qualifies for relief.
Alongside the technical log, keep timesheets or task records that allocate each person's time to named activities, supplier agreements, invoices, computing usage and accounting periods. A work item labelled "AI project" for 200 hours tells a reviewer little. Entries such as "six hours: evaluate extraction variant B against 40 altered tables" and "four hours: connect approved output to CRM" allow a tax adviser to separate the experimental and routine work. If a contractor performed the research, preserve who controlled it, who bore the risk and what the contract actually required.
For the mortgage-broker illustration, the experiment's 60 hours are not automatically a deductible or creditable $4,500. The team might have used a blended internal rate that differs from the tax scheme's allowable wage measure, and the cloud bill may contain production usage as well as test runs. The proper next calculation starts from eligible activity and legally permitted cost categories, then uses actual payroll and supplier records. Keep a column for "unresolved; adviser to decide" instead of pushing every ambiguous line into the claim total.
Ask your adviser a narrow, answerable question
Send the technical lead's two-page account, the activity log and the cost breakdown to a qualified tax adviser. Ask: "Which specific activities might meet the scheme's R&D test, what evidence is missing, where does the experimental period end, which costs are eligible, and what filing steps apply to this entity and period?" A specialist should challenge the baseline, not merely promise a percentage of the whole development budget. Ask them to document reasons for excluded work as well as included work.
AI can help arrange dated notes into a timeline and flag costs with no linked activity, provided the firm is authorised to share the records with the chosen service. It should not write a claim from a three-line project summary. A safer instruction is: "Using only these attached records, list each claimed technical uncertainty, the dated source that states it, each experiment and result, and any statement without a supporting record. Do not decide eligibility or invent missing tests." An illustrative output should say "No dated baseline found" if none exists. That gap is a task for the team, not a sentence for the model to fill.
For wider scoping, brief a developer on the exact workflow before paying for a build. The build-or-buy comparison helps decide whether custom work is justified; tax relief should never be the reason to build something a standard product already solves. If the team is testing a technical claim, a one-page project brief gives the owner a place to name the objective, measures and decision rights. Keep the tax evidence as a separate, dated layer.
Make a claim only after the technical story survives review
Before filing, read the proposed narrative against the raw record. Can the technical lead identify the field and the prior capability? Does every claimed uncertainty have a date before its experiment? Do the test results match the attachments? Are ordinary integration, user-interface work, data entry and staff handover separated from the candidate research? Does each expense map to a permitted activity and actual supporting document? If any answer is no, repair the record where truthful evidence exists or exclude the item. Do not create a retrospective test.
Some owners fear that recording failed methods will weaken a claim. In fact, failures may show the uncertainty and the process used to investigate it, while a story of effortless success can sound like routine implementation. The aim is a faithful account of what happened. If a competent specialist could have applied an established solution from the start, the project may still be a good commercial investment without R&D relief. Measure its business return separately using a worked AI return-on-investment calculation.
This is a practical screening method, not tax advice or an eligibility decision. The schemes, cost rules and filing requirements vary by jurisdiction and period. A business owner can make the review faster and more accurate by preserving the technical question, alternatives, results and cost boundaries as the work happens. A qualified tax adviser can then decide what, if anything, belongs in a claim.
AI project R&D claim questions
Does buying an AI subscription create an R&D tax claim?
Ordinary access to a subscription for everyday work is not evidence of qualifying research. A subscription or computing charge may need a separate cost analysis if it directly supported an eligible experiment, but that depends on the scheme and the records. Keep the invoice and a record of its actual experimental use; ask a qualified tax adviser before including any amount.
Can an unsuccessful AI experiment still be considered?
Potentially. The question is whether the work genuinely attempted to resolve a qualifying scientific or technological uncertainty using the process required by the relevant scheme. An experiment that fails can still show what was tested and learned. Preserve the initial hypothesis, dated test plan, results and conclusion rather than replacing the failure with a later success story.
Can I use ChatGPT to write the R&D claim narrative?
It can help organise records and draft plain-language summaries, but it cannot supply missing experiments or decide legal eligibility. Give it only material you are authorised to share, demand references to dated source records and have the technical lead and tax adviser verify every statement. A polished narrative unsupported by project evidence can make a weak claim harder to defend.
Further reads
- Can AI Help Prepare an R&D Tax Credit Claim? Narratives and Costs — Prepare claim narratives without inventing evidence.
- How Much Does a Custom AI Assistant Cost a Small Business? — Separate build cost from possible relief.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: GOV.UK, 'Meaning of research and development for tax purposes: guidelines', 'Expectations of claimants (part 2)', 'Additional information you must submit before you claim Research and Development tax relief', and 'Research and Development Tax Reliefs: improving the customer experience'; Internal Revenue Service, 'Instructions for Form 6765'; business.gov.au, 'Software development sector guide for the R&D Tax Incentive'. Checked 4 November 2026.