Software development and the R&D Tax Incentive: where the line sits

Software companies in Australia regularly ask the same question: where does routine software development end and eligible R&D begin? The R&D Tax Incentive is one of the most valuable government programs for technology businesses, but the boundary between an ordinary coding project and a genuine experiment is a line that can be deceptively hard to draw. Get it wrong on the wrong side and you risk overclaiming, which attracts ATO scrutiny and potential penalties. Get it right and you may recover a meaningful portion of your development spend, helping to fund the next iteration of your product.

This article walks through how to think about that line, step by step. It is general information only, not tax or legal advice. Eligibility depends on your specific facts, and you should have a registered tax agent or R&D tax specialist review your position before lodging any claim. The ATO, AusIndustry and the Department of Industry, Science and Resources (as published on business.gov.au) set and administer the rules, and you should always verify the latest guidance for the current income year.

Prerequisites

Before you start assessing individual software projects, there are a few fundamentals to get right. Having these in place will make the line-drawing exercise clearer and more robust.

• A registered company structure. Only an Australian incorporated company (or a foreign company resident in Australia and subject to Australian tax) may claim the R&D Tax Incentive. Sole traders, partnerships, and trusts are not eligible entities.
• Access to your accounting data. The incentive works by offsetting eligible R&D expenditure, so you need reliable financial records. If you use Xero, MYOB, or QuickBooks, GrantsMAX connects directly to your books to pull together the numbers.
• A clear picture of your development timeline. You will need to identify when each activity started, when it ended, and what technical challenges it aimed to overcome.
• A registered tax agent who handles R&D claims. The claim must be lodged with the ATO by a registered agent, and the business remains responsible for its accuracy. GrantsMAX prepares the evidence-backed pack and hands it to your accountant to review and lodge.
• AusIndustry registration. Before you lodge a claim, you must register the R&D activities with AusIndustry within 10 months after the end of the income year. Late registration is usually fatal.

With those in place, you are ready to work through the steps.

Step 1: Start with the legislative definition of eligible R&D

The Income Tax Assessment Act 1997 defines two types of R&D activities: core R&D activities and supporting R&D activities. Both must be conducted for the purpose of generating new knowledge.

A core R&D activity is an experimental activity:

• whose outcome cannot be known or determined in advance on the basis of current knowledge, information or experience (it involves a technical risk); and
• that is conducted for the purpose of generating new knowledge (including new knowledge in the form of new or improved materials, products, devices, processes or services).

The test is not whether the activity is successful. A failed experiment can be eligible; a routine build using known techniques is not.

Supporting R&D activities are activities directly related to core R&D activities, such as building a prototype for testing, but they also exclude a range of things like market research, commercial production, and routine software maintenance. We will explore exclusions later.

Pro tip: Write down the single most important technical uncertainty your project faced. If you cannot articulate it in a sentence, the project may not be eligible.

Step 2: Distinguish what is likely “routine development” from what may be experimental

This is the heart of the line. Routine development uses established methods to achieve a known result. It does not involve a technical risk that requires systematic experimentation.

Consider these examples:

• Building a standard e-commerce website using a popular framework (Django, Next.js) with no novel technical challenge.
• Customising a CRM like Salesforce using its point-and-click configuration tools.
• Porting a mobile app from iOS to Android using a cross-platform template.
• Writing a script to automate a manual data entry process when the logic is already well understood.

None of these activities involve a technical risk that cannot be resolved by an experienced practitioner applying known techniques. They are valuable business activities, but they sit on the non-eligible side of the line.

What may tip an activity across the line is genuine technical uncertainty: you are trying to achieve an outcome but you are not sure if it is even possible, or you do not know which of several possible technical approaches will work. You then design experiments-systematic trials-to resolve that uncertainty.

For instance, developing a new machine-learning model that must achieve a specific accuracy threshold on a novel dataset where no off-the-shelf model is known to work, and you need to experiment with architectures, hyperparameters, and training regimes to find a solution. If the outcome genuinely cannot be predicted by a competent professional in the field, that may be eligible.

AusIndustry’s software development sector guide for the R&D Tax Incentive reinforces this: routine software development, maintenance, and debugging are not R&D. The guide explicitly lists activities that are unlikely to be eligible, such as routine testing, bug fixing, and writing user documentation. It also warns against overclaiming-a theme you will see throughout the ATO’s compliance focus.

Step 3: Understand the explicit exclusions in the legislation and guidance

The law lists several activities that are not core R&D activities, even if they involve some technical work. These include:

