Quick answer: From day one, capture the information that is easier and more reliable to record while the work is underway than to reconstruct 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 that you'll claim. Contemporaneous records generally provide stronger support than a narrative reconstructed at tax time, so start the habit before you know whether the work will form part of a claim.
Much of the practical guidance on R&D evidence focuses on what is required at claim time — the activity records, apportionment method and supporting material a reviewer may expect to see. That guidance is useful, but it may come too late to address whether accurate records were created while the work was underway. This article focuses on the other end of the timeline — the day-one habit of capturing evidence as you go, before you know whether the project will form part of 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 generally 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 may be to wait: get through the messy early experiments, see if the idea works, and write it all up later if it appears potentially claimable. However, the early uncertain phase can contain important evidence, including why the outcome could not be known or determined in advance and how the hypothesis was developed and tested. By the time the business decides that the activities may warrant assessment, the team may have solved the problem, moved on or lost some of the original reasoning and context.
So the rule of thumb is simple: record as if you might claim, then decide later whether you do. The additional effort involved in maintaining brief records may be limited when evidence capture is incorporated into the team's existing workflow. Without those records, later substantiation may depend heavily on reconstruction from memory, which generally provides weaker support than contemporaneous documentation.
Why Contemporaneous Beats Reconstruction
A record made while the work is underway can carry weight because its dates and sequence help support the chronology of the activity. A hypothesis recorded before an experiment, results captured during it and a conclusion documented afterwards can provide a clearer and more credible progression than a narrative first prepared at year-end. A later narrative may still be useful, but it should be supported by the underlying contemporaneous records.
Reconstruction can create three recurring problems. Memory may smooth over failed attempts, even though those attempts can help show what was tested and observed. Dates may blur, causing the progression from question to conclusion to become less clear. The people who performed the work may also move on, taking some of the original reasoning with them. Some of this detail can be difficult to recover later, while capturing it as the work proceeds is generally more reliable.
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 generally easier and more reliable to capture in the moment than to reconstruct later.
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 can help demonstrate the relevant progression: a technical unknown, a proposition tested, observations gathered systematically and a conclusion reached on the evidence. It also makes failed approaches and rejected hypotheses visible. Those records can help demonstrate what was tested and observed, but a rejected hypothesis does not, by itself, establish that the outcome could not have been known or determined in advance.
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 could not be answered from publicly available or reasonably accessible knowledge, information or experience? 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 can be useful, 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 helps demonstrate the systematic progression and can be difficult to reconstruct accurately later.
4. The results — including failures. What actually happened versus what you predicted. Dead ends and rejected approaches are evidence, not embarrassments. Dead ends and rejected approaches can help document the systematic progression of work, but they do not, by themselves, prove that the outcome could not have been known or determined in advance.
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 can be maintained progressively, so at claim time you are organising and reviewing an existing trail rather than reconstructing it from the beginning.
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 broader activity and expenditure record requirements relevant to registration and claiming — including apportionment and retention requirements — see our companion piece on record-keeping and the evidence the program administrators may require, together with our self-assessment walkthrough.
Early engagement may allow the evidence system and research governance to be established before experimentation begins. As a Registered Research Service Provider (RSP000047) based at Lot Fourteen in Adelaide, Ignition Research supports research framing, experimental planning and evidence systems within its registered research fields. This may include defining the technical question, planning the experimental approach and establishing a record trail that the team can maintain through its existing tools.
RSP registration confirms that the provider has met the applicable registration requirements for its registered research fields. It does not constitute government endorsement of a particular project or guarantee that any activity will qualify for the R&D Tax Incentive.
Set up an evidence framework before experimentation starts. We help establish a low-friction evidence-capture process and research governance framework that supports contemporaneous record keeping 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 easier and more reliable to capture contemporaneously than to reconstruct 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 — Waiting until a claim decision has been made can result in important early evidence being lost. The early uncertain phase may contain records relevant to the technical unknown, hypothesis and experiments, even before you know whether the activities will form part of a claim. Making lightweight evidence capture a routine part of technical work allows the eligibility and claiming decision to be made later using the available records.
Q: Why are contemporaneous records better than reconstruction?
A: Because the dates and sequence of the records can help demonstrate the progression of the activity. A hypothesis logged before an experiment and results captured during it generally provide clearer support than a narrative reconstructed at year-end. Reconstruction may omit failed attempts, blur dates or lose some of the reasoning held by the people who performed the work.
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: The Australian Government announced reforms to the R&D Tax Incentive in the 2026–27 Budget, intended to apply to income years starting on or after 1 July 2028. Until those changes take effect, the program continues to operate under the current legislation. Readers should check the latest official guidance before relying on the future measures.
This article provides general information only and does not constitute tax, legal or financial advice. Eligibility for the R&D Tax Incentive depends on the specific entity, activities, expenditure and circumstances involved. Businesses should assess their circumstances against the legislation and current official guidance and obtain independent professional advice where appropriate.
Working on a project like this?
Tell us what you're building and the part you're not sure will work. A researcher from our Adelaide team (registered Research Service Provider RSP000047) reads every enquiry and replies within two business days. No documents needed.
