R&D Tax Incentive for AI Software Development in Australia

Yes, AI software development can qualify for Australia's R&D Tax Incentive, and an AI startup can claim it if it is an eligible company spending at least $20,000 on eligible R&D in the year. Only the genuinely experimental work counts: activities whose outcome could not be known in advance and was resolved by systematic experiment. Routine integration, interface and deployment work is excluded.

How does the R&D Tax Incentive apply to AI software development?

Many organisations building or commissioning AI are under-claiming, and some are taking on audit risk by claiming too much. Both problems come from a poor understanding of how the Research and Development Tax Incentive applies to software. The program is jointly administered by AusIndustry, within the Department of Industry, Science and Resources, and the Australian Taxation Office.

AI development is one of the most misunderstood categories in the scheme. AusIndustry and the ATO have repeatedly flagged software claims as a focus area, because companies assume a new end product makes the whole project R&D. The incentive rewards experimentation that resolves genuine technical uncertainty. It does not reward assembling a new system from known parts. This guide is for CFOs and finance directors who want to claim what is available without inheriting an audit they cannot defend.

What does the R&D Tax Incentive reward?

The incentive is set out in Division 355 of the Income Tax Assessment Act 1997. It works as a tax offset, reducing tax payable or, for eligible smaller companies, producing a cash refund:

• Companies with aggregated turnover under $20 million receive a refundable offset of 43.5 percent (for a base rate entity). In a tax loss year, it is paid as cash.
• Companies with turnover of $20 million or more receive a non-refundable offset: the company tax rate plus an intensity-based 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 (unless it uses a registered research service provider).

Rates and thresholds are those in place at the time of writing (October 2026). Check AusIndustry for any announced changes before relying on them for future years.

• Eligible R&D expenditure on an AI build$300,000
• Refundable offset at 43.5%$130,500
• Net cost of the eligible R&D work$169,500
• Effective discount on genuine experimentation43.5%

These figures are illustrative arithmetic. The real benefit depends on how much spend is genuinely eligible, which is where most of the work and risk sit.

Can an AI startup claim the R&D Tax Incentive in Australia?

Yes, provided it meets the same tests as any other claimant. The R&D entity must be a company incorporated in Australia (or a foreign company that is an Australian resident or operates through a permanent establishment here). Individuals, partnerships and trusts cannot claim directly.

For an AI startup, the refundable offset is often the most valuable part of the scheme, because a loss-making company receives the 43.5 percent offset as cash. The same rules apply: only experimental activities and the work that directly supports them count, the $20,000 minimum applies, and records must be made at the time. A startup that configures an existing AI product, or whose dominant purpose is building tools for its own internal administration, is unlikely to qualify for that work.

What are core and supporting R&D activities in software?

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 from current knowledge, information or expertise. The outcome can only be found through a systematic progression from hypothesis to experiment, observation, evaluation and logical conclusions, conducted to generate new knowledge.

Supporting R&D activities directly support a core activity without being the experiment. Preliminary research, project management and data collection can qualify. Where a supporting activity also produces goods or services, or is normally done in the ordinary course of business, a stricter dominant purpose test applies.

For an AI project, the split is everything. Training and evaluating an architecture when you genuinely do not know whether it will reach the required accuracy is plausibly core. Wiring the model into existing systems, building the interface and writing deployment scripts is ordinary software engineering, at best supporting and often not eligible.

	Activity	Likely treatment	Impact
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, integration and deployment included, because the product is new to the business. An organisation that buys and configures an existing AI tool is almost certainly not doing core R&D, a distinction covered in our build versus buy AI total cost of ownership guide.

How do you apply the technical uncertainty test to AI?

Ask of every AI activity: could a competent professional in the field have known the outcome in advance? If yes, it is not core R&D, however much effort it took. If genuinely no, and you resolved the uncertainty through a structured experiment, you have a candidate.

What is the nature of the technical work?

• Outcome was genuinely unknown and resolved by structured experimentLikely core R&D activity
• Novel application but built from well-understood componentsGenerally not core R&D
• Configuring or fine-tuning an existing product to known specsNot R&D
• Supports an experiment but is not the experiment itselfPossibly supporting R&D
• Routine integration, UI, or deployment workGenerally ineligible

Genuine technical uncertainty in AI tends to cluster around a few patterns:

