Turn Two Week MVPs into Audit Ready R&D Docs for Australian Software
Turn Two Week MVPs into Audit Ready R&D Docs for Australian Software
Yes, software project documentation can substantiate an R&D Tax Incentive claim in Australia, but only when it shows your development resolved genuine technical uncertainty through a systematic progression of work. Loose commit messages and after-the-fact summaries won’t cut it. The single most useful thing you can do right now is start capturing hypotheses and experiment plans contemporaneously, then link each one directly to code changes and cost records.
TL;DR:
- Accurate R&D documentation must show systematic work resolving genuine technical uncertainty, linking hypotheses, experiments, and outcomes at each step.
- Contemporaneous records, including commit histories, ticket comments, test reports, and meeting minutes, need clear metadata to be accepted by auditors.
- Only core experimental activities that produce new knowledge are eligible, with clear distinctions from routine development or known solutions.
- Claiming expenses requires detailed apportionment with time tracking and invoices referencing specific activities, avoiding generic salary or overhead claims.
- Building hypothesis and experiment logs into the development process ensures an audit-ready trail without delaying MVP delivery or normal workflows.
Table of Contents
- What Qualifies for the R&D Tax Incentive as R&D Documentation Software Projects?
- How Do You Document a Hypothesis, Experiment, and Conclusion?
- What Records Count as Contemporaneous Evidence?
- How Do You Apportion Costs and Meet the $20,000 Threshold?
- What Mistakes Make R&D Claims Fail Review?
- What Should Your R&D Documentation Checklist Look Like?
- How Does Zatersio Build R&D Documentation Into Developer Workflows?
- Balancing Speed With Audit-Ready Documentation
- Ready to Make Your MVP R&D-Ready From Day One?
- Sources
- FAQ
What Qualifies for the R&D Tax Incentive as R&D Documentation Software Projects?
The legislative test under section 355-25 asks a specific question: did your work generate new knowledge because the outcome couldn’t be determined in advance by a competent professional? If a senior developer could have looked at the problem and confidently predicted the result, it’s not eligible. That’s the line separating genuine R&D from ordinary software delivery.
Core R&D activities are the experimental work itself, tests, builds, evaluations aimed at resolving that uncertainty. Supporting activities are the tasks that enable the core work, like setting up a test environment or writing supporting infrastructure code, and they only qualify when directly related to a core activity.
A few Australian-flavored examples make this concrete:
- Building a new machine learning model to solve a problem with no known algorithmic solution: likely core R&D.
- Integrating a well-documented third-party payment API: almost never eligible, because the outcome is knowable in advance.
- Load-testing a new distributed caching layer whose performance under concurrent write conflicts is genuinely unknown: core R&D.
- Writing the CI pipeline that runs those load tests: supporting activity, claimable alongside the core work.
Assessment happens at the activity level, not the project level. A single sprint might contain one experiment that qualifies and five tickets that don’t.
How Do You Document a Hypothesis, Experiment, and Conclusion?
The systematic progression of work is a five-step cycle: hypothesis, experiment, observation, evaluation, and logical conclusion. Australian R&D TI rules require you to demonstrate this cycle for each core R&D activity, not describe it in vague retrospect months later.
Here’s how to turn that into a repeatable habit rather than a paperwork chore:
- Write the hypothesis first. State the goal, name the specific technical uncertainty, and predict an expected outcome. Example: “We hypothesize that a custom indexing structure will reduce query latency below 50ms under 10,000 concurrent reads, but the trade off with write throughput is unknown.”
- Design a controlled experiment. Define the testbed, the inputs you’re varying, and the outputs you’re measuring before you start coding. This is what separates an experiment from routine debugging.
- Record observations as they happen. Log what actually occurred, including failed attempts. A failed test run is often stronger audit evidence than a clean pass, because it proves the outcome wasn’t predictable.
- Draw a logical conclusion. State whether the hypothesis held, and what you learned that a competent professional couldn’t have known beforehand.
Pro Tip: Add a “hypothesis” and “conclusion” field directly to your Jira or Linear ticket template for anything you think might be R&D. It takes thirty seconds per ticket and turns your existing sprint board into an audit trail without extra tooling.
What Records Count as Contemporaneous Evidence?
Contemporaneous means created at the time the work happened, not reconstructed later from memory. Business lists acceptable evidence types that link R&D activities directly to expenditure, and most of them already exist in your normal workflow if you tag them correctly:
- Git commit history and pull request descriptions
- Jira or Linear ticket histories, including comments and status changes
- Written experimental plans and project plans
- Test reports and CI pipeline artifacts
- Meeting minutes from design or technical review sessions
- Emails discussing technical blockers or design decisions
- Timesheets linked to specific activity IDs
Informal tool-based records like commit logs and ticket exports are generally accepted as evidence when they’re clearly dated and tied to the hypothesis they’re testing. Every record needs four pieces of minimal metadata: who created it, when, why, and what it relates to. Missing even one of these weakens the record’s evidentiary value.
For storage, keep a version-controlled repository for code and commit history, export ticket histories on a regular cadence rather than at claim time, archive CI test artifacts before they expire on your build server, and maintain a dedicated claim folder that maps each piece of evidence to the expenditure it supports. Auditors and tribunal reviewers have disallowed claims specifically because hypothesis documentation was missing, even when the underlying technical work looked genuinely novel.
How Do You Apportion Costs and Meet the $20,000 Threshold?
Typical claimable expenditure includes developer and engineer salaries apportioned to R&D time, contractor payments, payments to a Registered Service Provider (RSP), decline in value on R&D-related depreciating assets, and feedstock adjustments where relevant. Overheads tied directly to the R&D activity, like a portion of cloud compute costs used specifically for testing, can also qualify.
Your company needs at least $20,000 in total notional R&D deductions to claim the tax offset, unless you’re claiming eligible expenditure to an RSP, which has its own exception. If you’re contracting an RSP or doing overseas R&D work, secure an advance finding from the department before you claim, and make sure contracts explicitly tie deliverables to discrete experimental activities.
Apportionment has to be visible, not asserted. That means:
- Timesheets keyed to specific activity IDs, not just “development” as a generic line item
- Invoices from contractors or RSPs referencing the activity they relate to
- A clear percentage split when a developer splits time between R&D and non-R&D work in the same week
Generic salary figures with no mapping to activities are weak under audit, even when the amount claimed is accurate.
What Mistakes Make R&D Claims Fail Review?
The ATO’s TA 2017/5 guidance flags a recurring pattern: companies registering an entire software project as R&D when only a fraction of the actual work involved technical uncertainty. The most common misclaims include:
- Registering a whole project when only specific experiments within it are eligible
- Claiming routine testing or standard quality assurance as core R&D
- Claiming user acceptance testing (UAT), which tests business fit, not technical uncertainty
- Adapting off-the-shelf software or configuring existing platforms and calling it R&D
- Confusing commercial risk (will customers buy this?) with technical uncertainty (can this even be built?)
Reviewers look for specific red flags: vague activity descriptions that could describe any software project, an absence of documented hypotheses, and cost claims with no apportionment trail. If you spot these in your own records, the fix is straightforward. Split blended activities into discrete, individually assessed pieces. Capture failed experiments, not just successes. Keep every cost record linked back to a specific activity ID from day one.
What Should Your R&D Documentation Checklist Look Like?
Build the habit around three checkpoints rather than trying to remember everything at claim time.
- Before the experiment: write the hypothesis, define the testbed, and note the expected outcome in the ticket.
- During the experiment: log observations as they happen, tag commits to the ticket, and attach CI test artifacts as they generate.
- After the experiment: add a conclusion comment to the ticket, map the time spent to the activity ID, and file the evidence in your claim folder.
Minimal template fields you need across hypothesis notes, experiment logs, and expense mapping are: activity ID, date, hypothesis statement, measured outcome, and linked expenditure. Most teams can assemble this straight from Git, Jira exports, and CI logs without buying new software.
How Does Zatersio Build R&D Documentation Into Developer Workflows?
Hypotheses and experiment plans are captured during two-week MVP sprints as they happen, not as a scramble before tax time. Each experiment ticket carries a hypothesis field, and the engineering team logs observations and conclusions directly against it.
Ownership stays simple: developers log the technical detail, the product owner confirms the uncertainty was genuine, and finance maps the time to expenditure.
- Developers: hypothesis, experiment design, observations
- Product owner: confirms uncertainty and scope
- Finance: expenditure mapping and timesheet reconciliation
Readers building or outsourcing an MVP can see how this works in practice through Zatersio’s guide on funding an MVP with the R&D Tax Incentive.
Balancing Speed With Audit-Ready Documentation
The temptation on a fast MVP build is to skip the paperwork and write it up later. That’s exactly backward. A small team’s minimum viable record is a one-line hypothesis and a one-line conclusion per experiment ticket, nothing more. Make it a sprint ritual, not a compliance task, and the documentation habit sticks without slowing anyone down.
— Lakitha
Ready to Make Your MVP R&D-Ready From Day One?
Most agencies hand you working software and leave the tax paperwork for you to reconstruct later, usually months after anyone remembers why a decision was made. Zatersio builds the hypothesis and experiment logging into the sprint itself, so by the time your two-week MVP ships, the audit trail already exists alongside the code.
That matters because Melbourne-based engineers, not account managers, scope and deliver every build, which means the person writing the code is the same person capturing the technical uncertainty behind it. For teams weighing delivery approaches more broadly, it’s worth comparing notes with partners like Omnivance Media’s custom software practice or reviewing an operational readiness framework before locking in a documentation process.
If you’re planning a build and want it structured for a claim from the outset, start with Zatersio’s MVP development service and get a fixed-price scope that includes R&D-ready documentation as part of delivery, not an afterthought.
Sources
Three government resources anchor every claim decision. Business.gov.au’s software guide gives software-specific eligibility examples, ATO’s TA 2017/5 explains common misclaims, and the R&D Tax Incentive eligibility page covers the offset threshold. AusIndustry handles activity registration; the ATO handles the tax return and offset calculation.
This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.
FAQ
Can a software MVP qualify for the R&D Tax Incentive?
Yes, an MVP can qualify if specific parts of the build resolved genuine technical uncertainty through a documented hypothesis and experiment cycle. Routine feature-building using known techniques won’t qualify, even inside an otherwise eligible project.
What is the $20,000 threshold for R&D claims?
Your company needs at least $20,000 in total notional R&D deductions to claim the tax offset, unless an exception applies for eligible RSP expenditure. Below that threshold, the claim generally isn’t eligible.
What records do I need to keep for an R&D claim?
Keep contemporaneous evidence like commit history, ticket logs, experimental plans, test reports, and meeting minutes that link the activity to the expenditure. Records created after the fact carry far less weight in a review.
Does UAT or routine testing count as R&D?
No, user acceptance testing and routine quality assurance are generally excluded because they test business fit rather than resolve technical uncertainty. The ATO explicitly flags this as a common misclaim in software projects.
How does Zatersio help with R&D documentation?
Zatersio builds hypothesis and experiment logging into its two-week MVP sprints, so the audit trail is created alongside the code rather than reconstructed later. Pricing for custom builds is available on the MVP development page.