Quick answer: From day one, capture the things that are cheap to record now and impossible to recreate later: the technical question or unknown you're facing, the hypotheses you form, what you tried and varied, the results — including the failures — and the decisions you made with their dates. You don't need to have decided you'll claim. Contemporaneous notes made while the work happens are far more credible than a narrative reconstructed at tax time, so start the habit before you know whether it becomes a claim.
Most advice about R&D evidence is written for the wrong moment. It tells you what to produce at claim time — the memos, the apportionment method, the bundle a reviewer wants to see. That's useful, but it arrives a year too late for the thing that actually decides whether your evidence is strong: whether it existed while the work was happening. This article is about the other end of the timeline — the day-one habit of capturing evidence as you go, before you know whether the project will ever become a claim.
The premise is deliberately forward-looking. You rarely know on day one whether a piece of technical work will turn into an R&D Tax Incentive claim. The pragmatic answer isn't to decide early and document only the "R&D" projects — it's to make lightweight evidence capture a default habit across your technical work, so that if a project turns out to involve eligible R&D, the record already exists. Eligibility is always self-assessed against your circumstances; this is general information from a Registered Research Service Provider, not tax advice.
Start Recording Before You Decide You're Claiming
The instinct is to wait: get through the messy early experiments, see if the idea works, and write it all up later if it looks claimable. That instinct is exactly backwards. The early, uncertain, "we don't know if this will work" phase is where the most valuable evidence lives — because that uncertainty is what the law is asking about. By the time you've decided the project is worth claiming, the team has usually solved the problem, moved on, and lost the record of why it was ever unknown.
So the rule of thumb is simple: record as if you might claim, decide later whether you do. The cost of keeping a few extra notes on a project that never becomes a claim is trivial. The cost of not keeping them on one that does is a reconstruction exercise from memory — the single weakest form of evidence under a self-assessment program.
Why Contemporaneous Beats Reconstruction
A record made while the work happens carries weight for a reason a reviewer can see: the timeline itself is evidence. A hypothesis written before an experiment, results captured during it, and a conclusion drawn after provides a much stronger and more credible chronology than a narrative first prepared at year-end. A polished narrative dated the week before lodgement tells the opposite story.
Reconstruction fails in three predictable ways. Memory smooths over the failed attempts — and failed attempts are often your best proof that the outcome genuinely couldn't be known in advance. Dates blur, so the systematic progression from question to conclusion collapses into "we built it and it was hard." And the people who did the work move on, taking the reasoning with them. None of that is recoverable later at any price. Capturing it as you go is nearly free.
An Evidence Timeline: What to Record, and When
The most useful way to hold the day-one habit in your head is as a timeline that mirrors the experiment itself — something to note before you start, during the work, and after you have a result. Each stage records a different kind of evidence, and each is far cheaper to capture in the moment than to reconstruct:
When
What to record
Example
Before experiment
The unknown and the hypothesis
“We expect X to handle constraint Y, because…”
During experiment
Inputs, variables and observations
Dataset / version / configuration used, and what you changed between attempts
After experiment
The result and the conclusion
Hypothesis supported or rejected, and why — including dead ends
Used consistently, this before / during / after rhythm produces exactly the progression a reviewer looks for: a technical unknown, a proposition tested, observations gathered systematically, and a conclusion reached on the evidence. It also makes the failures legible, which matters — under the incentive, a rejected hypothesis is evidence that the outcome genuinely couldn't be known in advance, not a gap to hide.
The Five Things to Capture From Day One
You don't need a bespoke system or a heavy template. You need to be able to answer five questions for any technical project, captured in whatever tools the team already uses:
1. The question or unknown. What are you trying to find out that you can't answer from existing knowledge or off-the-shelf methods? One or two dated sentences framing the technical question — not the commercial goal — is enough to start.
2. The hypotheses. What did you think would work, and why? Even a rough “we expect approach X will handle constraint Y” logged before you try it is gold, because it shows you were testing a proposition, not just building.
3. What you tried and varied. The approaches you tested, what you changed between attempts, and what you held constant. This is the systematic-progression thread, and it's the one reconstruction destroys.
4. The results — including failures. What actually happened versus what you predicted. Dead ends and rejected approaches are evidence, not embarrassments; the incentive doesn't require success, and failures often prove the uncertainty was real.
5. Decisions and dates. What you concluded, what you decided to do next, and when. A dated decision trail is what turns scattered notes into a followable progression.
Make It Low-Friction, Not a Second Job
Evidence capture fails when it competes with the work. The trick is to let it fall out of tools the team is already in rather than adding a parallel process:
Use what's already there. Commit messages, pull-request descriptions, issue-tracker tickets, design docs, experiment notebooks, Slack threads and meeting notes are all contemporaneous records if they capture the question, the attempt and the result. These tools can contain useful contemporaneous evidence, but their value depends on whether the content actually records the uncertainty, hypothesis, work performed, observations and conclusions. You mostly need to make them a little more explicit, not create something new.
Timestamp naturally. Dated tickets, version history and message threads timestamp themselves. Favour tools that do this for you over a document someone has to remember to date.
Write one line, not one report. A single sentence — “trying X because Y; expected Z” — on a ticket at the start of a task, and a one-line result at the end, can help preserve the outline of the progression, provided the underlying technical records and results are retained. The goal is a by-product of doing the work, not a homework assignment.
Name a light owner. Someone on the technical side who nudges “did we note why we tried that?” once a fortnight keeps the habit alive without turning it into governance.
Done this way, the record largely writes itself — and at claim time you're editing an existing trail, not inventing one.
Where an RSP Fits — and What This Isn't
Two clarifications matter. First, this day-one habit is about building the trail; it is not the full compliance standard. For the complete list of records the ATO expects at claim time — the activity-and-expenditure evidence, apportionment method and retention rules — see our companion piece on record-keeping and the evidence the ATO expects, and our self-assessment walkthrough. Second, keeping good records does not make a project eligible: eligibility is self-assessed against the law, and a strong record trail simply lets you substantiate a position you've assessed on its merits.
The distinct value in engaging early is that the evidence system and the research governance get set up before the first experiment, not after. As a Registered Research Service Provider (RSP000047, based at Lot Fourteen in Adelaide), Ignition Research works through research framing to stand up the question, the experimental approach and the record trail together — an evidence framework the team can run inside its own tools, so the record accrues as a by-product of the research rather than a year-end reconstruction. That's a research-side registration and capability, not a government endorsement or a guarantee that any activity qualifies.
Set up an evidence framework before experimentation starts. We help stand up a low-friction capture habit and research governance so your record is strong from day one.
Frequently Asked Questions
Q: What should I document at the start of an R&D project?
A: The five things that are cheap now and impossible to recreate later: the technical question or unknown you're facing, the hypotheses you form, what you tried and varied, the results (including failures), and your decisions with their dates. Capture them in the tools you already use — tickets, commits, design docs — so it's a by-product of the work. Eligibility is self-assessed, so confirm your position with your own adviser.
Q: Do I need to decide I'm claiming before I start recording?
A: No — and waiting until you've decided is the common mistake. The most valuable evidence lives in the early, uncertain phase, before you know whether the project is claimable. Make lightweight capture a default habit across your technical work, then decide later whether any of it becomes a claim.
Q: Why are contemporaneous records better than reconstruction?
A: Because the timeline itself is evidence. A hypothesis logged before an experiment and results captured during it show a genuine progression that is far harder to reconstruct convincingly at year-end. Reconstruction loses the failed attempts, blurs the dates, and walks out the door when the people who did the work move on — none of which is recoverable later.
Q: How do I keep R&D evidence without slowing the team down?
A: Let it fall out of tools the team already uses. A one-line “trying X because Y, expected Z” on a ticket at the start of a task and a one-line result at the end preserves the outline of the progression, as long as the underlying technical records are kept. Favour dated, self-timestamping tools like issue trackers and version history over a separate document someone has to maintain.
Sources & Further Reading
Records to show your R&D activities are eligible (business.gov.au)
Keeping records and calculating your notional deductions (ato.gov.au)
Income Tax Assessment Act 1997 s 355-25 — core R&D activities (Federal Register of Legislation)
Related: Evidence & audit-readiness · Research framing · R&DTI self-assessment · Registered Research Service Provider
Note: this article describes the current rules. Changes to the R&D Tax Incentive proposed to commence from 1 July 2028 are, at the time of writing, proposals only and not yet law.
This article is general information from a Registered Research Service Provider about the R&D Tax Incentive. It is not tax, legal or financial advice; eligibility depends on your circumstances and you should self-assess and seek your own advice.