• Market research, market testing or market development, or sales promotion.
• Prospecting, exploring or drilling for minerals or petroleum for the purposes of discovering deposits, determining more precisely the location of deposits or determining the size or quality of deposits.
• Management studies or efficiency surveys.
• Research in the social sciences, arts or humanities.
• Compliance with statutory requirements or standards.
• Developing, modifying or customising software for the dominant purpose of use by the entity itself (an important exclusion for internal-use software).
• Any activity related to the reproduction of a commercial product or process.

For software companies, the internal-use exclusion is particularly tricky. If you are building a tool primarily for your own business operations-say, a bespoke inventory system-the dominant purpose test means it may not qualify. However, if the purpose is to develop a product you intend to license or sell to others, that exclusion may not apply. The exact boundary can be complex, which is why expert review matters.

AusIndustry’s software guide also points out that work done to implement an already-chosen solution is implementation, not experimentation. Once the technical uncertainty is resolved, the subsequent work of productionising, scaling, and maintaining the solution is not R&D.

Step 4: Apply the “hypothesis-driven experiment” filter

R&D tax claims stand or fall on whether the activity followed a systematic progression from hypothesis to experiment to observation to conclusion. This is the scientific method dressed in commercial clothing, and it comes straight from the Frascati Manual, the international standard that informs how Australia defines R&D.

For each activity you want to claim, you should be able to answer:

• What was the specific hypothesis? (e.g., “If we combine algorithm A with data structure B, we can reduce latency below 10ms.”)
• What experiment did you run to test that hypothesis?
• What observations did you record, and what conclusion did you draw?
• Did the experiment generate new knowledge (even if the hypothesis was disproved)?

This exercise is not just an academic ritual. It is the backbone of your evidence if the ATO or AusIndustry ever reviews your claim. Without a clear record of hypothesis-driven experimentation, a software project can look like routine development, even if the work felt hard and uncertain at the time.

Warning: Do not retrofit a hypothesis onto a completed project. AusIndustry registrations and claims must reflect the actual activities as they happened. The better approach is to document your technical hypotheses in real time. Even a shared engineering notebook or a brief entry in your project management tool can serve as contemporaneous evidence.

Step 5: Review the AusIndustry software development sector guide in detail

AusIndustry publishes sector-specific guides because different industries present different line-drawing challenges. The software development sector guide is essential reading for any Australian tech company considering a claim.

Key takeaways from the guide:

• Eligible activities may include developing new algorithms, creating novel software architectures to solve a previously unsolved technical problem, experimenting with new encryption methods, or building a prototype where the technical feasibility is unknown.
• Ineligible or routine activities include routine testing and debugging, writing user documentation, minor modifications to existing software, data conversion, and user interface improvements that do not involve technical uncertainty.
• The guide stresses that developing a “new” product for your business is not enough; the work must involve a technical risk that could not be resolved by a competent professional in the field using publicly available information.
• AusIndustry expects you to be able to explain how the work goes beyond standard industry practice. This is where many claims fail: the developer says “it was hard for us,” but in the broader field, the problem might already have a known solution.

If you are reading the guide and thinking, “That sounds like our project,” take it as a prompt to dig deeper. Document precisely how your technical challenge differs from what is publicly known. Reference academic papers, open-source limitations, or prior internal failures that illustrate why you could not simply apply a standard approach.

Step 6: Characterise your software projects using a practical self-assessment framework

To help you walk the line for your own projects, use this structured self-assessment. It is not a substitute for professional advice, but it can highlight where you need more rigour.

1. Define the project boundary clearly. What specific component, module, or system are you evaluating? Avoid claiming an entire product when only one subsystem involved genuine experimentation.
2. List the technical uncertainties you faced. For each, ask: Would a competent software engineer in this field, with access to public knowledge, know how to solve this without running experiments? If the answer is yes, the activity is likely routine.
3. Describe the experiments you designed. These are not unit tests; they are systematic attempts to validate a hypothesis. For example, “We benchmarked three different compression libraries against our proprietary data format to determine which could meet the 5ms latency constraint, because no existing benchmark addressed our specific access patterns.”
4. Identify where the outcome was genuinely unknown. If you began the work knowing exactly how to implement it, the activity is implementation, not experimentation.
5. Separate eligible activities from ineligible activities. A single project may contain both. For example, designing a novel database indexing approach might be eligible, while the rest of the CRUD API layer around it might not be.

Once you have classified your activities, you can start mapping them to time and cost records. That is where your accounting data becomes critical, because the R&D Tax Incentive offsets eligible expenditure. If you cannot separate the eligible from the ineligible costs, you risk overclaiming.

GrantsMAX's eligibility assessment helps surface these lines by reading your Xero data and flagging where a reviewer would ask questions. But the business and its accountant must make the final call.

