R&D Tax Incentive for Software Startups in Australia

By Alex Knight, Founder and CEO, Advanced

Software startups are some of the biggest under-claimants in the R&D Tax Incentive program.

Not because their work doesn't qualify. Most of it does. The problem is that software founders look at their sprint backlog, see nothing that resembles a laboratory or a scientific paper, and assume the program isn't designed for them.

It is. The RDTI was built around genuine technical uncertainty and systematic experimentation. That describes most serious software development. The definition of R&D has nothing to do with test tubes.

What the program actually covers for software

The core test for eligible R&D activity is straightforward: were you trying to solve a technical problem whose solution was genuinely uncertain before you started? Did you form a hypothesis, run experiments, observe outcomes, and draw conclusions? That's R&D under the RDTI, whether you're building a novel machine learning model or a distributed system that nobody has built quite this way before.

The activities that most commonly qualify for software startups:

Algorithm development:

Building new algorithms to solve problems that existing approaches don't handle well. The uncertainty has to be genuine. Adapting a known algorithm to a new input type is less likely to qualify than developing a fundamentally new approach to a problem.

Machine learning and AI model development:

Training models where the architecture, approach, or outcome is not known in advance. The experimental nature of ML development, hypothesis, training run, evaluation, iteration, maps naturally onto the RDTI's requirements.

Novel platform or infrastructure development:

Building systems that need to behave in ways that don't have established technical precedents. Distributed systems, real-time processing at novel scales, new approaches to data consistency or fault tolerance.

Technical integrations where the approach is genuinely uncertain:

Not standard API integrations, but cases where the technical challenge of making two systems communicate in a novel way required genuine experimental work.

Performance optimisation at the frontier:

Solving performance problems that go beyond known optimisation techniques. If the answer wasn't in the documentation and you had to experiment your way to a solution, that's potentially eligible.

What doesn't qualify:

‍Routine feature development, bug fixes using known techniques, standard configuration of existing frameworks, and UI or UX changes that don't involve technical uncertainty.

The line isn't always clean, and that's intentional. The program is designed to be assessed on the specifics of each claim. When in doubt, the question to ask is: before you started, did you know if it was technically possible?

What expenditure you can claim

Once you have eligible activities, the expenditure categories available to software founders are broader than most assume.

Developer and engineer salaries:

Time spent on eligible experimental work by any employee is claimable, apportioned to the percentage of their time spent on eligible activities. This is usually the largest component of a software startup's R&D claim and the most commonly under-claimed, because founders assume only dedicated R&D staff qualify. They don't. A full-stack developer who spends 70% of their time on experimental work has 70% of their salary eligible for the program.

Cloud infrastructure costs:

AWS, Google Cloud, Azure, and equivalent services used to run experimental workloads are supporting R&D expenditure. Training ML models, running experimental builds, testing distributed systems, the compute costs associated with eligible experimental work are claimable.

Contractor costs:

External developers, architects, or technical specialists engaged to support eligible R&D can be included, where the expenditure is genuinely at risk.

Software development tools:

Tools used directly in eligible R&D activities. Not general business software, but tools that are part of the experimental workflow.

Failed experiments:

If you ran an experiment and it didn't work, that expenditure is eligible. The program rewards genuine uncertainty. A negative result is evidence of genuine R&D, not a reason to exclude the cost.

The documentation requirement for software claims

Software R&D claims attract more ATO scrutiny than most other sectors, partly because the line between eligible experimental work and routine development is harder to draw in code than in a laboratory.

The documentation that protects a software claim:

Experimental records created at the time:

Hypothesis documents, architectural decision records, experiment logs, and similar records created before and during the experimental work. Retrospective reconstruction is a risk. Records created as the work happens are more defensible.

Evidence of technical uncertainty:

Something that demonstrates you genuinely didn't know if the approach would work before you tried it. Design discussions, technical spikes, failed approaches that preceded the successful one.

Time records:

Supporting the apportionment of developer and engineer time. These don't have to be elaborate, but they need to exist and they need to be credible.

Cost records:

Invoices, contracts, and payment records for all claimed expenditure, with documentation connecting each cost to a specific eligible activity.

The ATO's compliance focus in recent years has been on the quality of technical narratives, the description of what the experimental work involved and why it was genuinely uncertain. A polished write-up at lodgement time doesn't substitute for contemporaneous records. The narrative should describe work that actually happened, not the work a consultant thinks qualifies.

What the refund means for your build

A software startup spending $800,000 on eligible R&D activity in a financial year has an anticipated RDTI refund of $348,000. That refund arrives in October or November, after the claim is lodged post-30 June.

Between spending and receiving, there's a 9 to 12 month gap. For a software startup with monthly burn of $100,000 and $600,000 in the bank, that gap is the difference between a comfortable position and a cashflow problem.

R&D financing closes that gap. The facility advances the anticipated refund before the ATO processes the claim. No equity, no monthly repayments, repaid when the refund arrives.

And if the capital arrives early enough to reinvest into eligible R&D before 30 June, that additional spend generates its own refundable offset. The program compounds.

A startup that accesses $348,000 early and reinvests $200,000 into eligible development before 30 June increases its anticipated refund for the following year by $87,000. The flywheel runs.

For the worked numbers and an interactive calculator, see our R&D capital strategy guide and the runway calculator.

The 2026 Budget changes and what they mean for software startups

The 2026 Budget proposed a 10-year cap on the refundable RDTI. Under the proposal, companies incorporated before July 2018 will lose access to the refundable component from July 2028. The legislation has not passed, but for affected software startups, FY26 and FY27 are the most valuable claiming years they have under the current structure.

For companies incorporated after July 2018, the current refundable structure applies for at least the next several years. The $20 million turnover threshold and the 43.5% refundable offset remain unchanged for now.

For a full breakdown of what changed and what didn't, see our Budget 2026 RDTI analysis.