From commits to claim in an hour: a walkthrough

The clearest way to explain what this is like is to walk through it. So here is a concrete, follow-along run, using an illustrative software company, from connecting a repository to a finished package. The company and numbers below are made up to make the steps tangible; the flow is the real one.

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

Meet the example: a small sync-engine startup

Say you run a six-engineer startup building a collaborative editor. Last year your team spent months on one genuinely hard problem: making concurrent edits from many users converge correctly offline, where no off-the-shelf approach did what you needed. You also did a lot of ordinary work, dashboards, settings screens, dependency upgrades, bug fixes. A real claim has to tell those apart. Here is how the hour goes.

Minutes 0 to 5: Connect and ingest

You install the GitHub App against your main repository and kick off the ingest. The tool pulls in the year's pull requests (or commits, if you do not use PRs), who authored them, and when. A few minutes later you see a summary: 312 pull requests found.

Immediately, the first pass sets aside the obviously routine and mechanical work, the dependency bumps, the lockfile-only and docs-only changes, the bot commits. 190 of the 312 are filtered out before you have done anything. That alone reframes the problem: you are no longer staring at a year of work, but at the 122 PRs that might matter.

Minutes 5 to 15: See the map

The tool builds a map of your codebase, classifying each module by its apparent purpose. Your conflict-resolution engine stands out as core product: dozens of pull requests over ten weeks against the same component. The settings and dashboard modules, by contrast, are classified as internal or likely routine.

This is the free preview. Before paying anything, you can already see that your sync engine is the heart of any claim and your admin screens are not. The richer signals, the rewrites, the cluster of reverts, the crdt-spike branch, the benchmark commits iterated against, come out in the interview that follows.

Minute 15: The decision to go further

You decide the sync-engine work is worth substantiating properly, so you start the interview. This is where you pay: a flat fee banded by the size of the estimated claim, not a slice of your refund. Everything up to here was free; from here the tool does the expensive, open-ended work.

Minutes 15 to 40: The interview

Now it gets specific. Instead of a blank "describe your R&D" box, the tool asks pointed, grounded questions:

• "You rewrote the merge logic twice over ten weeks and reverted it three times. What did you not know going in?" You explain that it was genuinely unclear whether you could guarantee convergence under offline edits without unacceptable latency, and that the published approaches did not cover your constraints. That is your technical uncertainty.
• "Was there a hypothesis before you started, and where is it?" You point to the design doc and the crdt-spike branch that predate the implementation. That anchors the new-knowledge purpose.
• "These benchmark commits, what were you measuring and evaluating against?" You describe the convergence and latency targets and how each iteration tested them. That is your systematic progression.

For the settings and dashboard modules, the tool asks whether they are routine, and you confirm they are. They are scoped out. The interview is doing as much excluding as including, which is the point.

Minutes 40 to 45: The skeptic pass

Before anything is finalised, an adversarial pass challenges each candidate. Your sync engine comes back as genuine core R&D, well-evidenced. A borderline candidate, some caching work you were unsure about, comes back flagged as weak, with the reason. You look at it, agree it was really a known optimisation, and leave it out. Better to find that now than in a review.

Minutes 45 to 55: Hours and cost

You estimate effort on a small, stratified sample of the sync-engine pull requests, a few small, a few medium, a couple of large. The tool extrapolates across all of them, splits out the routine PRs, and deducts non-PR overhead against each engineer's working hours. You and your co-founder attest the numbers. Every eligible hour is tied to specific pull requests on the conflict-resolution experiment.

Minute 55: The package

You end with a package: one confirmed core experiment (the conflict-resolution engine), its four-gate substantiation, the pull requests that evidence each part, the hours and cost per engineer, and an estimated offset. The routine work is shown, clearly, as excluded.

What happens next

You send the package to your registered tax adviser. They review the substantiation, apply their judgment, handle the tax treatment, and lodge the claim. They are the backstop; we do not lodge or advise.

What took an afternoon, or in the old way several rounds of meetings reconstructing what your team did, is now an hour that produces something built to be defended: a claim isolated to the genuine experiment, anchored to contemporaneous evidence, with the routine work honestly left out.

That is the whole idea. Start from the work you already did and the trail it left, and turn it into a claim your adviser can stand behind.

This article is general information, not tax advice, and not a determination of eligibility. The example is illustrative. Speak to a registered tax adviser before lodging an R&D Tax Incentive claim.