Step 7: Build an evidence trail that would survive an ATO review

The ATO and AusIndustry both emphasise that the claimant bears the burden of proof. Your evidence needs to show that:

• The activities were registered with AusIndustry on time.
• The activities were actually conducted and were eligible.
• The expenditure claimed is directly connected to those activities.

What does good evidence look like for a software R&D claim?

• Contemporaneous technical records: engineering notebooks, design documents, architecture decision records, and experiment logs. A commit history in a repository can help, but it rarely tells the full story of why a change was attempted.
• Project management artefacts: sprint plans, retrospectives, and task descriptions that reference the technical uncertainty.
• Correspondence: emails or Slack messages where engineers discuss the problem and debate alternative approaches.
• Time records: timesheets that map individual hours to specific R&D activities. Generic “research” entries without detail are weak.
• Financial records: Xero transactions, invoices, and payroll records that tie expenditure to the project.

GrantsMAX’s audit-ready evidence trail feature builds an index across your emails, invoices, and timesheets, tying each cost line to its source document. This does not guarantee a claim will be upheld, but it gives your accountant a much stronger starting point.

The ATO publishes its own guidance on substantiation. As a general rule, if you cannot produce evidence that a reviewer would accept, you should not include the activity or cost in your claim.

Step 8: Engage a registered tax agent who understands software R&D

The final and non-negotiable step is having your claim reviewed and lodged by a registered tax agent. The R&D Tax Incentive is administered through the company’s income tax return, and only a registered agent can interact with the ATO on your behalf for lodgement. Even if you have prepared the activity descriptions and cost schedule internally, the agent must be satisfied that the claim is reasonably arguable before they lodge it.

This is where GrantsMAX’s model fits: the platform prepares a complete pack-activity narratives, a cost structure pulled from your accounting data, and an evidence index-and then passes it to your accountant in a shared workspace. The accountant reviews, refines, and lodges. The business owns the claim throughout. No AI lodges or files anything; a human professional remains accountable for every claim that hits the ATO’s systems.

For accountants and bookkeepers who serve multiple technology clients, GrantsMAX offers an accountant channel that white-labels the workflow so firms can run R&D claims across their client base efficiently.

Common pitfalls (and how to avoid them)

Even experienced software companies stumble on the line. Here are the most frequent traps.

• Claiming the whole project instead of the experimental portions. A project that involved 10% eligible experimentation and 90% standard implementation should only claim the 10%. Lumping them together is a fast track to an adverse ATO finding.
• Failing to register with AusIndustry on time. The clock is strict: 10 months after year-end. A brilliant claim becomes worthless if registration is missed.
• Over-claiming internal-use software. Building a bespoke internal tool may serve the business but often fails the dominant purpose test. Get specific advice here.
• Ignoring the “competent professional” test. If the technical solution would be obvious to an experienced practitioner in the field, it is not R&D, regardless of how hard your team had to learn it.
• Weak documentation. Many audits begin with a request for evidence. If you cannot produce contemporaneous records, the ATO can disallow the claim and apply penalties.
• Not keeping up with announced reforms. For example, the 2026 reform proposes to lift the refundable-offset turnover threshold from $20 million to $50 million. That is not enacted law yet, but it is a significant change that businesses and accountants should track. GrantsMAX’s platform is designed to adapt as rules evolve.

Pro tip: Run a pre-lodgement review with your accountant at least six weeks before the ATO deadline. This allows time to find and fix gaps before the claim is lodged.

Bringing it together: a summary of the line

The line between routine software development and eligible R&D is drawn by technical uncertainty and systematic experimentation, not by how commercially novel or valuable the software is. The following table captures the essence.

If your activities sit squarely in the right-hand column, they may be eligible. If you are unsure, an honest discussion with a registered tax agent or R&D specialist is the safest next step.

Next steps for Australian software businesses

If you are a founder, CTO, or CFO wondering whether your software development work may be eligible, start by reading AusIndustry’s software sector guide closely. Then, look at your own projects through the lens of the self-assessment framework above. If you spot genuine technical experiments, ask your accountant to review them.

For businesses that want a more data-driven starting point, GrantsMAX scans your Xero, MYOB, or QuickBooks data and matches your expenditure patterns against the R&D Tax Incentive and other government grants. It does not tell you that you will receive an offset; it shows what you may be eligible for, and then prepares a pack for your accountant to review. That keeps the professional judgement where it belongs-with a registered tax agent-while saving the weeks of manual assembly that often make R&D claims daunting.

Ready to explore what may be available? Join the GrantsMAX waitlist and be among the first to access an AI grant agent built for the way Australian technology businesses actually work.