Is My AI Project Eligible for the R&D Tax Incentive?
Probably not, and this page is written to talk more readers out of it than into it. Most software and AI work in Australian businesses is competent application of things that are already known, which is exactly what a business should be buying, and exactly what does not qualify as a core R&D activity.
The rest of this page gives you the test the way a technical person would apply it, with worked examples of the calls that go each way. Before you read any of it, understand the boundary: we are not accountants and not registered tax agents. We do not assess eligibility, we do not give tax advice, and we never tell a client they will receive an offset. AusIndustry and the ATO determine eligibility. Your own accountant or a registered tax agent who specialises in R&D substantiates and lodges the claim. Worth knowing: there is no separate register of R&D advisers, so registration as a tax agent with the Tax Practitioners Board is the credential to check. What we can do is tell you honestly whether the build we are about to do contains anything genuinely uncertain, and record it properly if it does.
Realistic ROI
The Test, Applied the Way an Engineer Would Apply It
Four questions. If you cannot answer all four cleanly, the work is very likely ordinary development. General information only, not tax or financial advice.
Could the outcome have been known in advance?
This is the question that decides almost every software case. Not whether your team knew, but whether a competent professional in the field, working from publicly available knowledge, could have determined the result before starting. If the approach is documented in vendor material, described in published work, discussed in the open by people solving the same problem, or reliably predictable from experience, the outcome was knowable. A great deal of AI work fails here quietly, because the model provider has already published the technique you are about to apply.
Was it resolved by a systematic progression of experiments?
Eligible experimental activity looks like a designed sequence, based on principles of established science and carried out in the order business.gov.au sets out: hypothesis, experiment, observation, evaluation, logical conclusions, then the next question. It does not look like a developer trying several libraries until one behaved. Those two weeks can feel identical from the inside, and they are not the same thing on paper. If nobody wrote down what was expected before the test ran, it is very difficult to argue afterwards that the work was systematic rather than iterative tinkering.
Was the purpose to generate new knowledge?
Core activity is undertaken for the purpose of generating new knowledge, including new or improved processes, materials, devices or services. Building a system so your business can process orders faster is a commercial purpose achieved with existing knowledge, however new the system is to you. The distinction people find hardest is that a genuinely useful, genuinely novel product can be built entirely from known parts, and building it well is not research. Novelty in the market is not the same as novelty in the field.
What the Act excludes, and what simply fails the test
These are two different things and people routinely merge them. The Act excludes a specific list from being core activity, and the software item on it is narrower than most people assume: developing, modifying or customising software for the dominant purpose of use by you, or by an entity connected with or affiliated with you, for internal administration. Software you build to sell to unrelated businesses is not caught by that exclusion, even if those businesses use it to run their own admin, so a product or SaaS vendor should not rule itself out on this ground. Other items on the statutory list that come up in software work: market research, market testing and sales promotion; management studies and efficiency surveys; research in the social sciences, arts or humanities; the commercial, legal and administrative aspects of patenting and licensing; complying with statutory requirements or standards, including routine testing; and reproducing a commercial product from plans, specifications or publicly available information. Separately from that list, quality control of ordinary production, adapting existing software for a new customer, data mapping and migration and routine debugging and maintenance are not statutory exclusions at all. They simply fail the outcome unknown test on their own merits, which is a different argument and a harder one to win. Supporting activities can sometimes be claimed where they are directly related to a core activity, but they never stand alone, and where the supporting work produces goods or services, or is itself on the excluded list, it has to have been done for the dominant purpose of supporting the core activity rather than merely running alongside it. That second gate catches a lot of ordinary delivery work.
Worked Calls: Where the Line Usually Falls
These are illustrative technical judgements, not eligibility rulings. Your adviser makes the actual call, and the facts of your project will differ.
Connecting two business systems
Reading orders out of one platform and writing them into another using documented interfaces is ordinary development, even when the mapping is tedious and the edge cases are painful. The outcome was knowable: both vendors publish what their systems accept. Difficulty is not uncertainty. This is the single most common project we are asked about in this context and the answer is almost always no, which is worth knowing before anyone pays an adviser to look at it.
Adding a chatbot using a published model
Applying a commercially available language model through its documented interface, with prompts and retrieval configured the way the vendor describes, is applying known techniques. The vendor has published the approach and thousands of businesses have implemented it. That it is new to your organisation and produces a genuinely valuable result does not change the analysis, and describing the configuration work as research is the kind of overreach that invites a review you would deserve.
Fine tuning on your own data to a documented recipe
Following a published fine tuning process on proprietary data generally applies existing knowledge to a new dataset. It becomes more interesting only if the data has properties that make the documented approach fail in a way nobody has resolved publicly, and you can show you looked. Even then the eligible activity is likely to be a narrow slice of the work rather than the whole exercise, and the surrounding data preparation is supporting activity at best.
A model that must work on genuinely unusual data
Where the available techniques are documented to fail on your class of input, and no published approach resolves it, and you design a sequence of experiments to find out whether a novel combination holds accuracy above a stated threshold, there may be a core activity in there. The eligible part is the experiment and its immediate support, not the twelve weeks of interface work around it. Write the hypothesis before you run anything, because you cannot construct that evidence later.
Making something fast enough to be possible at all
Performance work is usually engineering: profile, optimise, cache, and the outcome is broadly predictable. It moves towards experimental only when the required target is beyond what the current publicly known approaches achieve, when nobody can tell you in advance whether it is achievable, and when you test that systematically. Wanting something to be faster is not uncertainty. Not knowing whether it can be done at all, and having checked, might be.
Rebuilding a system you already run, on new technology
Replatforming, migrating and modernising are among the clearest cases where the outcome was knowable in advance. They are not on the Act’s excluded list, they simply fail the first test, and that is a harder answer to argue with. The functional outcome is known because the existing system defines it, and the target technology is documented. These projects are frequently the largest, hardest and most valuable thing a business does in a given year, which makes the answer feel unfair, and it is still the answer. Size and risk are not the test.
Signals That Point Each Way
| Task | Traditional | How it usually lands | Notes |
|---|---|---|---|
| Nobody could tell you if it would work | A published approach exists | Points towards experimental | Search first. Finding the published answer saves both the claim and often the build. |
| You wrote down what you expected | Written up after the fact | Points towards experimental | A hypothesis recorded before the test is the strongest single indicator of systematic work. |
| Some attempts failed and you kept the evidence | Everything worked first time | Points towards experimental | A record where nothing ever failed does not describe an experiment. |
| The work was hard and took months | Effort mistaken for uncertainty | No signal either way | Difficulty, cost and duration are not part of the test at all. |
| It is new to your industry in Australia | Known elsewhere in the field | Points away from eligible | The knowledge base is the field, not your market or your competitors. |
| A vendor documents the approach you used | Following the documentation | Points away from eligible | If the recipe was published, the outcome was knowable. |
| You are migrating or replatforming | Outcome defined by the old system | Points away from eligible | Not on the excluded list. It fails the outcome unknown test instead, whatever the project size. |
| You cannot name the specific unknown | Broad narrative about the project | Points away from eligible | If you cannot state it in one sentence, an assessor will not find it either. |
Reasons to Walk Away From a Claim
The adviser fee exceeds the plausible benefit
Preparing a defensible registration takes real work: identifying activities, apportioning expenditure, assembling evidence and writing the narrative. On a small amount of genuinely experimental expenditure, the adviser fee plus your own internal time can consume most of the offset, and you have taken on review exposure for very little. Ask your adviser for a plain view on whether the claim is worth making before you commit, and be prepared to hear no.
You are being told the answer before anyone looked
Be sceptical of any supplier who tells you your project qualifies, quotes you an expected refund, or offers to handle both the build and the claim with an assurance attached. Eligibility is determined by AusIndustry and the ATO on the facts, and nobody can promise you an outcome. The risk of an overstated position falls on the company and its directors, not on the person who wrote the flattering narrative and moved on.
The record would have to be reconstructed
If the work is finished and nothing was written down at the time, what you can produce is a reconstruction: a narrative built from memory, commits and invoices. It is weaker evidence, it is more expensive to produce, and it tends to describe the work as more systematic than it was because you now know the answer. Where the only available material is a reconstruction, think hard about whether the claim is worth the exposure.
The activity is excluded, or it fails the test on its own merits
Two separate reasons a claim dies, and it pays to know which one you are facing. The statutory exclusions include market research and sales promotion, management studies and efficiency surveys, complying with statutory standards, and software developed for the dominant purpose of internal administration by you or an entity connected with or affiliated with you. That last one does not catch software you build to sell to unrelated businesses. The other category is work that is not excluded by the Act but still fails the outcome unknown test: quality control of ordinary production, routine debugging and maintenance, data migration, replatforming, and adapting existing software for a new customer. Either way, no amount of careful writing changes the underlying facts, and the effort spent arguing it is effort not spent on the build itself.
Your evidence lives with a supplier who has finished
Where the experimental work was done by an external team, the version control history, evaluation runs and decision records may sit in their systems. Once the engagement ends, retrieving that material gets progressively harder. Make ownership of the record an explicit part of the engagement, receive it as you go rather than at the end, and have someone internal read it while the work is still fresh enough to question.
The claim is being used to justify the project
If a build only makes commercial sense assuming a refund arrives, that is a financing decision dressed up as a technical one. Offsets are not certain, timing varies, and eligibility is decided by others. Decide whether the project earns its keep on its own merits, get your accountant and your board across the funding question separately, and treat any claim as an upside rather than a line in the business case.
What We Will and Will Not Tell You
We will tell you when there is nothing here
On most projects we look at, our honest technical read is that the work applies known techniques and the outcome was knowable in advance. We say that early, in writing, before anyone spends money exploring a claim. It is the least commercially convenient thing we can say and it is usually the correct one.
We do not assess eligibility or give tax advice
We are not accountants and not registered tax agents. Nothing on this page or in a scoping conversation is an eligibility assessment, tax advice or financial advice, and we will never tell you that you will receive an offset. AusIndustry and the ATO determine eligibility. Your accountant or a registered tax agent who specialises in R&D substantiates and lodges any claim.
Where uncertainty is real, we record it properly
If a build does contain a genuine technical unknown, we write the hypothesis before the experiment, log the design, capture the observations including the failures, and record the conclusion, dated as it happens with the artefacts attached. Your adviser gets material they can work from instead of an interview and a reconstruction.
We work to your adviser’s requirements, not ours
Different advisers want different evidence in different formats. We would rather your accountant or the registered tax agent handling your R&D tells us what they need at the start of the build than have us hand over a template of our own at the end. If you do not have one and the question looks live, engage one before the work starts, and check the registration on the Tax Practitioners Board register while you are at it.
How We Work Out Whether There Is Anything Here
Five steps, most of which end at step two with a no. General information only, not tax or financial advice.
State the unknown in one sentence
If the technical uncertainty cannot be written as a single specific question with a measurable answer, there is very likely no core activity. Vague statements about complexity and integration difficulty do not survive this step, and that is the point of doing it first.
Search for the published answer
We look for whether the field has already solved it: vendor documentation, published work, open discussion among people with the same problem. Finding the answer here is a good outcome twice over, because it closes the R&D question and usually shortens the build.
Separate the experiment from the engineering
Where something genuinely uncertain survives, we mark out the narrow slice that is experimental and the much larger surround that is ordinary build. Keeping them separate from day one is what makes a conservative, defensible record possible later.
Hand the question to a registered tax agent
Your accountant or a registered tax agent who specialises in R&D makes the eligibility call and tells us what evidence they want. We write to their requirements. If you do not have one, this is the point to engage one rather than after the income year closes.
Record it as it happens, or not at all
Hypothesis before the test, results including failures logged the same week, evidence attached and dated by the systems producing it, apportionment recorded as time is spent. If nobody in your business will own that habit, say so now and we will drop the whole idea.
Related Reading
R&D Tax Incentive and AI Build Work
What the incentive is, and what a contemporaneous record actually contains.
How to Write an AI Project Brief
Stating the unknown and the success measures before anyone starts building.
AI Pilot to Production Checklist
Turning a successful experiment into something you can actually rely on.
Custom LLM Development
Where real technical uncertainty does and does not show up in model work.
AI Strategy for Australian SMEs
Choosing work that pays for itself without needing a tax outcome.
AI for CFOs and Finance Teams
The finance view, including who should own the evidence trail.
FAQ
Want a Straight Answer on Whether There Is Anything Here?
Book a call and describe the build. If the work applies known techniques, we will tell you so and you can stop thinking about it. If there is a real unknown, we will record it properly from day one. General information only, not tax or financial advice. Phone (03) 9003 0111.
All discussions held in confidence. Australian-based consultants.