The R&D Tax Incentive and software development

The R&D Tax Incentive is Australia’s tax offset for companies doing eligible research and development, and software development can qualify, but only the part of the work that tests a technical problem nobody could solve in advance with existing knowledge. Most business software does not qualify, and the R&D Tax Incentive software rules exclude software built mainly to run a company’s own internal administration.

What follows is general information from the Australian Government’s business.gov.au pages, as at November 2026. It is not tax advice. The rules apply in Australia only, and whether your company can claim is a question for your registered tax agent or adviser, with your own figures in front of them.

How the R&D Tax Incentive works

Two agencies run it. According to the program overview, the Department of Industry, Science and Resources registers R&D activities on behalf of Industry Innovation and Science Australia, and the Australian Taxation Office (ATO) processes the expenditure claim in the company’s tax return.

The basic tests, from the eligibility page:

• It is for companies. The entity must be a corporation. A sole trader or a partnership does not meet that test.
• There is a minimum spend. R&D expenditure for the income year must be at least $20,000, unless you use a registered research service provider or contribute to the Cooperative Research Centres Program.
• It is self-assessed. The application page says registration does not confirm your activities are eligible. That judgement is yours, and the department or the ATO can review it later.

The offset depends on the company’s aggregated turnover. These are the rates the overview page gives:

The rules are due to change. The R&D Tax Incentive home page says the Government announced changes in the 2026-27 Budget that start from 1 July 2028, and the current rules apply until then. The detail sits on the ATO’s page about the changes, which would not open for us, so read it there with your adviser.

What counts as core R&D in software

The scheme splits work into core activities and supporting activities. A core activity is the experiment itself. The core activities page sets three conditions:

1. A competent professional could not know or work out the outcome in advance from publicly available knowledge.
2. The work follows a systematic progression: a hypothesis, an experiment to test it, observation and recording of results, evaluation, and logical conclusions.
3. It is done for the purpose of generating new knowledge.

The government’s software development sector guide adds points that matter for anyone building software. A core activity usually starts with a technical hurdle that existing knowledge cannot resolve, even for experienced developers. Your method, whether agile, waterfall or anything else, does not by itself make work eligible or ineligible. And software that is complex, new to the market or new to you does not count automatically, because it often applies knowledge that already exists.

Which software counts under the R&D Tax Incentive

The sector guide lists work that is generally not core R&D, because it uses known tools with predictable results:

• applying documented configuration options with known outcomes
• connecting third-party services or APIs by following the vendor’s documentation
• assembling screens from known components, style guides or frameworks
• building a dashboard with established design and development patterns
• migrating data with known tools and approaches

That list covers most of what a typical business software project involves: a client portal, a booking system, a quoting tool, a CRM connection. Good engineering, but not experimental.

AI gets the same treatment. The AI activities page says using AI in software development does not make an activity eligible, and building on existing AI platforms is generally not R&D when the outcome can be worked out from existing knowledge. Fine-tuning a model with established methods whose effects are well understood is not eligible. A new fine-tuning approach, tried because established methods failed and whose effects are not understood, may be.

The internal administration exclusion

One exclusion catches a lot of business software. The excluded activities page says that developing, modifying or customising software for the dominant purpose of your own internal administration cannot be core R&D. That applies to software for your company, a connected entity or an affiliate. The examples given are payroll, accounting, invoicing, ordering and enterprise resource planning.

The same page says the exclusion does not apply to software that forms part of a device, software used to analyse experiment data, or customer-facing software unrelated to internal administration. Software can serve several purposes, but it has only one dominant purpose, and that is the one assessed.

Two examples, to show the reasoning rather than to rule on anyone’s claim:

• A clinic builds a system to manage rosters, invoices and stock. Its dominant purpose is internal administration, so it is excluded from core R&D however hard it was to build.
• A software company sells a product that must match records from data sources with no shared identifier, and no published method reaches the accuracy it needs. It writes down a hypothesis, tests two approaches, records why the first failed and changes course. That is the shape of a core activity, and the customer-facing parts of the product are not caught by the exclusion.

Supporting activities and the dominant purpose test

Supporting activities are the work around the experiment. The supporting activities page says each one must be directly related to a specific core activity, and you explain the link when you apply.

Some supporting work must also pass the dominant purpose test, meaning supporting the core activity was your most influential reason for doing it. That test applies to activities that are excluded as core R&D and to activities that produce, or directly relate to producing, goods or services. In software terms, building out the product you will sell is normally producing the product. Only the part done mainly to support the experiment can be claimed as supporting R&D.

Records, deadlines and advance findings

Records. When you apply, you declare that you kept records while the R&D was being done. The sector guide says content matters more than format, and suggests showing the technical hurdle, attempts that failed and why, the limits of existing tools, the options you considered, and your planning, results and conclusions. Useful sources include spike tickets, design notes, architecture decision records, issue trackers, test plans, logs and meeting minutes. Records written a year later from memory are much weaker.

Deadline. The application page says you must apply within 10 months after the end of your company’s income year.

Advance findings. If you want certainty before you spend, the advance finding page describes an optional, legally binding decision on whether planned activities are eligible. It lasts for up to three years, must be applied for before the end of the income year in which the activities happen, and late applications are not accepted. The page gives an average processing time of about 90 days.

Work done overseas. The overview page says R&D done outside Australia needs a separate overseas finding. That matters if your developers are offshore, a trade-off covered in our guide to offshore software development.

If you are paying someone to build software

Most owners meet this scheme when a developer or adviser suggests the project might qualify. Before you plan your budget around an offset, work through these questions with your tax adviser:

1. What exactly is the technical unknown, and could an experienced developer solve it from published knowledge?
2. Is the software mainly for your own administration? If so, the exclusion likely applies.
3. Which company is the R&D entity, and does it meet the $20,000 minimum?
4. Where will the work be done, and does it need an overseas finding?
5. Who will keep the experiment records as the work happens?
6. Who owns the code and the results? Our guide on who owns the code covers the contract side.

Treat any promise that a whole project qualifies with care. The scheme is self-assessed, so a claim that fails review falls back on your company.

CentriWeb builds custom software such as portals, web apps and internal tools. Most of it applies known methods well, which the scheme does not reward, and we say so at the start. Plan the project on what it saves or earns, and treat any offset your adviser confirms as a bonus. Our guide to custom software costs helps with that sum.