What good R&D substantiation looks like (and what gets claims knocked back)

A R&D Tax Incentive claim is only as good as the evidence behind it. You can have genuinely eligible work and still lose the claim if you cannot show, after the fact, that it met the test. Substantiation is that showing, and for software companies it is where most of the risk lives.

This post covers what good substantiation actually looks like, the records that hold up, and the gaps that get claims reduced or denied.

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

What substantiation is really for

When the ATO looks at a claim, it is asking two questions: was this activity genuinely eligible R&D, and was the expenditure genuinely tied to it? Good substantiation answers both with evidence created at the time the work was done, not with a story assembled later.

The phrase that matters is contemporaneous records. A document written while the work happened, a pull request from the week you built it, a ticket from when you scoped it, carries weight precisely because it could not have been back-filled to fit the claim. A polished narrative produced months afterward does not.

What good substantiation looks like, gate by gate

A defensible core R&D activity needs evidence against each part of the test. In practice that means keeping:

For "the outcome was unknown":

• Background research from before you started: the competitor products, prior art, and literature you checked that showed the answer was not already known anywhere. This is what demonstrates genuine technical uncertainty rather than "new to us".

For "we worked systematically":

• The hypothesis, recorded up front, stating what result you were aiming for and why you thought it achievable.
• The experiment plan and the design of the progression.
• The results of your runs and how you evaluated them against the hypothesis, including the runs that failed or surprised you.

For "the purpose was new knowledge":

• Evidence of intent at the start: the problem framing, the ticket or design doc that shows you set out to create something new, not to confirm a known fact.

For "expenditure tied to the activity":

• A clear link from each dollar claimed to the specific registered activity: which people, how much of their time, on which experiment, and on what basis you apportioned it.

The unifying idea: a reviewer should be able to start from any claimed figure and trace it back to a specific activity and the contemporaneous artefacts that evidence it.

What gets claims knocked back

The failure modes are consistent, and most are about weak evidence rather than ineligible work.

The whole-of-project claim. Treating an entire platform build as R&D when only specific elements were experimental. The ATO has flagged this explicitly. Good substantiation isolates the genuine experiments; it does not blanket the project.

A hypothesis that did not pre-date the work. If the only record of your hypothesis appears after the code shipped, the "purpose of new knowledge" gate is hard to defend. Reviewers look for a contemporaneous artefact that predates the implementation.

Weak linkage between cost and activity. A big expenditure figure that cannot be tied, person by person, to specific registered activities is a classic concern. "We spent this much on engineering" is not the same as "this much time, by these people, went into this experiment".

Inappropriate apportionment. Claiming too high a share of people's time, with no reasonable documented basis for the split. For a maturing product the genuine R&D share is usually lower than teams first assume.

Commercial uncertainty dressed as technical. Records that describe market or delivery risk rather than a genuine technical unknown.

Explanation instead of evidence. A well-written narrative with nothing contemporaneous behind it. The standard is evidence, not eloquence.

Why software teams are better placed than they think

Here is the good news. Most of the evidence the ATO wants is something engineering teams already generate as a by-product of how they work: pull requests and commits with timestamps, code review discussion, issue and ticket history, before-and-after states, the revert chains and spike branches that show where the real uncertainty was. This is contemporaneous by definition, created at the moment the work happened.

The hard part is not producing the evidence. It is connecting it to the test after the fact: deciding which pull requests belong to which experiment, mapping each to the four gates, and apportioning time on a basis a reviewer will accept.

That is exactly what our tool does. It reads your development history, isolates the candidate experiments, walks you through substantiating each one against the gates, and ties every eligible hour back to the specific pull requests and experiment it came from. The output is a package built around evidence, with the basis of every figure recorded, so your adviser gets something they can defend rather than a story they have to take on trust.

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.