• pushing accuracy on a problem where published approaches fall short
• handling data far messier or more domain-specific than standard datasets
• meeting performance or latency targets known architectures do not reach
• combining techniques in ways whose behaviour cannot be predicted

Framing work this way before you start also produces better projects, as set out in our AI proof of concept four-week framework.

What R&D software activities are excluded?

Division 355 lists work excluded from core R&D regardless of uncertainty. Several come up often for software and AI teams:

• 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

The last exclusion catches a lot of internal AI work. 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. Scope internal automation projects carefully before building a claim into the budget. Our build versus buy AI decision framework covers where that boundary tends to fall.

What documentation does an R&D claim need?

Legitimate claims most often fail on review because the company cannot prove what it did, and when. AusIndustry and the ATO expect contemporaneous documentation, created when the activities were conducted.

For an AI project, records that survive scrutiny include:

• a statement of the hypothesis and technical uncertainty before the work began
• experiment logs: architectures, parameters and approaches tried, with results
• evaluation records showing how outcomes were measured against the hypothesis
• a narrative of the progression from hypothesis through experiment to conclusion
• time and cost records connecting expenditure to core and supporting activities

Much of this is a by-product of doing the work properly. Version control history, experiment tracking, evaluation reports and engineering tickets capture most of what a claim needs, if someone maps them to the eligibility framework as the work happens. Building that discipline into delivery is part of taking AI from prototype to production.

What does the R&D claim workflow look like?

The costliest mistake is treating the claim as a year-end task. By then the experiments are done, memories have faded, and the records either exist or they do not.

1. 1ScopeIdentify activities with genuine technical uncertainty
2. 2DocumentRecord hypotheses, experiments and results as you go
3. 3CostTrack expenditure against core and supporting activities
4. 4RegisterLodge activities with AusIndustry within 10 months
5. 5ClaimCalculate the offset in the company tax return
6. 6DefendRetain records in case of review

Activities must be registered with AusIndustry within 10 months of the end of the income year. For a 30 June year-end, registration for 2025-26 is due by 30 April 2027. Registration is a precondition for claiming the offset, and extensions are only granted in limited circumstances.

1. Start of projectFrame the uncertaintyWrite the hypothesis and define what is unknown
2. During the buildLog experimentsCapture approaches tried, results, and evaluations as you go
3. Year-end (30 June)Reconcile costsMap expenditure to core and supporting activities
4. By 30 AprilRegister and claimLodge with AusIndustry, then claim in the tax return

Worked example: splitting an AI build for an R&D claim

For example, consider a hypothetical distribution business building a demand-forecasting model for its network.

The team starts with a clear technical uncertainty: existing forecasting approaches do not handle its irregular, promotion-driven demand, and it is genuinely unknown whether a model can reach the accuracy operations needs. It frames a hypothesis and runs structured experiments across architectures and feature sets, logging each attempt and its measured accuracy. That work, and the data collection that directly supports it, is the candidate for core and supporting R&D.

Once a model meets the target, the remaining work changes character. Connecting it to the warehouse management system, building the planners' dashboard and writing deployment and monitoring scripts is well-understood engineering whose outcome was never in doubt. Most of it is not eligible.

	Phase of work	Treatment for the claim	Impact
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

A precise claim is usually a smaller share of total spend than businesses expect, and far harder to challenge. Our guide to AI demand forecasting for manufacturers and distributors covers the delivery side of the same capability.

What mistakes trigger R&D review?

1. Claiming the whole project. Integration, interface and deployment are rarely R&D, however new the product.
2. Thin documentation. Experiment logs reconstructed at tax time read exactly like what they are.
3. Claiming configuration of off-the-shelf AI. Setting up and tuning an existing product is implementation, even when it delivers real value.

Claim the experimental core, support it with the activities that directly enable it, document as you go, and leave routine engineering out. That claim is stronger where it counts and easier to defend.

How does the incentive fit an AI business case?

For any AI build involving genuine experimentation, the incentive should be a line in the business case from the start. A 43.5 percent refundable offset on the eligible portion changes the economics of building versus buying, and should be modelled alongside other costs. Our AI implementation cost breakdown and AI business case template for board presentation show how to fold it into the numbers a board will scrutinise.

How Solve8 can help

We build custom AI with the experimental work framed, logged and separated from routine engineering in the project record, so your tax adviser has a clear foundation to work from. We do not provide tax advice; confirm any claim with a registered tax agent or R&D specialist. See our custom AI development service or talk to us.