Skip to main content
zatersio

Software R&D Activities in Australia: 10,000 Users, Still Routine?

Software R&D Activities in Australia: 10,000 Users, Still Routine?

Sketch motifs framing an Australian software RD title

Software work qualifies for the Australian R&D Tax Incentive when it faces a genuinely unknown outcome, follows a systematic progression of hypothesis, experiment, observation and evaluation, and aims to generate new knowledge. Internal admin tools, routine customization and off-the-shelf integrations usually miss that test. Below, we walk through the legal elements, the pitfalls that trip up most claims, and the documentation that makes a claim defensible.

TL;DR:

  • Internal administration tools, routine integrations, bug fixes, and customer adoption uncertainty generally fail; routine testing qualifies only when it tests a specific technical hypothesis.
  • Register each activity, not the whole project, and link supporting work such as testbeds or curated datasets to a named core experiment.
  • Keep the hypothesis, experiment design, raw metrics, evaluation, and conclusions as work happens; retrospective explanations and mismatches between registration and tax claims invite scrutiny.
  • A $20,000 threshold generally applies to notional deductions for payments to another entity, with exceptions for registered research service providers and contributions to a Cooperative Research Centre.
  • Claim overseas R&D only with an advance Overseas Finding before the income year ends, and meet the technical necessity and cost ratio conditions.
Zatersio
Build Software With R&D in Mind
Zatersio builds bespoke software and automates repetitive admin tasks, with a focus on R&D Tax Incentive eligibility for eligible projects.
Visit Zatersio

Table of Contents

Core R&D activities: statutory definition and mapping to software work

The statutory test for a core R&D activity comes from subsection 355-25(1) of the ITAA 1997: the outcome has to be unknown in advance, and the work has to follow a systematic progression aimed at generating new knowledge. For software teams, “unknown outcome” means a competent professional in the field could not have predicted the result based on existing knowledge. A novel algorithm whose convergence behavior is uncertain, a machine learning model that may or may not generalize to a new data distribution, or an architecture that might not scale past a certain load all fit that description.

The systematic progression has five recognizable stages in a software context:

  • Hypothesis: a specific technical prediction, such as “this indexing approach will cut query latency below 50 milliseconds at 10 million records.”
  • Experiment: code built specifically to test that prediction under controlled conditions.
  • Observation: logged metrics, benchmark results, or failure traces captured during the test.
  • Evaluation: analysis of whether the result confirms or disproves the hypothesis.
  • Conclusions: a documented decision on what was learned and what happens next.

Prototyping and proof-of-concept work can qualify, but only when the team is resolving a real technical unknown rather than assembling known components. Building a demo with a published API and a standard database schema is implementation, not experimentation. Testing whether a new model architecture can hit an accuracy target nobody has confirmed is achievable, with experiments designed around that question, is a much stronger candidate. Scaling work follows the same logic: moving from 1,000 users to 10,000 by adding more servers is routine, but redesigning a data pipeline because nobody can predict whether a new concurrency model will hold up under load is where the technical uncertainty starts to look real.

Common exclusions and routine activities that usually do not count as core R&D

Most rejected or reduced claims fall into a short list of patterns. Recognizing them early saves time when you are deciding what to register.

  1. Internal administration software. Building or customizing a tool for the dominant purpose of running your own business operations, such as an internal CRM or HR system, is excluded as a core activity under subsection 355-25(2), though it may still count as a supporting activity in some cases.
  2. Reproducing known solutions. Work that reproduces an existing product, technique or process using publicly available information is not R&D, even if it takes real engineering effort.
  3. Off-the-shelf integration. Connecting a third-party API or plugging in a commercial platform is standard implementation work, not experimentation, because the outcome is predictable.
  4. Routine testing. Bug fixes, user acceptance testing, data migration testing and beta testing are generally ineligible. The ATO has flagged these as commonly misclaimed, and they only become core R&D when they are structured as experiments resolving a specific technical hypothesis rather than confirming that a feature works as designed.
  5. Commercial risk mistaken for technical uncertainty. Not knowing whether customers will adopt a feature is a business risk. Not knowing whether an algorithm will converge is a technical one. Only the second kind supports a claim.

Supporting R&D activities and the dominant-purpose test

Supporting activities are tasks that are not themselves experimental but exist to enable a core R&D activity. They qualify when their dominant purpose is supporting that core activity, a requirement spelled out in the software sector guide.

In practice, this covers:

  • Testbeds and experimental environments built specifically to run the experiments tied to a hypothesis.
  • Code written to generate test data or simulate edge cases, where the code itself is not the experiment but makes the experiment possible.
  • Curated datasets assembled to train or validate a model under test, rather than general-purpose data pipelines.

The practical test is linkage: can you point to the specific core R&D activity each supporting task feeds into? Evidence that shows dominant purpose includes project notes tying the testbed to a named hypothesis, time records showing the work was performed alongside the experiment, and version history showing the supporting code changed in step with the experimental one. When registering activities with AusIndustry, name the core activity first and describe each supporting activity as feeding directly into it, rather than listing supporting work as a standalone line.

Registering, claiming, and eligible expenditure for software R&D in Australia

