Quick answer: Software built mainly to run your own business — an ERP, CRM or internal workflow tool — is excluded from being a core R&D activity under s 355-25(2) of the ITAA 1997 when its dominant purpose of use is the internal administration of your own business, or of an entity connected with you, or of an affiliate. Experimental difficulty alone doesn't rescue it, and such work can only be assessed as a supporting activity, never core. For any part to be core, you may be able to point to separable experimental work generating new technical knowledge with a documented hypothesis-and-experiment process — provided it is not itself caught by the exclusion. You self-assess eligibility; there's no guarantee.
20 July 2026 — the 2026–27 Federal Budget proposed R&DTI changes that, if legislated, would apply to income years starting on or after 1 July 2028. This article describes the current rules unless stated otherwise.
Every year we meet founders in Adelaide and around the country who have poured six figures into a bespoke internal system — a custom CRM, an ERP tightly fitted to their operations, an automated workflow engine — and who arrive certain it was R&D "because it was really hard to build." Difficulty is real. But under Australia's R&D Tax Incentive, difficulty is not the test. The law asks a narrower, more awkward question: was the dominant purpose of that software your own internal administration? If so, s 355-25(2) of the Income Tax Assessment Act 1997 keeps it out of the core-activity definition — no matter how clever the engineering.
This is a Your-Money-Your-Life topic. Getting it wrong doesn't just mean a smaller refund; it can mean a clawback, penalties and interest years later. So the honest framing, before you register, is not "was this hard?" but "what new technical knowledge was I trying to generate, and can I evidence the experiment?"
This article walks through the exclusion, why the hinge is purpose rather than who uses it, the narrow escape hatch for supporting activities, and a clearly labelled hypothetical so you can see the line. Its scope is specific: the internal-administration exclusion under s 355-25(2) — the question of what your software was built to do.
The Short Answer: Internal Software Isn't Automatically Out — But It's Often Not Core
Internal-use software is not blanket-excluded from the R&D Tax Incentive. What s 355-25(2) excludes is treating software as a core R&D activity when its dominant purpose is internal administration. That's a specific move on a specific chessboard, not a ban on software claims generally.
For your work to be a core R&D activity, the law requires experimental activities:
• whose outcome cannot be known or determined in advance on the basis of current knowledge, information or experience;
• that can only be determined by applying a systematic progression of work — from hypothesis, to experiment, to observation and evaluation, to logical conclusions;
• conducted for the purpose of generating new knowledge.
If your internal system was assembled from known techniques, configured competently, and integrated well — but with no genuine technical unknown at its heart — it usually fails the core test on its own terms and runs straight into the s 355-25(2) exclusion. Two locked doors, not one.
The claim survives only where there is a real experimental core: a technical outcome that could not be known in advance, resolved by a documented experiment.
What s 355-25(2) Actually Excludes
Section 355-25(2) sets out activities that are not core R&D activities even if they'd otherwise seem to fit. One exclusion covers developing, modifying or customising computer software for the dominant purpose of use by any of the following entities for their internal administration (including the internal administration of their business functions): the entity for which the software is developed, modified or customised — the provision calls it the developer — an entity connected with the developer, and an affiliate of the developer, or an entity of which the developer is an affiliate.
Three features of that wording do the heavy lifting:
“Dominant purpose” — not “sole purpose”, not “a purpose”. The test weighs the software's main intended purpose of use. Incidental external touches don't save it if the centre of gravity is internal administration.
“Internal administration ... of business functions” — this reaches the systems that run you: finance, HR, CRM, inventory, scheduling, internal reporting and back-office workflow.
“Connected with” or an “affiliate” — you can't sidestep the exclusion by having a related entity build or hold the software. Those two limbs close that gap. Both are defined terms in the ITAA 1997 with their own tests, and neither is the separate tax-law concept of an “associate”.
“Dominant Purpose of Use,” Not “Did Outsiders Touch It”: The Hinge
The single most common misreading is to collapse the test into “did outsiders use the software?” That is not the question.
It can bite even if outsiders touch the software.
If you build an internal operations platform and later let a handful of external contractors log in, the dominant purpose of use may still be your internal administration. External use at the margin doesn't flip the centre of gravity.
Experimental difficulty does not override it.
If the software is predominantly for internal-administration use, the exclusion applies even if the development involved genuine technical unknowns. The uncertainty of the work does not turn excluded internal-use software into a core activity. Software caught by s 355-25(2) can only ever be assessed as a supporting R&D activity — never core — and even then it must clear the supporting-activity dominant-purpose hurdle.
Keep two things separate. The s 355-25(2) exclusion looks at the software's dominant purpose of use. The s 355-25(1) core-activity requirement looks for new knowledge generated through a systematic experiment. A core claim has to clear both, and the exclusion is decisive.
Core vs Supporting Activities: The Escape Hatch and Its Limits
Excluded internal-use software work isn't necessarily worthless for the incentive — but its natural home shifts from core to supporting.
A supporting R&D activity is one directly related to a core R&D activity. Where you have a legitimate experimental core, some surrounding software work — configuration, data preparation or building a test harness — may be claimable as supporting activity if it is directly related to that core.
The extra hurdle: for excluded activities of the kind listed in s 355-25(2), s 355-30(2) applies its own dominant-purpose test. The supporting activity must be undertaken for the dominant purpose of supporting the core R&D activity — not dominantly to field an internal tool.
The practical takeaway is to draw a clean line between the experimental work and the business-as-usual internal build. The experiment may be core; the tool-fielding around it is, at best, supporting — and only where it dominantly supports the experiment.
Worked Example: A CRM Build That Fails vs Experimental Work That May Qualify
The following is a hypothetical for illustration only. It is not a real client and contains no representative dollar figures or outcomes.
Scenario A — the internal CRM (fails as core)
A services firm builds a bespoke CRM tightly modelled on its own sales process: custom pipelines, quoting logic, dashboards and integrations to its accounting system. It's a big, difficult build. But every technical problem was solved with known methods; the “unknowns” were requirements and integration effort, not scientific or technological uncertainty. The dominant purpose is plainly the firm's internal administration. This is caught by s 355-25(2) and, separately, doesn't meet the s 355-25(1) core test. Not a core R&D activity.
Scenario B — the genuine technical unknown
The same firm hits a real wall: it needs a matching/ranking algorithm whose behaviour at its data scale cannot be predicted from existing knowledge. The team frames a hypothesis, designs experiments using competing approaches and controlled evaluation against measurable criteria, observes and evaluates results, and draws conclusions. That experimental cycle may be a core R&D activity — but only if that development is not itself caught by s 355-25(2). If it remains part of software predominantly for internal-administration use, the exclusion still applies and the work can only be assessed as a supporting activity, clearing its own dominant-purpose hurdle.
The difference between A and B isn't budget or difficulty. It's the presence of a documented technical unknown resolved by a systematic experiment — and an honest read of dominant purpose.
Documenting to Survive an AusIndustry Review
The incentive is a self-assessment programme with a split of roles: you register your activities with AusIndustry and claim the offset through the ATO. Registration for an income year must generally be lodged within 10 months of the end of that income year — confirm your own deadline against business.gov.au, as it is date-specific.
What actually decides a contested claim is contemporaneous evidence framed in technical, not commercial, terms:
• the hypothesis and the specific technical unknown;
• the experiments run, and why known methods couldn't resolve the question;
• results and evaluation, including failures;
• a clean separation of experimental work from the business-as-usual internal build;
• notes that speak to dominant purpose — why the work was done to generate new knowledge, not primarily to field an internal system.
If your records only describe what the software does for the business, you've documented the case against yourself.
Where an RSP Fits — and What We Can't Promise
Ignition Research is a Registered Research Service Provider (RSP000047), based at Lot Fourteen in Adelaide. Our role is to supply research capability and to structure and document R&D — to help you calibrate whether there's a genuine experimental core, and to build the evidence trail before you register. That's especially valuable on internal-software projects, where the dominant-purpose line is easy to misjudge.
Two things we're careful to say plainly. First, RSP-conducted eligible R&D activities can be claimed even where the usual $20,000 R&D expenditure threshold is not met — a real advantage for smaller experimental programmes. Second, using an RSP does not guarantee eligibility — you still self-assess. No adviser, RSP or otherwise, can promise your claim will pass review.
Offset Mechanics
The refundable R&D tax offset is the company tax rate plus 18.5 percentage points — 43.5% for a 25% base-rate entity — and is available where aggregated turnover is under $20 million and the entity is not controlled by one or more income-tax-exempt entities. An entity so controlled accesses the non-refundable offset regardless of turnover.
The non-refundable offset is the company tax rate plus 8.5 percentage points for R&D expenditure up to 2% of total expenditure, and plus 16.5 percentage points for expenditure above that 2% intensity threshold. A non-refundable offset reduces tax payable and any unused amount is carried forward, so it does not necessarily produce a cash payment. The $150 million figure is an R&D expenditure threshold, not a cap: expenditure above it generally attracts an offset at the company tax rate rather than zero.
Frequently Asked Questions
Q: Is software developed for internal use eligible for the R&D Tax Incentive?
A: Not as a core R&D activity where the software's dominant purpose of use is the internal administration of your own business, or of an entity connected with you, or of an affiliate. s 355-25(2) excludes that, and experimental difficulty does not override the exclusion. Such work can still form part of a claim as a supporting activity, subject to the s 355-30(2) dominant-purpose test. A separable experimental portion may be core only where it is not itself caught by the exclusion.
Q: What does “dominant purpose of internal administration” mean under s 355-25(2)?
A: It's a factual weighing test asking whether the software's main intended purpose of use was to run the internal administration of your own business, or that of an entity connected with you or an affiliate — finance, HR, CRM, workflow and similar. “Dominant” means the primary purpose of use, not merely one purpose among several.
Q: Can an ERP, CRM or internal workflow tool ever qualify?
A: The tool itself, built to run your operations, is the classic excluded case. What can qualify as core is a genuine experimental sub-project — for example, a novel algorithm whose outcome couldn't be known in advance — but only where that development is separable and not itself caught by the s 355-25(2) exclusion.
Q: Is the exclusion about who uses the software or why it was built?
A: It turns on the software's dominant purpose of use, assessed on the facts. A handful of external users doesn't automatically rescue a claim, and the difficulty of the build doesn't override the exclusion.
Sources & Further Reading
R&D Tax Incentive overview — business.gov.au
Check if you are eligible for the R&D Tax Incentive — business.gov.au
Getting help from a Research Service Provider — business.gov.au
Rates of R&D tax incentive offset — ato.gov.au
Refundable and non-refundable offsets — ato.gov.au
Proposed reforms to the R&D Tax Incentive — business.gov.au
Income Tax Assessment Act 1997, Division 355 — legislation.gov.au
Related: R&D Tax Incentive for software and AI
Related: What does not qualify
Talk to Ignition Research before you register or rely on an internal-software project as R&D. A short, honest eligibility conversation about dominant purpose and your experimental core is far cheaper than a clawback.
Note: this article describes the current rules. Changes proposed in the 2026–27 Federal Budget for income years starting on or after 1 July 2028 are not yet law.
This article is general information from a Registered Research Service Provider about the R&D Tax Incentive. It is not tax, legal or financial advice; eligibility depends on your circumstances and you should self-assess and seek your own advice.
