All articles
Compliance & Evidence

Contemporaneous evidence for a defensible R&D claim

Eligibility gets you in the door. Evidence keeps you there. This guide covers what contemporaneous records the ATO and AusIndustry expect, the evidence hierarchy that holds up in a review, and the documentation habits that make a claim defensible.

Written and reviewed by George Walch, Founder and R&D Tax Expert, Rand Advisory(updated 13 June 2026)5 min read

Key takeaways

  • Evidence must be contemporaneous: created while the R&D happens. Retrospective write-ups will not sustain a claim.
  • The strongest records are generated by the work itself: pull requests, experiment logs, issue threads, and dated design discussions.
  • Time records linking each person's hours to specific activities are what convert eligible work into claimable expenditure.
  • Keep your failures. Dead ends are the best proof that the outcome could not be known in advance.
On this page

Most R&D Tax Incentive claims are not lost on eligibility. They are lost on evidence. A company does genuinely experimental work, claims it in good faith, and then cannot produce records made at the time that show what was uncertain, what was hypothesised, and what was learned. When AusIndustry or the ATO reviews the claim, the activity may have been eligible, but it cannot be substantiated. The result is the same as if it had never qualified.

This guide explains what "contemporaneous" actually means, the hierarchy of evidence that holds up, and the documentation habits that turn a plausible claim into a defensible one.

The one rule to remember

Evidence must be contemporaneous: created at the time the R&D was done, not assembled afterwards. A polished narrative written the week before you lodge will not sustain a claim. Records generated as the work happened will.

Why do contemporaneous records matter?

Because a review asks a question only they can answer: can you show that you did this specific experimental work, in this year, in this way? The R&DTI is a self-assessment program, and AusIndustry and the ATO retain full authority to review, audit, or amend any claim. In a review, the question is rarely "is this kind of work eligible in principle?" It is "can you show that you did this specific experimental work, in this year, in this way?" That is a question only contemporaneous records can answer.

Retrospective summaries fail for a specific reason: they cannot demonstrate that the uncertainty was real at the time. With hindsight, every solved problem looks knowable. The records that prove it was not knowable in advance, the dead ends, the failed hypotheses, the design debates, are exactly the ones companies forget to keep.

What is the evidence hierarchy?

Not all evidence is equal. Reviewers weight records by how directly and how contemporaneously they show the experiment. A rough hierarchy, strongest first:

  1. Records generated by the work itself, time-stamped. Pull requests, commit history, issue threads, design documents, experiment logs, test results, and the dated discussion around them. These are the gold standard because they are created as a byproduct of doing the work.
  2. Project and planning artefacts. Sprint boards, technical specs, architecture decision records, and meeting notes that capture uncertainty and direction.
  3. Financial records tying effort to activity. Time records showing who worked on which experiment and for how long, linked to payroll, are what convert eligible activity into a substantiated dollar figure.
  4. Contemporaneous written narrative. Notes written at the time describing the hypothesis and outcome.
  5. Retrospective explanation. Useful for context, weak on its own. Never the foundation of a claim.

Software companies have an advantage here

If you develop software, you are already generating top-of-hierarchy evidence every day in GitHub, Jira, and your CI system. The challenge is not creating evidence, it is linking it to the right activity, the right person, and the right hours before it scatters and the context is lost.

What does a reviewer want to see?

For each core activity, AusIndustry and the ATO are looking for a clear chain:

  • The technical uncertainty. What could not be known or done with existing knowledge?
  • The hypothesis. What did you propose to try, and why?
  • The experiment. What did you actually do, in a systematic progression?
  • The observations and evaluation. What happened, including failures?
  • The conclusion and new knowledge. What did you learn?

If you map your evidence to these five points for each activity, you have a defensible claim. If you have a pile of receipts and a confident story, you do not.

What fails in a review?

The common failure modes are predictable:

  • Effort mistaken for experimentation. Lots of hard work, no documented uncertainty or hypothesis. See our software eligibility guide for the distinction.
  • No link between hours and activities. Salaries are usually the largest claim component, and an unsubstantiated time apportionment is the fastest way to lose them.
  • Reconstructed records. Narratives clearly written after the fact, with no contemporaneous trail behind them.
  • Missing the failures. Only documenting what worked. The dead ends are often your best proof that the outcome was genuinely uncertain.
  • Generic descriptions. "We improved performance and scalability" tells a reviewer nothing about the experiment.

Building the habit, not the scramble

The companies that sail through reviews are not the ones with the best memory at lodgement time. They are the ones who captured evidence continuously, as a low-effort byproduct of how they already work. Three habits make the difference:

  1. Capture at the source. Tie evidence to the activity when the work happens, not in a year-end reconstruction. A short note on a pull request about the uncertainty you were resolving is worth more than a page written later.
  2. Record time against experiments. Every R&D hour should be attributable to a specific activity and person. This is the bridge from "eligible work" to "claimable expenditure."
  3. Keep the failures. Treat dead ends as assets. They are some of your strongest evidence that the outcome could not be known in advance.

Why this matters more from 2028

The 2026-27 Budget narrows the program toward core experimental activity and removes supporting activities from 1 July 2028. A tighter definition raises the bar on how cleanly you describe and evidence the experimental core. The documentation discipline that is good practice today becomes essential under the new design. Building the habit now is the cheapest way to be ready.

Start with one activity

You do not need a perfect system overnight. Pick your most significant R&D activity and write the five-point chain for it: uncertainty, hypothesis, experiment, observation, conclusion. If you can fill it with contemporaneous evidence, you have a model for the rest. If you cannot, you have found your gap while there is still time to close it.

The R&DTI is a self-assessment scheme. Rand helps you prepare and document a defensible claim, but you and your directors remain responsible for its accuracy, and you should seek independent advice for your circumstances.

ShareLinkedIn𝕏X

Frequently asked questions

What does contemporaneous evidence mean?
Records created at the time the R&D was done, as a byproduct of doing it: pull requests, experiment logs, issue discussions, design notes, test results, all dated. A narrative written the week before you lodge is not contemporaneous and will not sustain a claim.
What records do AusIndustry and the ATO expect?
For each core activity, a chain showing the technical uncertainty, the hypothesis, the systematic experiment, the observations including failures, and the conclusions. For expenditure, time records tying each person's hours to specific activities, linked to payroll.
Are retrospective summaries acceptable evidence?
On their own, no. They are useful context but cannot demonstrate the uncertainty was real at the time, because hindsight makes every solved problem look knowable. Reviewers weight them lowest in the evidence hierarchy.
How should a software company capture R&D evidence?
Use what you already produce. GitHub, Jira, and CI generate top-of-hierarchy evidence every day; the work is linking each record to the right activity, person, and hours before the context scatters. A short note on a pull request about the uncertainty being resolved is worth more than a page written later.

Keep reading