Registration happens at the activity level with AusIndustry, not at the project level, and registering an activity does not automatically make it eligible. The claim still has to stand up to scrutiny when the ATO reviews the tax return.

Eligible expenditure generally falls into a few categories:

  • Salary and wages for staff time spent on registered R&D activities.
  • Payments to registered research service providers (RSPs).
  • Decline in value of assets used in R&D.
  • Feedstock expenditure, where inputs are consumed in the R&D process.

There is a general $20,000 threshold for notional deductions on expenditure to another entity, with exceptions for payments to RSPs or contributions to a Cooperative Research Centre. Overseas R&D work can only be claimed with an advance Overseas Finding in place before the income year ends, and it has to meet conditions around technical necessity and cost ratios, a process set out under the Industry Research and Development Act 1986. Mismatches between what is registered with AusIndustry and what is claimed on the tax return are a common audit trigger, so keep the two aligned from the start.

Concrete examples and hypotheticals: how to classify and document activities

A machine learning team building a fraud-detection model might hypothesize that a particular feature engineering approach will reduce false positives below a target rate that no existing published method achieves for their data type. They run controlled experiments varying feature sets and model parameters, log precision and recall at each run, and conclude whether the hypothesis held. That whole arc, hypothesis through conclusion, meets the unknown-outcome test because no competent professional could have predicted the result in advance.

Model trials compare fraud detection outcomes

Contrast that with a team building an internal rostering tool using a standard web framework and a commercial scheduling library. Even if the build takes months, it is implementation of known techniques for internal administration, which is excluded unless the business later sells the tool externally and the technical challenge shifts to something genuinely uncertain.

For each eligible example, keep:

  • The written hypothesis, stated as a testable prediction.
  • The experiment design, including what was varied and why.
  • Raw metrics and logs collected during testing.
  • Evaluation notes explaining whether the result confirmed or disproved the hypothesis.
  • A logical conclusion recorded close to when the work happened.

Pro Tip: Write the hypothesis down before you start coding, not after the results come in. Retrospective hypotheses are one of the first things reviewers question.

Practical application: how Zatersio scopes R&D-ready MVPs and documents eligibility

When we scope a rapid MVP build, we structure the project so the experimental work is visible from day one rather than reconstructed later. Our MVP Development process pairs engineer-led scoping with Australian data residency options, which also helps when a project later needs to show it meets the “conducted in Australia” requirement for core activities.

Through the build, we keep:

  • Written experiment plans tied to a specific technical hypothesis.
  • Test data and benchmark results from each iteration.
  • Evaluation notes explaining what each test confirmed or ruled out.
  • Versioned code snapshots showing what changed and when.

These records map directly to what AusIndustry and the ATO expect to see in a defensible claim. If you are planning a build with R&D potential, it is worth getting the documentation structure right before the first line of code is written.

Regulatory perspective: why specificity and contemporaneous records matter now

Regulators have made it clear that whole-project registrations and vague activity descriptions are the first things reviewers question. The practical fix is narrow: describe each activity specifically, log hypotheses and results as you go rather than reconstructing them later, and never fold routine testing into a core activity description. Tighter records do not just reduce audit risk. They make the claim genuinely defensible on its own merits.

— Lakitha

How we help Australian teams build R&D-ready software

We build MVPs and automations with the documentation habits baked in from the first sprint, not bolted on afterward. Whether the project is an AI agent, a workflow automation, or a full product build, the technical unknowns are scoped up front and records are kept as the work happens, not months later when a claim is due.

  • MVP Development for founders testing a genuinely new technical approach, delivered fast with documented experiments.
  • AI Agent Development and Workflow Automation for businesses automating processes where the technical outcome is not yet certain.
  • Fixed pricing and Australian data residency options on builds, which also supports claims that depend on work being conducted onshore.

If you are planning a software build that might carry genuine R&D value, check our pricing and service scope or start with MVP Development to see how we structure a build around a real technical hypothesis from day one.

Zatersio

FAQ

What counts as a core R&D activity for software projects?

A core R&D activity is one with an outcome that cannot be known in advance, pursued through a systematic progression of hypothesis, experiment, observation and evaluation. The purpose has to be generating new knowledge, not just building a working product.

Does building an MVP qualify for the R&D Tax Incentive?

An MVP qualifies only to the extent it involves genuine technical uncertainty resolved through structured experiments, not simply assembling known tools into a working product. Many MVPs mix eligible experimental components with routine implementation, so each activity needs its own assessment.

Are bug fixes and routine testing eligible for R&D claims?

Bug fixes, user acceptance testing and routine data migration testing are generally not eligible, since the ATO has identified these as commonly misclaimed activities. They can only qualify when structured as experiments testing a specific technical hypothesis.

How does AI agent or automation development fit the R&D definition?

AI agent and automation projects can qualify when the team faces a genuine technical unknown, such as whether a model will generalize reliably or whether a new orchestration approach will hold up under real conditions. Routine configuration of existing automation platforms without that uncertainty does not meet the test.

What records do I need to support a software R&D claim?

Keep a written hypothesis, the experiment design, raw metrics and logs, evaluation notes, and documented conclusions for each activity, as outlined in AusIndustry’s guidance. Records created at the time of the work carry far more weight than descriptions written after the fact.

Sources