Software is the single most heavily scrutinised category in the R&D Tax Incentive programme. The ATO and AusIndustry have published more guidance, issued more compliance bulletins, and run more focused audits on software claims than on any other category.

There are good reasons for this: software development looks like R&D from the outside — it's technical, it involves problem-solving, it produces a novel artefact — but most of it isn't.

Getting the line right is the entire game.

The legislative test

Core R&D activities under section 355-25 of the ITAA 1997 require three things present together:

  1. A hypothesis. A specific, testable proposition about how something works or how a result might be achieved.
  2. Technical uncertainty. The outcome can't be known or determined in advance using existing knowledge available within the company or its industry.
  3. Systematic experimentation. The hypothesis is tested through a structured process, with results captured, analysed and either confirmed or disproved.

Supporting R&D activities (s355-30) are claimable only if they're directly related to a core activity and undertaken for the dominant purpose of supporting that core activity.

The legislation doesn't mention software. The test applies the same way whether the work is in a lab, a factory, or a code repository.

What typically qualifies in software

In our experience, the categories of software work that consistently meet the test are:

  • Novel algorithmic development where there's genuine uncertainty about whether the algorithm will achieve the required performance characteristics (latency, accuracy, throughput, memory footprint) within the constraints of the target environment.
  • Architectural experiments where the question is whether a particular system architecture can handle the workload, data shape or failure modes the product needs to support, and the answer isn't determinable from published knowledge.
  • Integration work at the edge of two technologies where the question is whether two systems can be made to interoperate to a required standard, and where existing integration patterns demonstrably don't solve the problem.
  • Performance optimisation against a known bound where you're trying to achieve a result that the team genuinely doesn't know is achievable using the available stack.

What typically doesn't qualify

  • Routine feature development. Adding a button, a workflow, a report. Even if the feature is new to the product, if the implementation path is known from existing knowledge there's no R&D in the legislative sense.
  • Incremental product improvement. Making something faster, prettier or easier to use. Engineering, yes. R&D, no.
  • Bug fixes, refactoring, technical debt repayment. Maintenance activities. They don't test a hypothesis.
  • Configuration and integration of third-party services following documented patterns. Even if the integration is complex, if it follows a known recipe it isn't experimental.
  • Engineering work that resolves uncertainty about user requirements rather than technical uncertainty. UX research, A/B testing for engagement, market validation — important work, not R&D.

The "competent professional" test

The cleanest mental model is the competent professional test. Could a person with reasonable expertise in the field, given the company's existing tools and the publicly available knowledge in the industry, have determined the outcome of the work in advance? If yes, there's no technical uncertainty, and there's no eligible R&D. If genuinely no, there's a case to build.

This is harder than it sounds. Engineering teams often default to the answer "we figured it out" rather than asking the prior question of whether the answer was knowable in advance. The structuring conversation has to surface the genuine moments of uncertainty and the hypotheses that were tested at those moments — not just the work that got done.

Documentation that supports a software claim

A defensible software claim needs:

  • Hypothesis statements captured at the point the uncertainty was identified, not retrofitted from successful outcomes.
  • Experiment records showing the structured test of the hypothesis: what was changed, what was measured, what was concluded.
  • Decision points and pivots documented with the technical reasoning, especially where the team changed direction based on what an experiment revealed.
  • Technical literature scans showing that the question wasn't trivially solvable from publicly available information.
  • Apportionment of engineering time that distinguishes between R&D activity and routine engineering activity at the individual contributor level.

Source control history, design documents, retrospectives and ADRs are all useful inputs. None of them on their own are sufficient.

The risk of getting this wrong

A software claim that doesn't meet the eligibility test is the most common reason for ATO compliance review. The consequence of failing review isn't just the disallowance of the claim — it's the reputational and operational cost to the company of having a tax position unwound, often years after the cash has been received and spent.

The point of getting structurally rigorous about software R&D is not to claim less. It's to claim accurately, with documentation that says yes to the questions the ATO will ask if they ever ask them.