Using your git history as R&D evidence: timestamps, PRs and the audit trail

The ATO wants contemporaneous records: evidence created at the time the work was done, not reconstructed later to fit a claim. Most software teams are sitting on a near-perfect example of exactly that and do not think to use it. Your git history is a timestamped, immutable, detailed account of what your engineers built, when, and how it evolved. Used well, it is one of the strongest substantiation assets you have.

This post is about how to read git history as R&D evidence: what signals point to genuine experimentation, why the timestamps matter so much, and where the evidence stops and human judgment has to take over.

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

Why git history is good evidence

Three properties make it valuable to a reviewer.

It is contemporaneous. A pull request from last March was created last March. It records what you knew and did at the time, which is precisely the standard the ATO applies to records. It cannot be back-filled to fit a claim, and that is what gives it weight.

It is granular and linked. Each pull request ties a specific change to a specific author, at a specific time, often with the review discussion and the ticket it came from attached. That supports the "expenditure tied to the activity" requirement: you can show which people worked on which experiment, and when.

It is hard to fake. The history is an append-only record across many contributors. The shape of the work, including the dead ends, is preserved.

What in your history points to genuine R&D

Not all activity is equal. Routine work and genuine experimentation leave different traces. The signals that suggest real technical uncertainty being resolved by systematic work:

• Revert chains and competing approaches. A feature reworked several times, approaches tried and abandoned, branches that explored alternatives. This is the fingerprint of an unknown outcome being worked out, not a known solution being implemented.
• Spike and experiment branches. Explicitly exploratory work, prototypes, proof-of-concept branches that test whether something is even possible.
• Benchmarks and measurement. Commits that add performance or accuracy measurement, then iterate against it, the systematic observe-and-evaluate loop in action.
• Sustained iteration on one hard problem. Many commits over weeks against the same component, with course corrections, rather than a single straight-line implementation.

And the traces that usually indicate routine work, not core R&D:

• Dependency bumps, lockfile-only changes, and docs-only changes.
• Straight-line implementation of a known approach with no iteration.
• Configuration and wiring of existing libraries and platforms.
• Bot-authored and purely mechanical changes.

Why the timestamps matter more than you would expect

One gate of the R&D test turns on purpose at the time the work started: was the activity conducted to generate new knowledge? That makes the order of events important. A hypothesis is only convincing if it pre-dates the experiment, and git history is unusually good at proving sequence. The commit that frames the problem, the spike that tests it, the implementation that follows: the timeline itself is evidence that you set out to resolve an uncertainty rather than reconstructing a rationale afterward.

Timestamps also scope the claim to the right income year. Because each artefact is dated, work can be allocated to a claim period by when it actually happened, and an activity that spans two years can be sliced by date rather than guessed at.

Where git evidence stops

This is the honest part, and it matters. Git history shows what changed and when, but it does not, on its own, prove the why. Code alone cannot tell a reviewer that you genuinely did not know the outcome in advance, or that you held a specific hypothesis before you started. Those are human facts that an engineer has to attest to, with the artefacts as support.

So git history is the evidence and the scaffold, not the claim itself. The strongest substantiation pairs the two: the contemporaneous artefacts that show the shape of the work, plus a named person attesting to the uncertainty and the hypothesis, with the basis of each figure recorded. Evidence and attestation together, neither alone.

There is also a deliberate limitation worth naming: genuine R&D effort that left no commit, such as whiteboard design, research reading, or running experiments by hand, is not visible in git. A conservative claim built from git history will tend to undercount rather than claim time the artefacts do not support, which is the safer side to err on.

How the tool uses it

This is the core of how our tool works. It ingests your pull requests (or your commit history, for repos that do not use them), filters out the obviously routine and mechanical changes, and surfaces the candidate experiments where the signals above show up. It then walks your engineers through attesting the uncertainty and hypothesis for each one, and ties every eligible hour back to the specific pull requests and the experiment they belong to. The result is an audit trail a reviewer can follow from any claimed figure down to the contemporaneous artefacts behind it.

Your history already holds the evidence. The work is connecting it to the test, and doing that honestly.

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.