R&D Tax Incentive for AI Software Projects
Most businesses building or commissioning AI in 2026 are leaving money on the table, and a smaller group are quietly taking on audit risk by claiming too much. Both problems trace to the same source: a poor understanding of how the Research and Development Tax Incentive applies to software and AI work. The R&D Tax Incentive, jointly administered by AusIndustry within the Department of Industry, Science and Resources and the Australian Taxation Office, can return 43.5 cents in the dollar to eligible companies. For an organisation investing six figures in AI development, that is the difference between a project that pays for a chunk of itself and one that does not.
The catch is that AI development is one of the most misunderstood categories in the entire scheme. AusIndustry and the ATO have repeatedly flagged software claims as a focus area, precisely because companies tend to assume that because the end product is new, the whole project is research and development. It is not. The incentive rewards experimentation that resolves genuine technical uncertainty, not the routine assembly of a new system from known parts. This guide is written for the CFO, finance director, or founder who wants to claim what is rightfully available without inheriting an audit they cannot defend.
What the incentive actually rewards
The R&D Tax Incentive is set out in Division 355 of the Income Tax Assessment Act 1997. It works through a tax offset rather than a grant, which means it reduces tax payable or, for smaller companies, produces a cash refund. The structure is simple:
- Companies with an aggregated turnover under $20 million receive a refundable offset at a rate of 43.5 percent. If the company is in a tax loss, this is paid as cash.
- Companies with turnover of $20 million or more receive a non-refundable offset, calculated as the company tax rate plus an intensity premium, which can be carried forward.
- A company must incur at least $20,000 of eligible notional R&D expenditure in the income year to claim.
The 43.5 percent refundable rate continues to apply for the 2025-26 and 2026-27 income years. The Government announced changes to the program in the 2026-27 Budget, but those take effect from 1 July 2028, so they do not affect claims for the current or coming year. For planning purposes, the rules described here are the rules that apply to the AI project you are running today.
What a 43.5% refundable offset means in practice
The figures above are illustrative arithmetic, not a promise of outcome. The actual benefit depends entirely on how much of your spend is genuinely eligible, which is where most of the work and most of the risk sit.
Core versus supporting activities
The scheme divides eligible work into two categories, and getting the distinction right is the heart of a defensible claim.
Core R&D activities are experimental activities whose outcome cannot be known or determined in advance based on current knowledge, information, or expertise. The outcome can only be worked out through a systematic progression of work that proceeds from hypothesis to experiment, then to observation and evaluation, and leads to logical conclusions. They must be conducted for the purpose of generating new knowledge. This is the language of the scientific method, applied to software.
Supporting R&D activities are activities conducted for the purpose of supporting a core activity, but which are not themselves the experiment. Preliminary research, project management, and data collection can qualify as supporting activities. Where a supporting activity also produces goods or services, or is an activity normally undertaken in the ordinary course of business, a stricter dominant-purpose test applies.
For an AI project, this split is everything. Training and evaluating a model architecture where you genuinely do not know whether it will reach the required accuracy is plausibly a core activity. Wiring that model into your existing systems, building the user interface, and writing the deployment scripts is ordinary software engineering, and is at best a supporting activity, often not eligible at all.
AI project work: likely core, supporting, or ineligible
| Metric | Activity | Likely treatment | Improvement |
|---|---|---|---|
| Testing a novel model architecture against an unknown accuracy target | Experimental | Likely core R&D | Eligible |
| Developing a new technique to handle messy domain-specific data | Experimental | Likely core R&D | Eligible |
| Collecting and labelling training data for the experiment | Supports the core | Likely supporting R&D | Conditional |
| Integrating the model into existing line-of-business systems | Routine engineering | Generally ineligible | Excluded |
| Configuring an off-the-shelf AI product to your settings | Standard implementation | Not R&D | Excluded |
The pattern AusIndustry warns against is claiming the entire project, including the integration and deployment, because the finished product is novel to the business. Novelty of the product is not the test. Technical uncertainty that can only be resolved by experiment is the test. A business that buys and configures an existing AI tool, however transformative, is almost certainly not doing core R&D, a distinction we explore in our build versus buy AI total cost of ownership guide.
The technical uncertainty test, applied to AI
The single most useful question to ask of any AI activity is this: could a competent professional in the field have known the outcome in advance? If the answer is yes, it is not core R&D, no matter how much effort it took. If the answer is genuinely no, and you resolved that uncertainty through a structured experiment, you have a candidate.
Is this AI activity likely a core R&D activity?
In practice, genuine technical uncertainty in AI work tends to cluster around a few patterns: pushing model accuracy on a problem where published approaches fall short, handling data that is far messier or more domain-specific than standard datasets, achieving performance or latency targets that known architectures do not meet, or combining techniques in a way whose behaviour cannot be predicted. The discipline of framing the work this way before you start is the same discipline that produces good outcomes generally, as set out in our AI proof of concept four-week framework.
Documentation is the claim
The most common reason a legitimate R&D claim fails on review is not that the activity was ineligible. It is that the company could not prove what it did when it did it. AusIndustry and the ATO expect contemporaneous documentation, meaning records created at the time the activities were conducted, not reconstructed at tax time.
For an AI project, the documentation that survives scrutiny includes:
- A clear statement of the hypothesis and the technical uncertainty before the work began.
- Experiment logs: the architectures, parameters, and approaches tried, and the results of each.
- Evaluation records showing how outcomes were measured against the hypothesis.
- A narrative of the systematic progression from hypothesis through experiment to conclusion.
- Time and cost records that connect expenditure to the core and supporting activities.
The good news for AI teams is that much of this is a by-product of doing the work properly. Version control history, experiment-tracking tools, model evaluation reports, and engineering tickets already capture most of what a claim needs, provided someone connects them to the eligibility framework. The organisations that struggle are those that did real experimentation but recorded none of it in a form that maps to the scheme. Building documentation discipline into delivery, rather than bolting it on later, is part of what we mean by taking AI from prototype to production.
The end-to-end claim workflow
A clean claim follows a predictable path across the income year. The mistake that costs companies most is treating it as a year-end task. By then the experiments are done, the memory has faded, and the contemporaneous records either exist or they do not.
R&D Tax Incentive claim workflow
A critical date sits inside that workflow. Activities must be registered with AusIndustry within 10 months of the end of the income year. For a company with a 30 June year-end, that means the registration for the 2025-26 year is due by 30 April 2027. Registration is a precondition for claiming the offset in the tax return, and the deadline is not generally extendable. Miss it and an otherwise valid claim is lost.
A realistic timeline through the income year
The teams that claim confidently treat eligibility as a discipline that runs alongside the build, not a paperwork sprint after it. The schedule below assumes a 30 June year-end.
R&D claim discipline across the income year
Common mistakes that trigger review
Three patterns account for most of the trouble businesses run into. First, claiming the whole project. The integration, the interface, and the deployment are rarely R&D, however novel the product. Second, thin documentation. Reconstructing experiment logs at tax time reads exactly like what it is, and reviewers know the difference. Third, claiming the configuration of off-the-shelf AI as R&D. Setting up and tuning an existing product to your requirements is implementation, not experimentation, even when it delivers real business value.
Avoiding these is less about restraint and more about precision: claim the genuinely experimental core, support it with the activities that directly enable it, document everything as you go, and leave the routine engineering out. A claim built this way is both larger in the parts that count and far easier to defend.
How this fits your AI business case
The R&D Tax Incentive should be a line in the business case for any AI build that involves genuine experimentation, not an afterthought discovered at tax time. A 43.5 percent refundable offset on the eligible portion of spend materially changes the economics of building rather than buying, and it should be modelled explicitly alongside the other costs and benefits. Our AI implementation cost breakdown and AI business case template for board presentation both provide the structure to fold the incentive into the numbers a board will scrutinise.
The discipline that matters is designing the project so the experimental work is identifiable and documented from day one. That is good engineering and good governance, and it happens to make a strong claim almost automatic.
What the scheme excludes by default
Division 355 also lists categories of work that are specifically excluded from being core R&D activities, regardless of how much uncertainty they involve. For software and AI teams, several of these come up often, so it is worth knowing them before you scope a claim.
- Market research, market testing, and sales promotion, including consumer surveys.
- Management studies and efficiency surveys.
- Research in social sciences, arts, or humanities.
- Activities associated with complying with statutory requirements or standards.
- Reproducing an existing product or process from available knowledge.
- Developing, modifying, or customising software for the dominant purpose of internal business administration.
That last exclusion catches a surprising amount of internal AI work. Building an AI tool whose dominant purpose is your own back-office administration is generally excluded as a core activity, even where it involved real technical difficulty. The exclusion is one of several reasons that internal-facing automation projects need careful scoping before any expectation of a claim is built into the budget. It is also why the boundary between an experimental component and an ordinary build matters so much, a theme that runs through our build versus buy AI decision framework.
Worked example: an AI build across an income year
Consider a hypothetical logistics business that decides to build a demand-forecasting model for its distribution network. The point of this example is to show how the eligible and ineligible portions separate out, not to represent any specific engagement.
The team starts with a clear technical uncertainty: existing forecasting approaches do not handle the irregular, promotion-driven demand patterns in their product range, and it is genuinely unknown whether a model can reach the accuracy the operations team needs to act on. They frame a hypothesis, then run a structured series of experiments across model architectures and feature sets, logging each attempt and its measured accuracy. That experimental work, and the data collection and labelling that directly supports it, is the candidate for core and supporting R&D.
Once the experiment establishes a model that meets the target, the remaining work changes character entirely. Wiring the model into the warehouse management system, building the dashboard the planners use, and writing the deployment and monitoring scripts is ordinary, well-understood engineering. The outcome of that work was never in doubt to a competent professional. It is not core R&D, and most of it is not eligible at all.
Splitting the hypothetical forecasting build
| Metric | Phase of work | Treatment for the claim | Improvement |
|---|---|---|---|
| Framing the technical uncertainty and hypothesis | Experimental design | Core R&D | Eligible |
| Testing model architectures against the accuracy target | Experiment | Core R&D | Eligible |
| Collecting and labelling the training data for the experiment | Directly supports the core | Supporting R&D | Conditional |
| Integrating the chosen model into the warehouse system | Routine engineering | Not R&D | Excluded |
| Building the planner dashboard and deployment scripts | Standard development | Not R&D | Excluded |
The lesson from the split is that a precise claim is a smaller share of total project spend than many businesses expect, but it is also far harder to challenge. A claim that honestly isolates the experimental core will withstand review. A claim that sweeps in the integration and the dashboard because they were part of the same project invites exactly the scrutiny that makes the whole exercise stressful. The same forecasting capability, incidentally, is one we cover from a delivery angle in our guide to AI demand forecasting for Australian manufacturers and distributors.
Where Solve8 fits
Solve8 builds custom AI for Australian businesses, and we structure delivery so the experimental work is visible and documented from the outset. That means the technical uncertainty is framed before the build starts, experiments are logged as they run, and the boundary between core R&D and routine engineering is clear in the project record. We do not provide tax advice, and any claim should be confirmed with a registered tax agent or R&D specialist, but a build that is documented properly gives your advisers a far stronger foundation to work from.
If you are weighing whether to build AI in-house or commission it, the availability of the incentive is one input among several. Our custom AI development service and AI strategy service are designed to deliver capability that is documented, explainable, and defensible. To talk through an AI project and how to structure it well, contact the Solve8 team.
The bottom line
The R&D Tax Incentive can return a substantial share of what you spend on genuinely experimental AI development, but only if you claim the right activities and prove them with records made at the time. The businesses that benefit most are not the ones that claim the most aggressively. They are the ones that frame their technical uncertainty clearly, run real experiments, document as they go, and leave the routine engineering out of the claim. Do that, and the incentive becomes a reliable part of your AI economics rather than a year-end gamble.
Related reading
- Build versus buy AI: a complete total cost of ownership guide
- AI implementation cost breakdown
- AI business case template for board presentation
- AI proof of concept: a four-week framework
- Taking AI from prototype to production
Planning an AI build that involves real experimentation? Explore our custom AI development service or contact the Solve8 team.