The program rewards work that goes past existing knowledge to solve a real technical problem. It does not reward building a product with established tools, however new the product is.
A company turning over less than $20 million receives a 43.5 per cent refundable offset, which for a pre-revenue startup arrives as cash from the ATO. Above $20 million the offset is non-refundable, at the corporate tax rate plus an intensity premium. Prime Innovation, a specialist division of Prime Partners, helps software companies work out which side of the line each piece of work sits on, structure the claim, and keep documentation that survives AusIndustry review.
This is the distinction the whole thing turns on, and the one most companies get wrong. Something can be entirely new to your business, genuinely hard to build, commercially risky, and still not be R&D, because a competent professional in the field could have told you how it would turn out. The incentive sits in Division 355 of the Income Tax Assessment Act 1997 and it pays for resolving uncertainty, not for effort.
New algorithms for computational problems where no known solution exists, or where existing ones cannot meet the constraints you are working under.
New model architectures or training methods, where whether you can reach the target accuracy at all is an open question.
New approaches to threat detection, encryption or vulnerability prevention where existing techniques are not enough.
Systems built for scale, consistency or fault tolerance beyond what the proven patterns can handle.
New approaches to language understanding, generation or analysis where accuracy or reliability is uncertain.
New methods for recognition, object detection or visual analysis using unproven techniques.
Reaching speeds or throughput that known optimisation methods cannot deliver.
Test environments, datasets, prototypes and documentation that directly support a core activity.
Routine coding, meaning features built with established frameworks and patterns: React front ends, REST APIs, CRUD.
Bug fixes and maintenance on existing software.
Interface and visual design, and A/B testing layouts.
Installing and configuring an off the shelf platform.
Integrating a pre-trained model is generally not R&D. Fine tuning that model for a domain where the performance is genuinely uncertain, and experimenting systematically to get the accuracy acceptable, may be.
Also usually outside: connecting systems through documented APIs, CI/CD and containerisation with established tools, porting between platforms by known methods, and adapting open source without resolving anything uncertain.
Technical uncertainty exists where a competent professional in the relevant field cannot know or determine the outcome in advance. Not unknown to you. Unknown to anyone who knows the field. Here is how that plays out on things software companies actually build.
| What you are building | Uncertain? | Why |
|---|---|---|
| A recommendation engine using collaborative filtering | No | A well established technique with a known outcome |
| A recommendation engine on sparse cold-start data at under 50ms | Possibly | The combination of constraints may go past what known solutions can do |
| Implementing OAuth2 authentication | No | A standard protocol with documented implementations |
| Zero-knowledge proof authentication for a novel use case | Yes | A novel application that has to be validated experimentally |
| Training a GPT model on industry-specific data | Generally no | Fine tuning a pre-trained model is established practice |
| A new training method for a domain LLM with unacceptable hallucination rates | Yes | Requires investigation beyond what is currently known |
The experimental work itself, the part that addresses the uncertainty directly. Writing experimental code to test a hypothesis, designing and running benchmarks, training and evaluating model architectures, running systematic experiments on algorithm variants.
Work that enables the core activity without being experimental itself. Setting up cloud infrastructure for R&D workloads, building data pipelines for training sets, creating test frameworks for experimental code, writing the specifications that guide the experiments.
A supporting activity has to have a direct, close and relatively immediate connection to a specific core activity. Without that connection it is just work.
An AI-powered compliance platform. Eight developers and two data scientists, aggregated turnover $3.5 million. The R&D is developing novel natural language models for analysing regulatory documents.
| Category | Total cost | Eligible | Why |
|---|---|---|---|
| Developer salaries, the R&D team | $400,000 | $250,000 | 62.5% on timesheets |
| Data scientist salaries | $300,000 | $270,000 | 90% on core R&D |
| Cloud computing | $120,000 | $48,000 | 40% of total cloud spend |
| Contractor, machine learning specialist | $80,000 | $80,000 | Exclusively R&D |
| Software tools and licences | $40,000 | $12,000 | The R&D portion only |
| Total | $940,000 | $660,000 |
$660,000 at 43.5 per cent is a refundable offset of $287,100, which brings the net cost of that R&D down to $372,900. Because turnover is under $20 million the offset is refundable, so the ATO pays it whether or not the company is profitable.
Illustrative only. What a claim is worth depends on your facts and your apportionment.
Building something new to you is not the test. AusIndustry separates commercial novelty from technical novelty, and only the second one counts.
Development moves fast and records fall behind. Without contemporaneous notes of the uncertainty, what was tested and what happened, a claim is hard to defend.
Where the same people do both, time has to be apportioned honestly. Claiming 100 per cent of a developer's time invites scrutiny and usually deserves it.
Cloud costs are eligible only to the extent they relate to R&D. Without tagging or separation between R&D and production workloads there is nothing to substantiate.
Ten months from the end of the financial year. Miss it and the claim for that year is gone, with nothing anyone can do about it.
Will customers buy this is a market question. Can this be built at all is a technical one. Only the second qualifies.
A software company is unusually well placed here, because a lot of what AusIndustry wants is already being produced as a by-product of the work. It just needs to be recognisable as evidence.
Your git history is a contemporaneous record with dates already on it. Write commit messages that reference the hypothesis, tag experimental branches, and keep R&D work on branches or repositories you can point at later.
A dedicated project or label for R&D. The technical uncertainty described in the ticket, the results recorded in the comments, and R&D time tracked apart from production work.
The problem, the hypothesis, the method and the result, written before and after each investigation. A wiki or structured markdown is fine. Dated, and written at the time.
That uncertainty existed, that the investigation was systematic, and that new knowledge came out of it. Anything assembled after the fact at claim time reads as exactly that.
Most software companies are claiming either too much or nothing at all. A proper look at what your team has actually been doing usually settles it quickly.
Contact Prime Innovation→Once a month we send our latest thinking on tax, business, and the moments that shape a year. Practical, considered, and written for people who would rather understand the why than chase the headline.
