Software is eligible for the R&D Tax Incentive on exactly the same terms as any other field: there is no software-specific test. What matters is whether a specific activity had an outcome that a competent professional could not have known in advance, and whether you resolved it through a documented progression from hypothesis to evaluation. Most commercial software development does not meet that bar. The parts that do are usually narrower than founders expect.
The eligibility gates in order
Four questions decide whether a software company has a claim, and they are assessed in sequence.
- Is the claimant an eligible R&D entity? Broadly, a company incorporated in Australia (or an eligible foreign resident), lodging an Australian company tax return.
- Does at least one activity meet the core R&D activity test in s 355-25? Assessed per activity, never per project.
- Which remaining work is genuinely supporting under s 355-30?
- Is there at least $20,000 of notional R&D deductions, and contemporaneous evidence to substantiate it? (Or expenditure paid to a Registered Research Service Provider or contributed under the Cooperative Research Centre program, which is claimable regardless of amount.)
Fail gate two and nothing downstream matters. That is where almost every software eligibility dispute lives.
The R&D entity test
Companies incorporated in Australia qualify as R&D entities. A foreign company can also qualify where it is a resident of a country with an Australian double tax agreement and carries on the R&D through a permanent establishment in Australia.
Trusts, partnerships and sole traders cannot claim, with the narrow exception of a public trading trust with a corporate trustee. If you are trading through a non-corporate structure, the structure has to change before the activities are registered, not after.
Core R&D activities under s 355-25
A core R&D activity is defined in s 355-25 of the Income Tax Assessment Act 1997 as an experimental activity whose outcome "cannot be known or determined in advance on the basis of current knowledge, information or experience". That outcome can only be determined by a systematic progression of work that is based on principles of established science and "proceeds from hypothesis to experiment, observation and evaluation, and leads to logical conclusions".
It must also be conducted for the purpose of generating new knowledge. Both limbs apply: an unknown outcome resolved by ad hoc tinkering fails, and a beautifully documented experiment with a predictable outcome fails too.
Assess per activity, not per product
Eligibility is self-assessed activity by activity. A typical registration has three to seven core activities, each tied to one discrete technical hurdle. AusIndustry's software sector guidance specifically warns against over-grouping, because bundling the whole build into one activity makes the description unclear and can itself affect eligibility.
The competent professional benchmark
The test is not what your team knew. It is whether the outcome was determinable from knowledge, information or experience that is publicly available or reasonably accessible anywhere in the world, judged by a competent professional in the field: for software, an engineer or ML practitioner who keeps current with literature, patents and open-source work.
A competitor's trade secret is not reasonably accessible, so a genuine knowledge gap can exist even where someone has privately solved the problem.
What counts as technical uncertainty in software?
Technical uncertainty means a competent professional could not predict, model or calculate the outcome without running the experiment. Difficulty, cost, deadline pressure and team inexperience are not uncertainty. In practice, defensible software uncertainty takes three shapes.
- A measurable target at a stated scale. Latency, throughput, accuracy, memory or unit cost at a concurrency or data volume that no published result demonstrates.
- Whether a novel approach generalises. Whether a new algorithm, model architecture or data structure converges, holds accuracy, or degrades gracefully outside its published regime.
- Emergent behaviour of a combination. Whether components can be made to interoperate when their combined behaviour is genuinely not knowable in advance.
Notice what each has in common: a number, a threshold, and a falsifiable prediction.
A strong hypothesis reads like this:
A graph-embedding retrieval approach will return relevant recommendations under 150 ms p95 over a 10M-node corpus, where existing collaborative-filtering methods degrade non-linearly beyond about 1M nodes; disproven if no configuration holds latency under target without unacceptable relevance loss.
In GQHC [2024] AATA 409 the tribunal rejected hypotheses that were vague or commercial rather than scientific. "Build a faster search" is a goal. The sentence above is a hypothesis.
Eligible versus routine: a working table
| Activity | Usual treatment | Why |
|---|---|---|
| Novel algorithm tested against a latency or accuracy threshold at scale | Core | Outcome not determinable from published knowledge |
| Whether an ML architecture generalises to your data regime | Core | Genuine unpredictability, hypothesis-driven |
| Building a data pipeline or test harness to run the experiment | Supporting | Directly related to a core activity |
| Integrating a third-party API using vendor documentation | Not eligible | Known method, predictable outcome |
| Configuring documented product options | Not eligible | Applying known tools |
| Dashboards and UI assembly from established patterns | Not eligible | Routine development |
| Bug fixing, refactoring, re-platforming, version upgrades | Not eligible | No technical unknown |
| Data migration with known tools | Not eligible | Established method |
| Internal admin software for your own business functions | Excluded core | s 355-25(2)(h) |
Two further points from the sector guidance. Development methodology is irrelevant: using Agile neither creates nor destroys eligibility. And testing that does not require a hypothesis to resolve a technical hurdle is not core, no matter how rigorous the QA process.
Applying a known technology in a genuinely new context can still be experimental. Moreton Resources Ltd v ISA [2019] FCAFC 120 read "experimental activities" broadly on exactly that point.
Coal of Queensland [2021] FCAFC 54 is the counterweight: applying known methods without a genuine unknown outcome and a documented systematic progression still fails.
Supporting activities and the internal-use exclusion
A supporting R&D activity under s 355-30 is one directly related to a core activity. Where the activity produces goods or services, or falls in an excluded category, it must also be undertaken for the dominant purpose of supporting the core activity.
For most software companies this is where the bulk of the engineering sits: instrumentation, environment setup, data preparation, test harnesses, and the specific build work needed to run the experiment. See core vs supporting R&D activities for how to draw the line.
Software developed for the dominant purpose of internal administration by you, or by an entity connected with or affiliated with you (accounting, HR, records, internal business systems), can never be a core activity under s 355-25(2)(h). The purpose is tested on the whole activity. Embedded control software forming part of a physical device is not caught.
How much an eligible software company can claim
Two rates apply, both set out on the ATO's R&D Tax Incentive pages.
| Aggregated turnover | Offset | Effect |
|---|---|---|
| Under $20M | Company tax rate + 18.5 points (commonly 43.5%) | Refundable, paid as cash to the extent it exceeds tax payable |
| $20M or more | Company tax rate + 8.5 points on notional R&D up to 2% of total expenditure, + 16.5 points above 2% | Non-refundable, applied marginally |
The percentages in the examples below assume a 25% company tax rate; a 30% company adds the same premiums to 30%. The refundable offset is not available to companies controlled by income-tax-exempt entities. Notional R&D deductions above $150M in a year attract the offset at the company tax rate only.
Worked example (refundable). A base-rate startup with $18M turnover has $600,000 of notional R&D deductions: eligible salary and on-costs apportioned by R&D time, contractor payments, apportioned overheads and depreciation. At 43.5%, the offset is $261,000, refundable to the extent it exceeds tax payable.
Worked example (non-refundable). A company at $30M turnover, $25M total expenditure and $2.5M notional R&D, assuming a 25% company tax rate. The first $500,000 (2% of total expenditure) attracts 25% + 8.5 = 33.5% = $167,500. The remaining $2M attracts 41.5% = $830,000. Total offset $997,500.
Evidence software companies actually need
The evidence must be created as the work happens. Tribunals have repeatedly held that retrospective reconstruction fails.
In Absolute Vision Technologies [2022] AATA 2319 the absence of any literature review meant no knowledge gap was demonstrated, and documents prepared later for internal review were not contemporaneous. Royal Wins Pty Ltd [2020] AATA 4320 turned on the absence of contemporaneous evidence that a hypothesis was ever developed or tested.
For a software claim, the practical minimum is:
- A prior-art search dated before the activity started: literature, internet and patent searches, plus any expert consultation, with the enquiries kept.
- The hypothesis, written down before experimentation. Tribunals have treated contemporaneous hypothesis formation as the essential starting point of the activities.
- Iteration records: what was varied, what was held constant, what was measured. Commit history, PRs, Jira tickets, design docs and benchmark outputs all count.
- Evaluation against the pre-stated thresholds, and how each result drove the next iteration.
- Time records tying named people to specific R&D activities.
Rand builds this from the engineering evidence you already generate in GitHub and Jira, so the registration narrative and the expenditure both trace back to artefacts dated inside the income year. More detail in contemporaneous evidence for a defensible claim.
The mistakes that sink software claims
- Treating "new to us" as new knowledge. The dominant failure mode, and the one Absolute Vision turned on.
- Registering the whole product as one core activity. Over-grouping obscures the uncertainty and invites questions.
- Commercial hypotheses. "Improve retention" or "ship a scalable platform" are goals, not testable predictions.
- Claiming the full engineering payroll. Routine build is supporting at best, and only where it is directly related.
- Missing the observation and evaluation step. GQHC required evaluation to be evidenced, not asserted.
- Ignoring the internal-use exclusion on tooling built for your own business operations.
Assessing eligibility before you register
Work through this before drafting anything:
- List each technical hurdle that actually stopped progress during the year, in one sentence each.
- For each, ask what a competent professional with worldwide knowledge could have predicted. Document the search that establishes the gap.
- Write the hypothesis with a threshold and a disproof condition. If you cannot state what would falsify it, it is not a hypothesis.
- Map the surrounding engineering to supporting activities and test "directly related" (and dominant purpose where relevant).
- Quantify notional R&D deductions and confirm the $20,000 minimum, unless the RSP or CRC exception applies.
- Register with AusIndustry within 10 months of year end: 30 April for a 30 June year end. See every date that matters.
The registration form is a field-by-field questionnaire: projects first, then core activities, then supporting activities, with separate fields for sources investigated, why a competent professional could not know the outcome, the hypothesis, the experiment, the evaluation and the new knowledge.
Each field has its own character minimum and its own job. Drafting one narrative and splitting it across the fields is how otherwise-good claims read as thin.
For the full program mechanics, start with the complete guide to the R&D Tax Incentive, then the software development R&D guide and AI and machine learning eligibility. If you would rather have the assessment done against your actual engineering record than against a memory of last financial year, that is the problem Rand was built for.