Using GitHub commits as R&D evidence is legitimate: commit history is contemporaneous, attributed, and one of the few records most software teams already produce without being asked. What it cannot do is carry the claim alone.
Commits prove that work happened, when, and by whom. They rarely prove that the outcome was unknown in advance or that a hypothesis was formed before the code was written, and those are the limbs on which claims actually fail.
What commits prove, and what they don't
A commit is a timestamped, attributed record of a change that is difficult to alter without leaving a trace. That makes it excellent evidence of the observation stage of a systematic progression of work, and of the expenditure nexus (who spent time on what). It is weak evidence of the two things AusIndustry scrutinises hardest: that a competent professional could not have known the outcome in advance, and that a hypothesis existed before the experiment.
The test in s 355-25(1) of the Income Tax Assessment Act 1997 requires experimental activities whose outcome cannot be known in advance, determined by a systematic progression that proceeds from hypothesis to experiment, observation and evaluation, and leads to logical conclusions. A repository shows the middle of that arc clearly and the ends barely at all.
Does AusIndustry accept GitHub commits as evidence?
Yes. No tool is mandated by the legislation or by AusIndustry, and the business.gov.au R&D Tax Incentive guidance and the ATO's guidance on keeping records and calculating your notional deductions both describe categories of records rather than named systems.
Version control is accepted for the same reason lab notebooks are: it is created at the time, it is hard to alter innocently, and it is attributable to a person. The requirement is contemporaneity, not format, so records must be made while the R&D is being conducted and kept for at least five years after the claim is made.
In Absolute Vision Technologies [2022] AATA 2319, documents prepared after the fact for an internal review were not accepted as contemporaneous, and there was marked discord between the records and the activities as registered. See our guide to contemporaneous evidence for the full record set.
Mapping commit evidence to the statutory test
The table below shows where repository history is load-bearing under s 355-25(1) and where you need something else.
| Element of s 355-25(1) | What commits and PRs can show | What you still need |
|---|---|---|
| Outcome unknown in advance | Little to nothing | Prior-art and patent search results, literature review, expert statements, dated before the work started |
| Purpose of generating new knowledge | Weak signal only | Project plans, meeting records, expenditure approvals stating the R&D purpose |
| Hypothesis | Only if written into the PR or issue | A dated note or experimental plan stating the hypothesis and its basis, before experiments |
| Experiment | Branch structure, config changes, test harnesses, variables altered | Test protocols specifying what was varied, held constant and measured |
| Observation | Strong: commit timestamps, CI runs, benchmark output, failed builds | Raw data logs where results live outside the repo |
| Evaluation and conclusions | PR discussion, revert commits, ADRs | Analysis notes recording negative results and the next hypothesis |
The pre-work evidence of a worldwide knowledge gap is the single most common missing piece in software claims.
Commit and branch hygiene for R&D traceability
You do not need a special workflow. You need messages and structures that a reviewer who has never met your team can read two years later.
Write messages that carry the reasoning
- Name what was being tested, not only what changed: "test whether batched writes hold p99 under 200ms at 10k concurrent sessions" beats "perf tweak".
- Record the result, including failures: "approach rejected, latency degraded above 4k sessions, next attempt uses sharded queue".
- Reference the issue or experiment ID so the commit joins a chain rather than sitting alone.
- Keep reverts and abandoned branches. Deleted dead ends destroy the evidence that the outcome was genuinely uncertain.
Use branches and PRs as experiment boundaries
Name experimental branches so they map to a registered activity, for example exp/sync-conflict-resolution. Put the hypothesis and the acceptance criteria in the PR description before merging, and let the review thread capture the evaluation.
Never rewrite history for a claim
Git history is not truly immutable, which is exactly why rewriting it for a claim is so damaging. Force-pushed rewrites, squashed histories that erase failed attempts, and bulk message edits after year end are the version-control equivalent of backdating a file note. Rewrites usually leave traces, in reflogs, forks, CI logs and platform event histories, and any inconsistency between those traces and your submitted evidence is exactly what a reviewer will find.
Jira and linked issue trackers
Issue trackers close the gaps commits leave. A ticket can hold the hypothesis, the acceptance criteria, the literature reviewed and the conclusion, all with creation and transition timestamps, and it links to the commits that implemented the work.
That link matters because the tribunal has repeatedly refused to accept asserted process. In GQHC [2024] AATA 409, hypotheses had to be scientific, specific and capable of being validated or invalidated rather than commercial aims, and observation and evaluation had to be evidenced rather than asserted. Maintaining adequate documentation was treated as part of the systematic progression itself.
Separately, the ticket trail is what lets you allocate work across core and supporting activities and show why each allocation is reasonable.
In the AAT's 2023 decision in Active Sports Management, the contemporaneous formation of a hypothesis was described as the essential starting point of the activities. A ticket created before the branch is exactly that artefact.
The expenditure nexus
Commit and ticket history also feeds the ATO side of the claim, because every R&D hour must tie to a specific registered activity through a reasonable apportionment method. Timesheets or equivalent time records remain the primary nexus; commits and tickets are what make the numbers in them credible.
Worked example
Take one engineer on a $160,000 salary with $24,000 of on-costs. Time records supported by commits and tickets show 45% of their year on a registered core activity.
- Total salary and on-costs: $160,000 + $24,000 = $184,000.
- Apportionment supported by commits and tickets: 45%.
- Notional R&D expenditure: $184,000 x 45% = $82,800.
The offset applied to that figure depends on aggregated turnover and the company tax rate: a company under $20M aggregated turnover claims the refundable offset at its company tax rate plus 18.5 percentage points. Our end-to-end guide to the R&D Tax Incentive sets out the rates and thresholds in full.
This is illustrative only. Integrity rules such as the at-risk, conducted-for and clawback provisions can change the outcome, and the offset itself is a matter for the company's tax agent.
What a reviewer will test
The apportionment percentage is the number a reviewer will test, and repository history is how you defend it. Expect questions about how the split between R&D and non-R&D work was derived, and about how core work was separated from supporting work.
In the ATO-cited Tier Toys and Ozone Manufacturing matters, the absence of contemporaneous records meant the taxpayers could not show the expenditure was anything more than normal business expenditure. That is the failure a clean commit-to-activity trail prevents, and it is a recurring theme in ATO reviews and audits.
Common mistakes
- Treating the whole repository as the claim. A core activity is a knowledge gap, not a repo, a sprint or a team. Most applications land on three to seven core activities.
- Registering the product, not the experiment. The registration narrative must describe the knowledge gap and the experiment. Commit volume is not an argument.
- No prior-art trail. Without a dated search or literature review, there is nothing to answer the "why couldn't a competent professional know this" field. Absolute Vision failed partly on exactly this.
- Backfilling messages before an audit. Retrospective edits invite the same finding as Absolute Vision: records that do not match the activities as registered.
- Ignoring the excluded categories. Commits on internal administration software can fall foul of the s 355-25(2)(h) exclusion regardless of how difficult the work was. See software eligibility.
- Counting all committed time as core. Environment setup, tooling and test frameworks are usually supporting activities, grouped into a few broad categories per stream rather than one per ticket.
Turning engineering signals into a registration
The practical problem is not whether commits count. It is that the useful signal sits across thousands of commits, tickets and PRs, and someone has to allocate it to activities and hours before it becomes evidence.
Rand does that mapping directly from GitHub and Jira, allocates hours against each stream, and produces the field-by-field content the AusIndustry registration form requires (sources investigated, why the outcome could not be known, hypothesis, experiment, evaluation, conclusions, new knowledge) with the underlying signals attached.
Your repository is already most of an evidence file. The work is connecting it to a hypothesis that existed first, a knowledge gap you can point to in the literature, and an hour allocation you can defend three years from now.