Does using AI make an activity R&D?
No. The Department of Industry, Science and Resources (DISR) states that the R&D Tax Incentive's requirements "do not depend on the technology used", so using AI in software development does not make an activity eligible. An AI, machine learning or large language model (LLM) activity is tested against the same Division 355 definitions as any other activity.
DISR's guidance adds that "using an AI model or technique that is new to you does not, by itself, mean the activity is eligible for the program." To be a core R&D activity, the work must aim to resolve a technical hurdle, with a proposed solution (the hypothesis) tested through planned experiments. (business.gov.au — Artificial intelligence-related activities and the R&D Tax Incentive)
DISR treats AI as part of software development, so its Software development sector guide also applies. For that broader picture, see Are software development activities eligible for the R&D Tax Incentive?.
This article explains how the legislation and guidance frame the test. It is general information, not advice, and it does not assess any particular activity.
How does the activity-by-activity test apply to AI and machine learning work?
The R&D Tax Incentive assesses activities, not projects. An AI project is a set of separate activities, such as scoping, training, evaluation, integration, deployment and monitoring. Each one is assessed on its own against section 355-25 (core) or section 355-30 (supporting). DISR says it is likely that not every activity within an innovation project will meet the requirements.
DISR's software guide describes activities as "the building blocks that make up a project" and states that "it is likely that not all activities within an innovation project will meet the requirements." (Software-related activities and R&D Tax Incentive, May 2024)
DISR's AI guidance lists the kinds of activity AI-related R&D may involve:
- scoping and designing AI-enabled solutions
- developing and training AI models
- testing and evaluating model performance
- integrating AI into software applications and platforms
- deploying models into operational use
- monitoring, updating or maintaining AI systems over time.
Each item is a candidate for assessment, not a category that passes or fails as a whole. DISR also warns against combining too many activities into a single core R&D activity, as this can make the description unclear. (business.gov.au — Software development sector guide)
The underlying statutory test is in section 355-25(1) of the Income Tax Assessment Act 1997. Core R&D activities are experimental activities whose outcome cannot be known or determined in advance from current knowledge, and can only be found through a systematic progression of work, conducted to generate new knowledge. (ITAA 1997, Division 355) For a full walkthrough of the definitions, see Core vs supporting R&D activities: Division 355 explained.
Which AI activities does the guidance describe as unlikely to be core R&D?
DISR lists AI work that may be complex but generally can be handled by experts using existing knowledge and solutions. Examples include routine monitoring and dashboards, standard data preparation, regression and acceptance testing, and parameter tuning where the fix is known. Integrating known model outputs through pre-defined logic, and integrating APIs by following vendor documentation, are also listed.
The AI guidance gives these examples of activities unlikely to meet the core R&D requirements:
| Activity | Why the guidance treats it as routine |
|---|---|
| Logging, alerts, dashboards or routine performance checks | Uses established methods and tools to confirm expected model behaviour |
| Cleaning, formatting and aligning data to a model's documented input requirements | Standard data preparation, where the transformations needed are known in advance |
| Regression, acceptance or functionality testing | Expected outcomes are already known |
| Adjusting or fine-tuning parameters such as learning rate | It is known the issue can be solved by parameter changes and the effect is well understood |
| Integrating known model outputs (scores, labels, recommendations) into apps or dashboards | Uses pre-defined logic, rules and interfaces where model behaviour and the integration approach are established |
Source: business.gov.au — AI-related activities and the R&D Tax Incentive.
The broader software guide adds "integrating third party services or application programming interfaces by following vendor documentation" to its list of generally routine work. (business.gov.au — Software development sector guide)
DISR notes that activities which are unlikely to be core R&D activities may still qualify as supporting R&D activities, which must be directly related to a core activity.
What AI work does the guidance describe as potentially core R&D?
The guidance says AI activities may meet the core R&D requirements where a technical hurdle exists and an expert in the field considers that only experimentation will show whether a proposed solution can resolve it. Its examples are a fine-tuning strategy whose effects are not well understood, and an architecture that may not work in a new domain.
In DISR's words, AI-related activities may meet the requirements of a core R&D activity "where a technical hurdle exists and an expert in the field considers that only experimentation will determine if a proposed solution, or the way to develop a solution, can resolve the technical hurdle." Its two illustrations, paraphrased:
- investigating a new fine-tuning strategy whose effects are not well understood, and which has not been applied in a comparable deployment environment, to resolve scalability issues where established methods have failed
- experimentally testing an AI architecture against domain-specific performance limits, where it is not known whether it can work in the target domain or with the available data.
Source: business.gov.au — AI-related activities and the R&D Tax Incentive.
The bar for "unknown" is set by knowledge available anywhere, not by the team's own experience. DISR's software guide says a competent professional in the field must be unable to determine the outcome in advance using knowledge available anywhere in the world. It expects reasonable and thorough inquiries, such as searching journals, open-source code repositories and technical blogs, before concluding an outcome is unknown. (Software-related activities and R&D Tax Incentive, May 2024)
How does the guidance treat an LLM chatbot built on RAG?
DISR's AI guidance works through three hypothetical activities on one retrieval augmented generation (RAG) chatbot. Desktop research to choose a stack from proven platforms is not core R&D. Researching new chunking methods to refine a hypothesis can be supporting R&D. Experimenting with unproven chunking methods on real-world data, where experts could not predict the result, can be core R&D.
| Hypothetical activity | How the guidance characterises it | The deciding factor |
|---|---|---|
| Desktop research into proven platforms, models, frameworks and RAG pipelines to decide the technology stack | Does not meet the core R&D requirements | Existing knowledge could determine the stack design. There was no technical hurdle. |
| Desktop research into new, still-theoretical dynamic chunking methods, to refine a hypothesis for a planned experiment | Can be a supporting R&D activity | It was done specifically to refine the hypothesis and experiment design for a planned core activity |
| A series of runs comparing new and baseline chunking methods on the same real-world data and queries, measured on retrieval precision and recall, semantic similarity and answer faithfulness | Can be a core R&D activity | Background research found no existing solution, and experts could not predict how the methods would behave on real-world data |
Source: business.gov.au — AI-related activities and the R&D Tax Incentive, Examples 1–3.
The same product, and even the same technique, can therefore sit on different sides of the line depending on the activity. In the third example, several assumptions in the hypothesis were proven wrong and new runs were needed. The guidance still describes that activity as one that can be a core R&D activity.
Which exclusions matter for AI projects?
The exclusion most relevant to software, and so to AI, is section 355-25(2)(h). It covers developing, modifying or customising software for the dominant purpose of internal administration by the developer or a connected or affiliated entity. The exclusion turns on the software's dominant purpose of use: if that is internal administration by the developer or a connected or affiliated entity, the exclusion's terms apply whatever AI technique is used.
DISR's software guide gives payroll, accounting, invoicing, ordering, management information systems and enterprise resource planning as examples of internal administration functions. It notes that software is not caught where its dominant use is not internal administration, for example software used by customers, or software used to collect and analyse data from experiments. Activities excluded from being core can still be supporting R&D activities where they are directly related to a core activity and meet the dominant purpose test. (Software-related activities and R&D Tax Incentive, May 2024; ITAA 1997, s 355-25(2)(h))
The same guide notes an expenditure rule. The cost of "core technology", meaning technology bought or licensed in order to develop it further, is not an allowable R&D expense, although the costs of developing it further may be. The ATO administers the expenditure rules. (Software-related activities and R&D Tax Incentive, May 2024)
What records demonstrate an AI or machine learning experiment?
DISR expects records of the hypothesis, the experiment, the results and the conclusions, made at or around the time of the work. For AI and machine learning this usually means background research, a written hypothesis, the experiment design and metrics, results from every run including failed ones, model and code version history, and the evaluation that led to each conclusion.
DISR's software guidance says it expects you to record "the hypothesis that you are testing", what the experiment was and how it was conducted, the results, and the conclusions drawn. For experiments it lists the objective, the experimental variables and parameters, the observations, and the evaluation method. (Software-related activities and R&D Tax Incentive, May 2024) Mapped to typical AI work:
| What needs showing | Records the guidance points to | In an AI or ML project, for example |
|---|---|---|
| The outcome could not be known in advance | Literature reviews, expert communications, forum questions, failed attempts with existing technology | Notes on papers, benchmarks and repositories reviewed, and why existing models or methods did not resolve the hurdle |
| A hypothesis | The idea, how it will be achieved, and the background research behind it, formed before the experiment starts | A dated hypothesis linking a specific method to a specific measurable effect |
| A planned experiment | Parameters varied, held constant and measured, and the evaluation method | Run configurations, datasets and splits, baselines and success metrics |
| Observation and evaluation | Results of all experimental runs and analyses of them | Experiment logs and evaluation results per run, including runs that disproved assumptions |
| Iteration | Code repositories or software versions with comments on weaknesses found and fixed in successive versions | Model, prompt and code version notes tied to the run that prompted each change |
| Purpose of generating new knowledge | Meeting minutes or reviews identifying the need to experiment | Recorded discussion of why experimentation was needed, such as expert advice that the outcome could not be predicted |
Sources: Software-related activities and R&D Tax Incentive (May 2024), Table 1; business.gov.au — Software development sector guide; business.gov.au — Hypothetical Machine Learning case study.
DISR's hypothetical Machine Learning case study, about predicting soil moisture, lists the records its fictional company keeps while the work happens. These are documented discussions of its intent, background research with article links, experiment plans including the hypothesis, and the results of all experimental runs. It also keeps timesheets and annotated invoices linking expenditure to the activities. The case study describes hyperparameter tuning to set benchmarks as a routine step, separate from the experiment itself.
DISR's record-keeping guidance says records should be created at the time the activity is conducted and kept for five years after the expenditure is claimed. (business.gov.au — Record keeping for the R&DTI) DISR says it is the content of records, not their format, that matters. Experiment tracking that AI teams already use, such as run logs, evaluation dashboards and versioned notebooks, can capture much of this evidence, provided it captures the hypothesis and conclusions as well as the numbers. For why timing matters, see What "contemporaneous documentation" means for the R&D Tax Incentive. For a plain-English overview of the wider rules, see the guide to the R&D Tax Incentive rules, or put a question about the terms to the R&D Tax Incentive chatbot.
Dossio is compliance infrastructure for the R&D Tax Incentive. It captures the hypothesis, experiments, results and conclusions behind AI and software R&D activities in structured, dated form as the work happens, with R&D tax experts providing oversight and governance.
Sources
- business.gov.au — Artificial intelligence-related activities and the R&D Tax Incentive
- business.gov.au — Software development sector guide for the R&D Tax Incentive
- business.gov.au — Hypothetical Machine Learning case study
- business.gov.au — Software-related activities and R&D Tax Incentive (PDF, May 2024)
- business.gov.au — Record keeping for the R&DTI
- Federal Register of Legislation — Income Tax Assessment Act 1997, Division 355 (ss 355-25, 355-30)