Does Artificial Intelligence Qualify for the R&D Tax Incentive?
Can AI development qualify for the R&D Tax Incentive?
Yes. Artificial intelligence and machine learning development can
qualify for the Australian R&D Tax Incentive, but using AI does not make an
activity R&D by itself.
The important question is whether you were trying to resolve a genuine technical
problem where the outcome could not be determined in advance from the knowledge,
information and experience reasonably available at the time.
If a competent professional could determine the outcome using existing methods,
documentation, published research or other reasonably accessible knowledge and
tools, it is much harder to argue that the activity was a core R&D activity.
I see a lot of companies doing genuinely impressive things with AI.
That doesn’t automatically make the work R&D.
A company might build a completely new product using machine learning, large
language models, Claude, ChatGPT, Codex or its own AI agents. The product might be
difficult to build and unlike anything the company has built before.
I would still pull the project apart.
Which parts involved a technical outcome that genuinely could not be worked out
beforehand? Which parts were normal software development? What did the team
actually test? And what evidence exists showing what they knew at the time?
That is normally where the real R&D claim starts.
What do the R&D Tax Incentive rules require?
Under
section 355-25 of the Income Tax Assessment Act 1997,
a core R&D activity must be an experimental activity whose outcome cannot
be known or determined in advance on the basis of current knowledge,
information or experience.
The outcome must instead be determined through a systematic progression of work
based on established science that proceeds from hypothesis to experiment,
observation and evaluation and leads to logical conclusions.
The activity must also be conducted for the purpose of generating new knowledge.
AI does not have a separate R&D test.
The Department of Industry, Science and Resources now provides
specific guidance for AI-related activities
as well as a
software development sector guide,
but the underlying legislative test remains the same.
The technology can be new. The product can be new. The way your company uses it
can be new. None of those things, by themselves, establish that the activity was
R&D.
What does this mean for an AI or software company in practice?
I would start with the technical hurdle, not the product.
What specifically stopped the development team progressing using existing
knowledge?
Then I would ask what a competent professional in that field could reasonably
have known or worked out at the time.
That distinction is particularly important with AI because the technology moves
so quickly.
Something that was genuinely difficult to determine six months ago might now be
solved by a published paper, a new model, an open-source library or a prompt to
Claude or Codex.
You have to assess the activity using the knowledge that was reasonably available
when the work was being done. You should not assess a 2025 experiment using
knowledge that only became readily available in 2026.
What does strong AI R&D look like?
Potentially stronger R&D
A company has a measurable performance problem that existing AI models,
published approaches and known methods cannot resolve.
The technical team establishes a baseline, develops a hypothesis about a
different architecture, training method or algorithm, conducts controlled
experiments and objectively measures the results.
The answer is not known before the experiments are conducted.
Usually weak as a core R&D activity
A company connects an existing language model to its software through an API,
configures the available settings and adjusts prompts until the outputs are
commercially acceptable.
The work may require considerable development effort, but the implementation
uses known tools and established approaches.
Difficult implementation is not the same thing as an unknown technical
outcome.
Potentially stronger R&D
An AI company needs to improve a model from a defined baseline but established
fine-tuning methods have failed.
The team proposes a different technical approach whose performance cannot
reasonably be predicted and tests it against a predefined dataset and
objective performance measures.
Usually weak as a core R&D activity
A team changes learning rates, prompts, model settings or other parameters
using recognised optimisation techniques where the expected effect of those
changes is already understood.
Trying several settings to find the best one is not necessarily an R&D
experiment.
For AI claims, I look for numbers
With AI claims, one of the first things I look for is something quantitative.
Show me the baseline. Show me what you changed. Then show me what
objectively happened.
AI development can become subjective very quickly.
Saying that a new model was “better”, that the output was “more useful”, or that
users preferred it tells me very little about whether there was a genuine
experimental activity.
A much stronger technical record might show:
- a baseline accuracy, latency, precision, recall, error rate or other relevant
performance measure; - a clearly defined technical limitation;
- a hypothesis about how that limitation may be overcome;
- a deliberate change to an algorithm, architecture, model or methodology;
- a controlled method for testing the change;
- quantitative results produced under comparable conditions; and
- a conclusion based on those results.
The particular measure will depend on the technology. What matters is that the
experiment is capable of producing an objective result.
If nobody can tell me what the starting point was or objectively demonstrate what
changed, I normally start asking more questions.
Questions I would ask your CTO
- What exact technical problem couldn’t you solve using the existing approaches?
- What did you search for before deciding an experiment was necessary?
- What would a competent specialist in this area have known at the time?
- What could the available AI tools help you determine at the time?
- What was your hypothesis?
- What did you deliberately change?
- What result were you measuring?
- What was the baseline?
- What happened when you ran the experiment?
- What did you learn that you did not know beforehand?
If those questions have clear answers, there may be something worth investigating.
If the discussion keeps coming back to how many hours the developers worked, how
difficult the coding was or how new the product is, I would be more cautious.
What if you built the software using ChatGPT, Claude or Codex?
Using ChatGPT, Claude, Codex or another AI coding tool does not automatically
qualify or disqualify software development from the R&D Tax Incentive.
But these tools can affect an important part of the analysis.
The question remains whether a competent professional could know or determine the
outcome using the knowledge, information and experience reasonably available at
the relevant time.
If a developer struggles with a problem for three days and then puts the same
problem into Claude or Codex and receives a workable solution in a few minutes,
I would start asking whether the knowledge needed to solve the problem was
already reasonably accessible.
An experienced developer would reasonably be expected to be aware of major tools
relevant to their field and consider whether those tools could help resolve the
problem.
If an AI coding tool can readily produce a workable solution using existing
knowledge, I would treat that as a strong reason to examine whether a competent
professional could already have determined the outcome without the claimed
experiment.
That does not mean AI-assisted development can never contain R&D.
It means AI is increasingly part of the technical environment that needs to be
considered when assessing what knowledge was reasonably accessible at the time.
An impressive AI-built platform can still be a weak R&D claim
I spoke to a business owner who had built a substantial internal software platform
himself using Claude, Codex, Gemini and local AI agents.
It handled a huge range of functions across the business. CRM, job management,
customer information, call processing and other operational systems.
It was impressive.
But that wasn’t the R&D test.
I started pulling the platform apart.
Call transcription already exists. CRM systems already exist. Automated business
workflows already exist. The fact that one person had combined these functions
into a new system did not make the whole development project R&D.
There may have been individual technical elements worth investigating further.
But those elements needed to be identified separately and assessed against the
R&D requirements.
There was another issue as well.
Even where some technically eligible activity may exist, the resulting claim still
needs to make commercial sense.
Sometimes the useful advice is to claim less.
Sometimes it is not to claim at all.
Is using off-the-shelf AI part of R&D?
Using an existing AI model or tool is generally not a core R&D activity simply
because it is new to your business.
But I often see off-the-shelf AI used before the genuinely interesting technical
work starts.
A company implements an existing model. It gets most of the way there, but hits a
technical limitation that the available system cannot overcome.
That limitation may lead to a separate experimental activity.
For example, the company may need to develop or materially adapt its own
architecture, algorithm, retrieval method, training approach or model because the
available approaches cannot achieve the required technical performance.
The earlier use of off-the-shelf AI does not automatically become eligible
R&D.
An activity that is not itself a core R&D activity may qualify as a
supporting R&D activity where it satisfies the requirements in section
355-30 and is sufficiently related to an eligible core R&D activity.
AI moves fast. Your evidence needs to show what was known at the time.
I think this is going to become increasingly important in AI claims.
A technical team might spend a year working on a problem for which no known
solution exists. Then, a month after they finish, a new paper, model or
open-source implementation solves essentially the same problem.
Someone reviewing the claim later can search for the answer and find it
immediately.
But that doesn’t tell you whether the answer was available when the company
started the experiment.
Current government guidance says the assessment should consider knowledge,
information or experience that was publicly available or reasonably accessible
anywhere in the world at the time the activity commenced.
See the government guidance on
conducting core R&D activities.
This is why contemporaneous records matter so much with AI.
I want to be able to reconstruct what the technical team knew at the time, what
they searched for, what tools were available and why they concluded an
experiment was needed.
What evidence should an AI company keep?
You do not need to manufacture an R&D document after the event if the
technical team already has good development records.
In software and AI businesses, useful contemporaneous evidence can already exist
across the normal development environment.
Before the experiment
- technical research;
- papers and documentation reviewed;
- comparison of available models or architectures;
- GitHub or open-source research;
- technical forum discussions;
- AI/chat research records;
- architecture decision records;
- technical limitations identified; and
- the proposed hypothesis.
During the experiment
- Git commits;
- Jira or investigation tickets;
- experiment plans;
- model versions;
- test datasets;
- benchmark results;
- logs;
- performance graphs;
- failed approaches; and
- technical discussions.
After the experiment
- results;
- quantitative comparisons;
- analysis of the results;
- technical conclusions;
- decisions to change or abandon an approach;
- new hypotheses; and
- architecture or model decisions arising from the experiment.
The format matters less than the content.
What I want is a trail showing why the problem could not be solved using the
knowledge available at the time, what was tested and what the team learned.
For more on substantiation, see our
R&D Tax Incentive record-keeping guide.
Can you claim AI, GPU, API and cloud costs?
AI companies can incur significant costs through AWS, Azure, Google Cloud, GPUs,
model training, OpenAI or Anthropic APIs and other development infrastructure.
I would not start by assuming those costs are a problem simply because they are
cloud or AI costs.
I would start by asking what they were actually used for.
If compute resources were genuinely being used to perform the eligible
experimental work, I would investigate the expenditure as part of the R&D
claim.
The main thing I would then strip out is business-as-usual usage.
For example, a cloud account may include both experimental model-training costs
and normal production hosting used to serve customers.
Those are not the same thing.
The expenditure needs to be connected to eligible registered R&D activities,
and where a cost relates partly to R&D and partly to ordinary operations, the
basis of apportionment needs to be reasonable.
There are also specific expenditure rules and exclusions that can apply to
acquired technology and other costs. This is why I would not simply take the AWS
or AI-provider invoice and include the whole amount.
The ATO has specifically identified whole-of-project software claims, acquired
technology and unreasonable apportionment between R&D and ineligible activity
as areas of concern in software-development claims.
See our
guide to eligible R&D expenditure
for the broader expenditure rules.
What if the AI system is being built for your own business?
This needs additional care.
The R&D Tax Incentive contains a specific exclusion for certain software
developed, modified or customised for the dominant purpose of the internal
administration of the developer, connected entities or affiliates.
That can become relevant to AI systems built for internal CRM, administration,
HR, workflow management, finance and other business functions.
It does not mean every internally used piece of software is automatically
excluded. The purpose of the software and the particular activities need to be
analysed properly.
See our
guide to activities excluded from core R&D
for more detail.
Common mistakes I see with AI R&D claims
Claiming the whole product
A large AI platform may contain a relatively small number of genuinely
experimental activities. The entire software project should not automatically
be treated as R&D.
Assuming new means R&D
A product being new to your company or even new to the market does not
establish that the technical outcome could not be determined in advance.
Calling trial and error experimentation
Trying different prompts, settings, models or configurations until one
performs best is not necessarily the systematic hypothesis-led experimentation
required for a core R&D activity.
Retrofitting the hypothesis
If nobody involved in the development can explain what they thought would
happen before the test, a beautifully written hypothesis prepared nine months
later does not fix that.
Ignoring reasonably accessible knowledge and tools
The fact that your developer did not personally know how to solve something
does not establish an unknown outcome if a competent professional could
reasonably have determined it using the knowledge and tools available at the
time.
No quantitative evidence
AI claims become much stronger when the technical team can show a baseline,
experiment and objective change in performance.
Reconstructing the records later
AI knowledge changes too quickly. Contemporaneous records can be critical to
showing that a solution available today was not reasonably available when the
experiment occurred.
Claiming all cloud costs
Experimental compute and normal production infrastructure need to be
distinguished. The expenditure analysis should follow the actual activities.
Official sources
-
Income Tax Assessment Act 1997 – sections 355-25 and 355-30
-
Department of Industry, Science and Resources – Artificial intelligence-related activities and the R&D Tax Incentive
-
Department of Industry, Science and Resources – Software development sector guide
-
Department of Industry, Science and Resources – Conducting core R&D activities
-
Australian Taxation Office – Helping you get R&D claims right