R&D Tax Incentive for Software Companies
Software development can qualify for the RDTI, but the ATO scrutinises software claims more closely than almost any other sector. We help Australian software companies identify what genuinely qualifies, build defensible technical narratives, and claim with confidence.
Does Software Development Qualify for the RDTI?
Yes, but the bar is higher than many software companies expect.
The RDTI requires genuine technical uncertainty: a problem that a competent software professional in your specific field couldn't resolve without experimentation. Writing code is not R&D. Building a product using established frameworks and documented patterns is not R&D. Solving a technical problem that already has a known solution is not R&D.
Where software genuinely qualifies is at the frontier: novel algorithms, system architectures solving performance problems no existing approach can handle, machine learning with uncertain training outcomes, and distributed systems solving consistency or synchronisation challenges without established solutions.
The three RDTI tests apply equally in software as in any other discipline:
- Technical uncertainty - the outcome is not known or determinable in advance, even by a competent professional
- Systematic experimentation - a hypothesis, test, observation, and evaluation cycle. Not just iterating on a feature
- New knowledge - knowledge not available in the public domain at the time the work was conducted
Understanding RDTI eligibility requirements in full is the starting point for a defensible software claim.
Software R&D: What Qualifies and What Doesn't
The difference between qualifying and non-qualifying software work is not about effort, team size, or product ambition, it's about whether the technical outcome was genuinely uncertain and whether you ran structured experiments to resolve it.
✅ LIKELY QUALIFIES:
- Developing a novel search or ranking algorithm where accuracy and performance characteristics are uncertain before testing
- Custom distributed systems architecture solving consistency or synchronisation problems that existing databases cannot handle
- ML/AI model development: training custom architectures, tuning for specific accuracy-latency tradeoffs with unknown outcomes
- New data compression or encoding schemes for specific payload types not addressed by existing codecs
- Researching and implementing novel security mechanisms where standard cryptographic approaches are demonstrably insufficient
- Building a query execution engine or storage layer optimised for an unusual data access pattern
❌ DOES NOT QUALIFY:
- Standard web or mobile application development using documented frameworks (authentication, billing, CRUD) built to product specifications
- Integrating external APIs or SaaS platforms following vendor documentation
- Routine bug fixes, dependency upgrades, or performance tuning with predictable improvements
- Software developed primarily for your own company's internal operations - this is explicitly excluded by the legislation
For guidance on how eligible expenditure is calculated, see the R&D Tax Incentive overview.
What's Different About Software RDTI Claims
Software claims carry specific risks and nuances that don't apply in other sectors. These are the areas we focus on most closely when working with software teams.
The internal administration exclusion
The legislation explicitly excludes software developed for the dominant purpose of internal administration, including a company's own business functions. This catches software companies that build internal tools, internal reporting systems, or operational platforms. If your software is not sold, licensed, or delivered to external customers, examine this exclusion carefully before claiming.
The competent professional test, applied to software
The RDTI asks whether a competent professional in the field could determine the outcome without experimentation. In software, this means a specialist at the frontier of your specific domain, not a generalist developer. What would an experienced distributed systems engineer, ML researcher, or compiler specialist know? If the answer is available in public documentation, academic literature, or common engineering practice, there is no technical uncertainty.
Agile sprints are irrelevant to eligibility
Agile methodology does not confer RDTI eligibility. Sprints, story points, and standup notes don't qualify work as R&D. Each activity must independently involve genuinely uncertain technical outcomes and structured experimentation. "We ran experiments" is not sufficient evidence. "We didn't know which of three consistency models would meet our latency requirements under partition, so we ran controlled tests with each" is the kind of framing that holds up.
Your dev tools are your documentation
GitHub commit histories, pull request descriptions with technical rationale, Jira tickets detailing failed approaches, architecture decision records (ADRs), and sprint retrospectives can all serve as contemporaneous evidence. You typically don't need a separate documentation system, but the evidence needs to show the uncertainty at the start of an activity, not just that you wrote code. We review your existing artefacts and identify gaps before lodgement.
ATO scrutiny in software is high
The ATO and AusIndustry classify software as a high-risk RDTI sector. Claims described in commercial terms, such as "we built a feature that increases revenue" or "we improved the user experience," are routinely challenged. Claims described in technical terms, such as "we developed a novel cache invalidation strategy where the consistency guarantees were unknown," are not. This distinction in language is a practical matter of claim survival.
How We Help Software Companies
Activity Scoping
We review your development backlog, sprint history, and technical documentation to identify activities that meet core R&D criteria. Most software companies are surprised how precisely the line can be drawn, and which side of it more of their work falls on.
Technical Narrative Writing
We translate your engineering work into RDTI-compliant technical narratives. This is not marketing language, it's precise framing of the uncertainty, the hypothesis, the experiments run, and what was learned. We write with AusIndustry review criteria in mind.
Expenditure Mapping
Developer salaries are the largest eligible cost for software companies. We map time against eligible activities using Git data, time tracking records, or defensible estimation methodologies, and ensure cloud infrastructure and tooling costs are captured where they directly support R&D.
Audit-Ready Claims
Software R&D claims are among the ATO's highest scrutiny categories. We build every claim assuming AusIndustry review will occur, with supporting evidence packages pre-assembled, activity descriptions technically precise, and cost allocations fully documented.
Software RDTI: Frequently Asked Questions
Does SaaS product development qualify for the RDTI?
It depends on the nature of the work, not the product type. A SaaS product can absolutely involve qualifying R&D, for example, developing novel algorithms, solving unique infrastructure challenges, or building ML systems with uncertain outcomes. But standard feature development using established frameworks does not qualify. We assess your backlog to separate qualifying activities from routine development. See our RDTI eligibility guide for the core activity criteria.
Can we include developer salaries in our RDTI claim?
Yes, salary and wages for time spent on eligible R&D activities are the most significant expenditure category for software companies. You need to allocate each developer's time between R&D and non-R&D activities, which requires time tracking, estimation, or Git-based analysis. We help structure this allocation so it withstands AusIndustry scrutiny. See our RDTI overview for the full expenditure rules.
We work in agile sprints - does that satisfy the systematic experimentation requirement?
Agile methodology does not automatically qualify work as R&D. What matters is whether individual activities within those sprints involved genuine technical uncertainty and structured experimentation, forming a hypothesis, testing it, and learning from the result. Sprint membership is irrelevant; each activity is assessed on its own technical merits. Activities with known technical outcomes don't qualify even if they were tagged as R&D in Jira.
What records do we need to support a software R&D claim?
The ATO requires contemporaneous records showing that technical uncertainty existed at the start of each activity and that systematic experimentation was conducted. Your existing dev tools often contain this: GitHub commit history, PR descriptions with technical rationale, Jira tickets detailing the problem and attempted solutions, architecture decision records (ADRs), and test plans. We work with your existing artefacts and identify gaps early so nothing is missing at lodgement. For a full picture of process and timeline, see our RDTI claim process guide.
Software R&D Claim Assessment
If you're building novel software and want to know what genuinely qualifies, and how to claim it without the risk of a challenge, start with a structured review.