The four-gate test, explained for engineers (not accountants)

Whether a piece of work qualifies for the R&D Tax Incentive comes down to a test in the tax law (ITAA 1997 s355-25). It is usually explained by accountants, for accountants, which is why it feels abstract. But the test is really asking questions an engineer can answer better than anyone: did you know how this would turn out, and how did you go about finding out?

Here is the test in engineering terms. There are four gates. An activity has to pass all four to count as a "core R&D activity", and failing any one fails it.

This is general information, not tax advice. Your registered tax adviser determines and lodges your actual claim.

First, the distinction that frames everything: core vs supporting

The law splits R&D into core activities (the actual experiment) and supporting activities (work directly related to a core activity, like data prep or tooling). A valid claim needs at least one eligible core activity; supporting work hangs off it.

This matters more every year. Supporting activities are scheduled to be removed from the program from 1 July 2028, which makes the core experiment the whole game. So the four gates below, which define a core activity, are what you really need to understand.

Gate 1: Was the outcome genuinely unknown?

The first gate asks whether the outcome could have been known or worked out in advance, based on existing knowledge anywhere in the world. If a competent professional in your field could have determined the result without experimenting, it is not R&D.

The bar is technical uncertainty for a competent professional, not "we had not built it before" and not "it was hard". A senior engineer who has not used a particular framework still faces a learning curve, not technical uncertainty: the answer is knowable, it is just new to them.

The tell for genuine uncertainty in a codebase: revert chains, competing approaches tried and abandoned, spike branches, benchmarks that did not behave as expected. You were not just implementing a known solution; you did not know if the approach would work, and you had to find out.

Crucial distinction: technical, not commercial. "Will customers want this" and "can we ship by the deadline" are commercial unknowns. They do not count. The uncertainty has to be about whether a technical outcome is achievable.

Gate 2: Did you work systematically?

The second gate asks how you went about resolving that uncertainty. The law wants a systematic progression through, in order:

hypothesis -> experiment -> observation -> evaluation -> logical conclusions

Every element has to be present. In engineering terms: you had a stated expectation about what would work and why, you built something to test it, you captured what actually happened, you evaluated it against the expectation, and you drew a conclusion that informed the next step.

Two things engineers are often relieved to hear:

• A failed or surprising result still counts. Getting a different result than you predicted does not disqualify the work. The systematic progression is what matters, not whether the hypothesis held.
• A series of experiments testing the same idea can be grouped into one core activity. A genuinely different idea or hypothesis is a different core activity.

The catch is the next gate's close cousin: the hypothesis has to have come first.

Gate 3: Was the purpose to generate new knowledge?

The third gate is about why you did the work: it has to be conducted for the purpose of generating new knowledge (a new or improved material, product, device, process or service), not to confirm something already known or demonstrate existing knowledge.

Purpose is inferred from the evidence at the time the work started. This is why the hypothesis has to pre-date the experiment, with something to show it did. Reconstructing a tidy hypothesis months later, after the code already shipped, does not satisfy this gate, and it is exactly what reviewers look for.

An important subtlety from case law (Moreton Resources): "outcome unknown" (gate

1. and "new knowledge purpose" (gate 3) are separate, cumulative tests. You need both. And applying existing technology in a genuinely new context can still be core R&D, as long as all the requirements are met.

Gate 4: Is it not an excluded activity?

The fourth gate is a checklist. Some activities can never be core R&D, no matter how uncertain they felt. For software teams, the ones that bite:

• Software for your own internal administration. Building, modifying or customising software for the dominant purpose of your own internal admin (or a connected entity's) is excluded. This is the big one.
• Configuration and customisation of existing commercial platforms, which a competent professional can usually do with known techniques.
• Reproducing functionality from existing products or publicly available information.
• Routine development, testing, debugging and maintenance.

These can sometimes still qualify as supporting activities if they directly serve a core activity, but they are not core in their own right.

What this looks like in real software

To make it concrete, here is the same project passing and failing.

Passes the gates: an ML feature where it was genuinely unknown whether you could reach the target accuracy, so you formed a hypothesis about an approach, ran experiments, captured the metrics, evaluated them, and iterated to a conclusion. Or a novel algorithm or architecture with no known solution. Or performance and scaling at a combination no one had tested, where the outcome could not be predicted in advance.

Fails the gates: integrating that same ML model using standard methods once the approach is known, tuning with established techniques, and shipping it. No documented uncertainty, no up-front hypothesis, a straight-line implementation with no experimental iteration. That is routine development, however much skilled work it took.

The mistake the ATO is watching for

The single most flagged error is the whole-of-project claim: treating an entire platform or product build as R&D when only specific elements contain genuine experimentation. The claim has to isolate the specific experimental activities, not the whole program of work. With supporting activities sunsetting in 2028, isolating the genuine core experiments cleanly is becoming the entire exercise.

What you would actually keep as evidence

If your work passes the gates, what defends it is contemporaneous evidence:

• Background research from before you started, showing the outcome was not already known.
• The hypothesis, recorded up front.
• The experiment plan and the design of the systematic progression.
• The results of your runs and how you evaluated them.
• Version-control history, issue and ticket records, before-and-after states.

Most engineering teams generate almost all of this as a side effect of how they already work, in pull requests, commits and tickets. The hard part is not producing it; it is connecting it to the four gates after the fact. That is the job our tool does: it reads your development history, finds the candidate experiments, and walks you through substantiating each one against exactly these four gates, so your adviser gets a package they can defend.

This article is general information, not tax advice, and not a determination of eligibility. Speak to a registered tax adviser before lodging an R&D Tax Incentive claim.