Skip to main content
zatersio

Make Your MVP R&D Ready in Two Weeks for Australian Software Teams

Make Your MVP R&D Ready in Two Weeks for Australian Software Teams

Decorative MVP RD title card illustration

Software development can qualify for Australia’s R&D Tax Incentive, but only the experimental slice of the work. To count, that work has to clear the s.355-25 core R&D test: a genuine technical uncertainty, a hypothesis-driven experiment, and new knowledge nobody could pull from existing documentation. Two dates matter immediately: you need at least $20,000 in notional eligible R&D deductions (unless you’re using a registered RSP), and you must register within 10 months of your income year end.

TL;DR:

  • Claims require at least $20,000 in eligible R&D deductions or registration through a registered RSP within ten months of the income year end.
  • Only experimental activities that involve genuine technical uncertainty and produce new publicly available knowledge qualify as core R&D under strict criteria.
  • Most supporting activities, like API integration or UI design, are ineligible unless directly related to a core experiment and undertaken for the experiment’s purpose.
  • Breaking projects into discrete core activities with clear hypotheses, experiments, personnel, and outcomes improves the likelihood of a successful claim.
  • Evidence like spike tickets, commit histories, benchmark outputs, and contemporaneous documentation is crucial for defending claims during review.

Table of Contents

Quick Eligibility Checklist for R&D Software Eligibility in Australia

Before you spend a week building a claim, spend ten minutes on this.

Run your project against these six checks:

  • Entity status: you’re an Australian-incorporated company, an Australian tax resident, or a foreign entity operating through a local permanent establishment.
  • Technical uncertainty: a competent software professional, armed with public documentation, couldn’t have predicted the outcome in advance.
  • Documented hypothesis: you wrote down what you expected to happen and how you’d measure it, before you ran the experiment.
  • New knowledge test: the result adds to what’s publicly known about how to solve the problem, not just to your own team’s internal understanding.
  • Spend threshold: you’ve incurred, or plan to incur, at least $20,000 in notional eligible R&D deductions, or you’re claiming through a registered Research Service Provider.
  • Registration timing: you’re on track to register within 10 months of your income year closing.

If you fail two or more of these, don’t panic. Most projects have some eligible activity buried in them. The trick is isolating it.

What Counts as Eligible Software R&D Under the Core Activity Test?

The statutory test lives in s.355-25 of the ITAA 1997, and it’s narrower than most engineers assume. “We didn’t know if this would work” isn’t the bar. The bar is that a competent professional, using publicly available knowledge, couldn’t have known the outcome without running an experiment.

Technical uncertainty in software terms looks like:

  • Whether a novel model architecture will hit a target inference latency at production scale without accuracy loss.
  • Whether a new consensus or synchronization algorithm holds up under conditions no published paper has tested.
  • Whether a data compression method behaves predictably when applied to a data type it wasn’t designed for.

None of these are “will the API return the right JSON.” They’re questions where the answer genuinely isn’t known until you test it.

The process matters as much as the question. Eligible software activity follows a systematic progression: state a hypothesis, design an experiment with a measurable outcome, run it, and evaluate against a pre-defined pass or fail line. Auditors specifically look for that decision rule set up front. If the target gets defined after you see the result, that’s a weak one.

Pro Tip: Auditors have said measurable decision rules, defined before the experiment runs, are one of the clearest signals that separates genuine R&D from routine tuning work.

New knowledge doesn’t mean you invented something the world has never seen. It means the specific combination of technique, constraint, and context you tested wasn’t already documented in a way a competent professional could have applied directly. Fine-tuning an off-the-shelf model on your own dataset using a documented method is not that. Benchmarking a new architectural variant against a target you couldn’t predict from published research usually is.

Common Exclusions and When Supporting Activities Are Allowable

Most rejected software claims aren’t rejected because the work wasn’t impressive. They’re rejected because the impressive work was implementation, not experimentation.

Activities the ATO and AusIndustry routinely exclude from core R&D:

  • Internal administration software, including practice management tools and internal dashboards.
  • Routine configuration of existing platforms or frameworks.
  • Integrating a third-party API by following its published documentation.
  • Standard UI and UX design work, however polished.
  • Data migrations between systems using established methods.
  • Post-launch maintenance, bug fixes, and performance patches on stable systems.

That said, activities on this list can still be supporting activities if they’re directly related to a core experiment and undertaken for the dominant purpose of supporting it. Building a data pipeline purely to feed a research experiment can be supporting R&D. Building the same pipeline to run your production reporting dashboard isn’t. The test isn’t “did this help the project,” it’s “was this done for the dominant purpose of supporting the experimental core.”

Only the narrow experimental elements of most software projects typically qualify. The rest is implementation dressed up as innovation. That’s not a knock on the work, it’s just not what the incentive was built to fund.

Auditors get suspicious when a claim’s supporting activities dwarf the core activity in hours logged, when there’s no documented link between a supporting task and a specific technical hurdle, or when “R&D” appears on every single sprint ticket regardless of content.

How to Group Activities for Registration

Over-grouping kills more claims than under-claiming does. Bundling your entire six-month build into one “core activity” makes it impossible for an assessor to see where the actual uncertainty sat, and it invites them to reject the whole thing rather than untangle it.

AusIndustry’s own guidance flags this directly: successful registrations typically break a project into three to seven discrete core activities, each tied to one specific technical hurdle.

For each activity, record:

  1. The hurdle. What specific technical question couldn’t be answered from existing documentation?
  2. The hypothesis. What did you expect, and why?
  3. The experiment design. What variable did you change, and how did you measure the result?
  4. Personnel and time. Who worked on it and roughly how many hours?
  5. The outcome. What did you learn, and did it match the hypothesis?

