The short answer
Software development can be eligible for the R&D Tax Incentive (RDTI), but the legislation applies its test to activities, not whole projects — and much ordinary software work does not meet it. A team can run a genuine R&D activity inside a project that is, overall, routine build. The question is never "is our software project R&D?" It is "which specific activities meet the definition in Division 355 of the Income Tax Assessment Act 1997?"
This article explains the test as the law and AusIndustry state it. It is general information, not advice, and it does not assess any particular activity — an R&D tax adviser does that.
Core vs supporting R&D activities
Division 355 splits eligible work into two kinds.
A core R&D activity is experimental work where the outcome "cannot be known or determined in advance", that proceeds by a "systematic progression of work (hypothesis, experiment, observation, evaluation, logical conclusions)", and is conducted to generate "new or improved materials, products, processes or services." (business.gov.au — Assess if your R&D activities are eligible)
A supporting R&D activity is work "directly related to a core R&D activity." Where a supporting activity also produces goods or services, it must satisfy a dominant purpose test — the prevailing reason for doing it must be to support the core R&D, not to earn a commercial benefit.
The test that decides it: could the outcome be known in advance?
For software, AusIndustry frames the core-activity threshold as a genuine technical hurdle: a core R&D activity arises when you hit "a specific technical hurdle that stops you progressing the work because no existing knowledge, method, or solution can resolve it, even for experienced professionals." (business.gov.au — Software development sector guide)
That last phrase — even for experienced professionals — is the bar. If a competent engineer could resolve the problem by reading documentation, applying a known pattern, or using an existing tool, the outcome was knowable in advance, and the activity is not core R&D.
Software activities that generally are NOT core R&D
AusIndustry's software guide lists routine development that does not meet the core-activity test, including:
- Applying documented configuration options with known outcomes.
- Integrating third-party services or APIs by following vendor documentation.
- Assembling user interfaces using known UI components, style guides, or frontend frameworks.
- Building a dashboard by implementing established design and development patterns.
- Migrating data between systems using known tools and established migration approaches.
None of these are "lesser" engineering — they are simply work whose outcome was knowable, which is what places them outside the core-activity definition.
What core R&D looks like in software
By contrast, an activity moves toward core R&D when there is a real technical unknown and the work is genuinely experimental:
| Routine development | Core R&D activity | |
|---|---|---|
| The problem | Resolvable with existing knowledge/tools | No existing solution, even for experts |
| The outcome | Knowable in advance | Could not be known or determined in advance |
| The method | Apply a known pattern | Hypothesis → experiment → observation → conclusion |
| Failed attempts | Unusual | Expected — evidence the outcome was uncertain |
What the documentation needs to show
Because eligibility turns on the technical unknown, the evidence has to demonstrate it. AusIndustry's software guidance expects records that show "the existence of a technical hurdle," "the actions taken to overcome the technical hurdle, including attempts that failed," and "the proposed solution or approach, including the technical rationale." It accepts ordinary work artefacts as those records — spike tickets, design notes, architecture decision records, emails and chat, and test plans and outputs.
Crucially, these records are strongest when made at the time the work happens, not reconstructed at claim time. (See What "contemporaneous documentation" means for the R&D Tax Incentive.)
A few thresholds worth knowing
- R&D activities must be registered with the Department of Industry, Science and Resources for each income year before the offset is claimed through the ATO.
- A company generally needs at least A$20,000 of notional R&D deductions in a year to claim (this minimum is waived where the spend is with a registered Research Service Provider).
- Eligible R&D expenditure is capped at A$150 million per income year.
Sources: business.gov.au — Assess if your R&D activities are eligible.
Dossio is compliance infrastructure for the R&D Tax Incentive: it captures the technical evidence behind software R&D activities in structured, dated, audit-ready form as the work happens, with R&D tax experts providing oversight and governance.
Sources
- business.gov.au — Software development sector guide for the R&D Tax Incentive
- business.gov.au — Assess if your R&D activities are eligible
- Income Tax Assessment Act 1997 (Cth) — Division 355 (sections 355-25 core, 355-30 supporting R&D activities)