Quick answer: Software built mainly to run your own business — such as an ERP, CRM or internal workflow tool — is excluded from being a core R&D activity under section 355-25(2) of the ITAA 1997 where its dominant purpose is use by the developer, or certain connected or affiliated entities, for their internal administration. Experimental difficulty alone does not override that exclusion. Work caught by the exclusion cannot be a core R&D activity. It may only be assessed as a supporting R&D activity where it is directly related to an eligible core R&D activity and is conducted for the dominant purpose of supporting that core activity. A separately identifiable experimental activity may still warrant assessment as core R&D where it satisfies all the core-activity requirements and is not itself caught by the internal-administration exclusion. Eligibility is self-assessed and is not guaranteed.
As at 20 July 2026, the Australian Government had announced R&DTI reforms in the 2026–27 Federal Budget, intended to apply to income years starting on or after 1 July 2028. Until those changes take effect, the program continues to operate under the current legislation.
We regularly meet founders in Adelaide and around the country who have invested substantially in a bespoke internal system — a custom CRM, an ERP closely fitted to their operations or an automated workflow engine — believing it was R&D because it was difficult to build. Difficulty may be genuine, but it is not the legal test under Australia's R&D Tax Incentive. One key question for internal software is whether its dominant purpose of use was the internal administration of the developer's business or that of a relevant connected or affiliated entity. If the exclusion applies, section 355-25(2) prevents the software activity from being treated as a core R&D activity, regardless of the sophistication of the engineering.
This is a high-stakes compliance issue. An incorrect claim may result in the offset being adjusted or repaid, together with applicable interest or penalties. The appropriate question before registration is therefore not simply “was this hard?”, but “what new technical knowledge was the activity intended to generate, and what evidence supports the hypothesis and experimental process?”
This article walks through the exclusion, why the hinge is purpose rather than who uses it, the limited circumstances in which excluded activities may qualify as supporting R&D 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.
Access to the R&D Tax Incentive requires at least one eligible core R&D activity. A separately identifiable experimental software activity may warrant assessment as core R&D only where it satisfies all the core-activity requirements and is not itself caught by the internal-administration exclusion.
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” — The exclusion cannot necessarily be avoided merely because the software is intended for use by a connected or affiliated entity rather than by the developer itself. 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
A common misreading is to reduce the test to “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. Limited external use does not necessarily change the software's dominant purpose of use; that purpose must be assessed on the overall facts.
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 cannot qualify as core R&D, but it may still warrant assessment as a supporting R&D activity where the applicable requirements are met.
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 for an R&DTI Review
The incentive is a self-assessment programme with a split of roles: you register your activities with the Department of Industry, Science and Resources (DISR) and claim the tax 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 the records describe only what the software does for the business, they may not adequately demonstrate the technical unknown, hypothesis and experimental process required to support an R&D position.
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 points should be stated clearly. First, where an entity's total notional R&D deductions are below the usual $20,000 threshold, it may still obtain the R&D tax offset for eligible expenditure incurred to a Registered Research Service Provider for services within a research field for which that RSP is registered, provided the RSP is not an associate of the R&D entity. Second, using an RSP does not guarantee eligibility. The entity must still self-assess its activities and expenditure against the applicable requirements, and no adviser or RSP can guarantee that a claim will be accepted on 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 may still qualify as a supporting R&D activity where it is directly related to an eligible core R&D activity and is conducted for the dominant purpose of supporting that core activity, as required by section 355-30. 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: What does not qualify
Talk to Ignition Research before registering or relying on an internal-software activity as R&D. An early discussion about dominant purpose and the relevant experimental activities can help identify eligibility and evidence risks before an application is submitted.
Note: The Australian Government announced reforms to the R&D Tax Incentive in the 2026–27 Budget, intended to apply to income years starting on or after 1 July 2028. Until those changes take effect, the program continues to operate under the current legislation. Readers should check the latest official guidance before relying on the future measures.
This article provides general information only and does not constitute tax, legal or financial advice. Eligibility for the R&D Tax Incentive depends on the specific entity, activities, expenditure and circumstances involved. Businesses should assess their circumstances against the legislation and current official guidance and obtain independent professional advice where appropriate.