A typical two-week MVP sprint might map like this: one core activity for testing whether a lightweight model can hit a real-time inference target on modest hardware, one supporting activity for the benchmarking harness built specifically to test it, and everything else (the UI, the deployment scripts, the client dashboard) sitting outside the claim entirely, which aligns well with best practices in app development Singapore for SMEs | FlowLab. That’s a defensible, activity-by-activity registration rather than a vague “we built an AI product” bundle.

Record Keeping and Contemporaneous Evidence: What to Collect

The single biggest reason software R&D claims collapse under review isn’t ineligible work. It’s evidence assembled after the fact.

Reconstructed end-of-year narratives are weak evidence, and reviewers know the difference between a story written in June about what happened in October and a paper trail generated in October as it happened.

What holds up:

  • Spike tickets that record the technical question before work starts.
  • Architecture decision records showing the hypothesis and the alternatives considered.
  • Commit history and pull requests tied to specific experiment IDs.
  • Benchmark graphs and test harness output showing measured results against your pre-set decision rule.
  • Meeting minutes where the team discussed uncertainty and next steps.
  • Time sheets that map staff hours to specific registered activities, not just “engineering.”

The practical fix is cheap: attach an experiment ID to the ticket, the commit, the test run, and the benchmark output, so each core activity builds its own chain of evidence automatically as the work happens.

Pro Tip: Tag your spike tickets and pull requests with an experiment ID the day you open them, not the week before you file your claim. Six months of consistent tagging beats one frantic week of reconstruction.

Teams running experiments involving hosted models or client data should also think about where that data lives. If data residency and sovereignty matter to your evidence chain, particularly for AI-related experiments, sort that out at the start of the project, not the end.

How to Register and Claim: Timeline, Findings, and Offset Rates

Registration happens with AusIndustry; the tax offset itself is claimed through the ATO once registration is confirmed. You need to register within 10 months of the end of your income year, and you can’t claim the offset without that registration in place.

If parts of your work sit overseas, or if the novelty of what you’re claiming is genuinely arguable, an advance finding or Overseas Finding can settle the question before you file, rather than after an auditor challenges it. Overseas Findings specifically require you to document why the work couldn’t reasonably have been done in Australia, backed by cost comparisons the legislation expects to see.

Once registered, the offset you actually receive depends on your aggregated turnover. Practitioner guidance puts it this way: companies under $20 million in aggregated turnover generally receive a refundable offset equal to the company tax rate plus 18.5 percentage points, commonly landing around 43.5%, which can mean an actual cash refund even if the company is pre-revenue. Larger companies move to a non-refundable, intensity-based offset instead, which reduces tax payable rather than generating a refund.

How to Register and Claim: Timeline, Findings, and Offset Rates — overview diagram

That refundable treatment is a big deal for early-stage software companies. It’s one of the few government mechanisms in Australia that can put cash in the bank of a company that hasn’t sold anything yet, provided the experimental work and the paperwork both hold up.

Eligible vs. Ineligible: Four Quick Scenarios

  1. A novel model architecture benchmarked at scale. A team builds a custom attention mechanism and tests it against latency and accuracy targets no published paper has verified at that scale. Core R&D.
  2. Integrating a third-party payment API following its documentation. Well-executed, necessary work, but the outcome was knowable from the vendor’s docs. Not R&D.
  3. A data pipeline and test harness built specifically to run the above benchmark. Not experimental on its own, but directly supports the core activity and was built for that dominant purpose. Supporting activity.
  4. An internal tool for tracking staff rosters and client jobs. Useful software, zero technical uncertainty, no new knowledge generated. Excluded as core R&D, and generally not eligible as a supporting activity either since it doesn’t serve an experiment.

Most real projects contain all four types of activity at once. The registration only needs to capture the first and third.

Why Most Software Teams Get This Backwards

Most engineering teams treat R&D eligibility as a finance problem to solve after the product ships. That’s the order of operations that causes rejected claims. By the time you’re writing the registration in month nine, nobody remembers which decision came from a genuine unknown and which came from “we just picked the popular option.”

The teams that get clean, defensible claims treat the eligibility test as a design constraint from day one. They write the hypothesis before the sprint, not after. They tag the experiment before the first commit. This isn’t extra bureaucracy bolted onto engineering work, it’s closer to how a competent technical team should be documenting hard decisions anyway.

Why Most Software Teams Get This Backwards — overview diagram

Zatersio builds MVPs this way by default, not because it’s chasing an R&D tax outcome, but because rapid, evidence-backed engineering and a defensible R&D claim happen to require the same discipline: a clear hypothesis, a measurable test, and a paper trail that doesn’t need reconstruction later. The MVP development work we deliver in under two weeks generates exactly the artifacts an AusIndustry reviewer wants to see, because we were never planning to reconstruct anything after the fact.

Ask any development partner this before you sign: will you tag experiments as you build, or will I be piecing together a narrative from Slack messages in month nine? The answer tells you almost everything about whether your project will still be claimable when it counts.

— Lakitha

Get an R&D-Ready MVP Built in Under Two Weeks

Zatersio builds working MVPs for Australian founders and business owners in under two weeks, and structures the experimental parts of that build so the paperwork holds up if you pursue the R&D Tax Incentive. That’s the real gap most software teams hit: they either build fast and lose the evidence trail, or they document everything and miss their launch window. You don’t have to choose.

Zatersio

Every build runs on fixed pricing with direct access to the engineering team actually writing the code, and you can choose your data residency setup to keep AI-related experiments compliant with Australian data expectations. If your project touches trades, professional services, healthcare, or any workflow buried in repetitive admin, there’s a good chance part of the build qualifies as genuine technical experimentation, not just implementation. Review the MVP development page and book a consult to find out which parts of your project could be claimable before you write a single line of code.

Sources