If your company is building with AI or large language models (LLMs), it's natural to wonder whether that work qualifies for the R&D tax credit. The credit is worth 30% of qualifying expenditure, rising to 35% for accounting periods ending on or after 31 December 2026, so the answer matters.
Some AI projects qualify and many don't, and the label “AI” makes no difference either way. Revenue's guidance on software R&D doesn't refer to AI or LLMs specifically, so the same science test applies to your project as to any other software work. Here's how that test plays out.
What does Revenue's science test say about software?
For any project to qualify, it has to be systematic, take place in a field of science or technology, seek an advance in the overall knowledge or capability of that field (not only your own company's), and involve resolving a scientific or technological uncertainty.
For software, Revenue quotes the OECD's Frascati Manual:
“for software development to be classified as R&D its completion must be dependent on the development of a scientific and/or technical advance.”
This essentially means that building an AI product isn't enough on its own. The question is whether you had to solve a technical problem that nobody could have told you the answer to in advance. Our guide to Revenue's definition of R&D covers each part of the test in more detail.
Where do AI projects usually fall short?
Revenue excludes “software developments using known methodologies in standard development environments”, along with routine analysis, copying, upgrading or adaptation of an existing product. Many AI projects fall into this category, because so much of the technology is now available off the shelf. The following typically don't qualify:
- Connecting a commercial LLM to your systems through an API
- Writing and refining prompts until the outputs are good enough
- Standard fine-tuning or retrieval set-ups using established methods and tools
- Adding an AI feature to a product that is to work
A model can be new to your company and still not be an advance in the field. If the difficulty is time, resources, effort or cost rather than a technical unknown, the work is routine development, however valuable it is to your business.
Where can AI and LLM projects qualify?
Revenue's guidance recognises the development of mathematical models or algorithms to achieve a functional goal as a possible source of uncertainty, and that's where qualifying AI work tends to sit. It might involve a new model architecture or training method, or hitting a hard performance target where published approaches and standard tools can't get you there, and where you didn't know at the start whether it could be done.
For example:
A Cork medtech company is developing a model to detect irregular heart rhythms from wearable sensor data. Published approaches and standard frameworks can't reach the accuracy it needs within the memory and power limits of the device, and the team doesn't know at the outset whether it's possible. Its engineers run a series of experiments on new model architectures, log the accuracy and memory use of each run against agreed targets, and record which approaches failed and why.
That project has a specific uncertainty, a systematic approach and a result that a competent professional couldn't have predicted.
However, in another example:
A Dublin logistics company connects a commercial LLM to its customer portal, writes prompts to handle common queries, and tests different wording until the answers are accurate enough. The tools are standard, the method is well known, and a competent professional would expect it to work.
That's routine development. It may be a good use of your budget, but it doesn't meet the science test.
What about the grey areas?
Fine-tuning a model on your own data or building a retrieval pipeline can go either way, depending on what happened during the project. If standard techniques worked, it's routine. If you hit a problem that known methods couldn't resolve, and you had to investigate systematically to solve it, the work on that problem could qualify.
Four questions help you decide:
- What could existing tools and published methods do when the project started?
- What specifically was uncertain?
- What did you try, and what happened?
- Why couldn't a competent professional have predicted the answer?
If you can answer all four with evidence, you're in a strong position.
How should you document an AI project?
Revenue expects detailed, dated records of your original goals, the progress of the work and your conclusions, and a claim can be disallowed if that documentation isn't kept. For AI work, useful records include:
- The baseline: which models, tools and published methods existed at the start, and how they performed
- Experiment logs: model versions, configurations, evaluation results and benchmark scores, including the failures
- Notes on why an approach was chosen or abandoned
- The names and experience of the people leading the technical work
Failed experiments are evidence too. A record of approaches that didn't work shows genuine uncertainty. Our guides to what records you need and what makes a good technical report show how to bring this together.
Which AI project costs can you claim?
Staff costs are usually the largest item. You can claim the proportion of an employee's emoluments that matches their time on qualifying R&D, and for accounting periods ending on or after 31 December 2026, you can claim 100% where they spend at least 95% of their time on it. Cloud computing costs, including the compute you use to train and test models, are allowable where they're incurred wholly and exclusively in carrying on qualifying R&D. If you outsource part of the work, the subcontracting caps apply. You can find more information on expenditure in our article on qualifying costs.
Revenue's guidance doesn't address costs such as API or token usage specifically. It's sensible to record them separately and apply the same wholly and exclusively test that applies to cloud computing. All of this is covered in our guide to software costs in your R&D claim.
Key takeaways
- The science test applies, not the AI label. Your project has to resolve a genuine technical uncertainty and advance the field, not just your own company.
- Standard use of off-the-shelf models is usually routine. API integrations, prompt writing and established fine-tuning methods typically don't qualify.
- Qualifying work tends to involve a real unknown. Examples include new architectures, training methods, or performance targets that existing approaches can't reach.
- Evidence makes the difference. Record the baseline, the experiments and the failures as you go.
- Costs follow the usual rules. Staff and cloud costs can qualify, and API or token costs should be tracked separately.
Working out whether an AI project meets the science test is one of the more judgement-heavy parts of building a claim. If you'd like help assessing your project and documenting it properly, get in touch and we'll walk you through it.
