R&D Tax Incentive Australia: does your AI build qualify?

TL;DR: Your AI build can qualify, but only if it solves a real technical problem nobody has the answer to yet. Write the hypothesis before the code. Run a proper experiment with pass and fail criteria set up front. Log every attempt, including the ones that failed. Keep timesheets tagged to the activity, not a generic project code. Do it while you build, because records written six months later get picked apart.

Your AI build can qualify for the R&D Tax Incentive. But not automatically, and not because the tech is new to you.

Four things have to be true. The work has to solve a real technical problem where nobody knows the answer up front. You test it with a written hypothesis and a real experiment. The work generally happens in Australia. And you keep the records while you build, not six months later.

That last one is where most teams come unstuck. The engineering is fine. The paper trail is missing.

What counts as core R&D

The business.gov.au software sector guide sets the bar. A core R&D activity follows a set path: hypothesis, experiment, observation, evaluation, conclusion. The outcome has to be genuinely unknown to a skilled person in the field. Not just unknown to your team.

Here is the test for a CTO.

Wiring up a documented API with a known pattern isn't R&D. It might feel new to your business. It is still a build job.

Training a model where you can't say if a new architecture will converge is different. So is a data pipeline where the behaviour under load is a real unknown. Approach those as experiments and you're in the right territory.

Using a model your team has not used before doesn't make it eligible on its own. What matters is whether the work solves a technical problem by testing it.

Things worth documenting:

• A new model architecture or training approach where you can't predict the result from the docs or the literature.
• Data work where the effect of a transformation, feature set or labelling scheme on model performance is genuinely unknown.
• Scaling behaviour you can't estimate up front, like latency or accuracy trade-offs under production load.
• Integration work where joining two systems throws up failure modes standard debugging can't explain.

Supporting activities sit next to the core work. They have to be directly related, and done for the dominant purpose of supporting it. Building test rigs to run your experiments is the clean example. If the task would've happened anyway, it's hard to justify.

Write the hypothesis before you write the code

Most engineering teams already do experiment-shaped work. The gap is writing it down, not the method.

Four habits turn a sprint task into evidence.

1. State the hypothesis first. Say what you think will happen and why it's uncertain. Something like: a hybrid dense and sparse retrieval approach will push RAG precision above 85% on your support ticket data, but you don't know how chunk size and embedding model interact.
2. Define the experiment. Set the control variables, the metric, and what counts as pass or fail. Do this before you run anything. If you can't say what failure looks like, the test isn't tight enough.
3. Log every attempt. A failed run is evidence, not waste. Ruling out an approach is exactly the kind of finding a claim needs.
4. Record the evaluation. Write what the data showed against your stated criteria, and whether the hypothesis held.

Two examples. Tuning retrieval precision counts when you can show the link between chunking strategy and answer accuracy was a real unknown, and you tested it properly. Scaling tests on a new architecture count when throughput under real load could not be predicted from the docs.

Now here's the important bit. Commit a small `hypothesis.md` file to the same branch as the experiment code. Tie it to a ticket number and your time entries. That one habit links the idea, the code and the hours in a way a reviewer can follow.

Sprint reviews and CI dashboards already throw off most of this. What is usually missing is a short note at the end of the cycle saying what you tested and what you learned, written while it's fresh. The same discipline that makes prompt engineering work makes an R&D claim work: test against a fixed set, write down the result.

What records the ATO expects

The ATO wants a clear line between the dollars you claim and the registered activity that earned them. That means records kept at the time, not a reconstruction after the fact.

A short checklist:

• Timesheets tagged to a specific registered activity, not a generic project code.
• Experiment logs and sprint notes saved on the day.
• A written method for splitting the time of developers who work across R&D and normal delivery.
• A one page finance memo explaining that split, so a reviewer sees the logic and not just the number.

Salaries, contractor fees and cloud compute tied to an experiment generally count. Costs with no clear link don't survive a look. General account management and unrelated feature work bundled into the same sprint are the usual casualties.

Cloud compute is the one people underestimate. If you already track infrastructure cost per workload and run proper unit economics on your AI spend, you're most of the way to a defensible split.

There is also a minimum. You need eligible notional deductions above a threshold in the income year, and the work generally has to happen in Australia. Overseas work only counts with a formal finding from the Department of Industry, Science and Resources. Check the current threshold on business.gov.au before you plan around it, and run the numbers past your tax adviser. We build software. We don't lodge your claim.

What gets knocked back

Software built for the dominant purpose of internal business administration is excluded from core R&D. That holds even when the build is hard. Payroll systems, internal ERP work and internal reporting dashboards all sit in that bucket. They can sometimes count as supporting activities, but only if the link to a registered core activity is explicit.

Routine engineering is the other trap. Plugging in a well documented library, applying a known pattern, or scaling an existing system with standard techniques generally misses the bar. The outcome isn't uncertain to a skilled professional.

Red flags worth catching before someone else does:

• Records written after the fact. Reviewers spot it in the metadata and the uneven detail.
• Hypotheses written in product language like "improve the user experience" instead of testable technical terms.
• Optimisation work with no real technical uncertainty, just trial and error across known options.
• Overseas development claimed with no DISR finding on file.

Build it with the trail already in place

We have shipped over 200 apps, including work for the NSW Government in Justice and Corrective Services, Briometrix, Vivid and Huskee.

The habit we keep coming back to is a small one. Log a hypothesis before a sprint starts. Write a short review note after it ends. It costs almost nothing, and it leaves behind exactly the evidence a claim needs.

If you're briefing an outside team, ask how they document technical uncertainty. Not just what they will ship.

The habit isn't unique to tax. Teams running agents in production already keep observability logs and evaluation frameworks because they can't debug without them. Same records, second use. If you're still weighing build versus buy, note that a bought tool rarely leaves you an experiment trail of your own.

Our AI app development work, our AI programs, and our custom software builds all separate the genuinely uncertain parts from routine feature work. You get a cleaner claim and a better engineered product from the same effort.

Scoping something new and want to know whether it clears the technical hurdle test before you commit budget? Talk to us and we will map it out with you.

Frequently asked questions

Does using a new AI model automatically qualify a project?

No. New to your team isn't enough. The work qualifies only if it solves a real technical problem through structured experiments, as set out in the business.gov.au software sector guide.

Is there a minimum spend to claim the R&D Tax Incentive?

Yes. You need eligible notional deductions above a minimum threshold in the income year, and you must be a registered R&D entity doing the work generally in Australia. Check the current threshold on business.gov.au, because it can change.

Can internal tools like dashboards or payroll systems qualify?

Generally no. Software built for the dominant purpose of internal business administration is excluded from core R&D. It can sometimes count as a supporting activity, but only where it directly serves a registered core activity.

What records do I need for an R&D tax claim?

Timesheets tagged to specific activities, experiment logs, and sprint review notes created at the time the work happened. Not rebuilt afterwards.

Can Devwiz help structure a project to be R&D eligible?

We build AI platforms and custom software with hypothesis documentation and experiment logging inside the delivery process. That gives you a cleaner evidence trail. We're not tax advisers, so your accountant still lodges the claim.