R&D Tax Incentive for Software Development
Can software development qualify for the R&D Tax Incentive?
Yes, but difficult or innovative software is not automatically R&D.
Software development can qualify where the technical outcome could not be known or determined in advance from existing knowledge, information or experience, and experiments were required to work out the answer.
The important distinction is between ordinary software engineering and genuine experimental development.
When does software development qualify as R&D?
Under section 355-25 of the Income Tax Assessment Act 1997, a core R&D activity must involve an outcome that cannot be known or determined in advance on the basis of current knowledge, information or experience and can only be determined by applying a systematic progression of work based on principles of established science.
That progression must proceed from hypothesis to experiment, observation and evaluation and lead to logical conclusions. The activity must also be conducted for the purpose of generating new knowledge.
For software companies, the difficult part is rarely proving that development occurred.
The difficult part is showing why the technical outcome could not reasonably have been determined before the experimental work started.
Difficult software development is not necessarily R&D
Software companies often tell us the development was complicated, took months, required several attempts or produced something nobody else had built.
Those facts may be relevant. None of them proves R&D eligibility by itself.
We normally start with a narrower question: could a competent professional have determined the technical outcome using knowledge, information or experience that was reasonably available at the time?
If they could, the work may simply be difficult engineering. If they could not, we then want to understand why and what experiments were conducted to resolve the uncertainty.
Routine software development versus software R&D
Routine API integration
A development team integrates a documented API using published technical instructions and established methods.
Uncertain integration behaviour
The available documentation and known approaches cannot establish whether the required integration behaviour is achievable, so competing technical approaches are designed and tested.
Routine performance tuning
Developers apply established database or infrastructure optimisation techniques to improve performance.
Uncertain performance outcome
Different architectures or algorithms must be tested because the required performance cannot be predicted from existing knowledge.
A software R&D example: when the algorithm did not behave as expected
One software project Bulletpoint worked on involved a compliance system that needed to analyse complex, interdependent time periods and identify regulatory breaches.
The development team encountered several technical problems. The algorithm could not correctly calculate backwards and forwards across multiple reference points, longer reporting periods produced unacceptable page-load times, and the system stopped identifying later breaches once the first breach had been recorded.
The team developed and tested different approaches. The results were observed, the algorithm was modified and the process was repeated.
The R&D story was not simply that the company built innovative compliance software.
The stronger R&D story was the narrower technical problem, why the outcome could not be determined beforehand, what was tested and how the results changed the next iteration.
Don’t automatically claim the whole software project
A substantial software project usually contains a mixture of experimental and routine work.
- routine feature development;
- UI and UX work;
- standard integrations;
- maintenance and bug fixes;
- commercial deployment;
- customer-requested changes; and
- a narrower set of potentially experimental technical activities.
If the claimed R&D activity sounds almost identical to the company’s product roadmap or sales description, it is probably still too broad.
The R&D activity should explain the technical uncertainty and the experiments, not simply what the product does.
The questions we’d ask your CTO
- What couldn’t you determine before the experimental work started?
- Why couldn’t an experienced developer work it out from what was already available?
- What research did you do before deciding experimentation was required?
- What did you think might solve the problem?
- What did you actually test?
- What happened?
- What failed or behaved differently from what you expected?
- What did you learn from the result?
- What changed in the next iteration?
- What records from the time show that this happened?
What evidence should a software R&D claim have?
Software companies often already create useful R&D evidence as part of normal development.
Development records
- Git commits and branches
- Jira and spike tickets
- Sprint records
- Architecture decision records
Experimental evidence
- Test plans and outputs
- Performance benchmarks
- Logs
- Prototypes
Technical context
- Design notes
- Architecture diagrams
- Slack, Teams or email discussions
- Technical reports and meeting notes
Having GitHub and Jira does not prove that R&D occurred.
A commit saying “fixed performance issue” tells us very little. A sequence of records showing the technical problem, proposed approach, test, result and resulting technical decision is much more useful.
Ideally, the evidence lets someone follow the technical story:
uncertainty → hypothesis → experiment → observation → evaluation → conclusion.
What if the R&D wasn’t perfectly documented at the time?
This is common. Developers document what they need to build and ship software. They do not usually stop during a sprint to write an AusIndustry explanation.
That does not mean an R&D story should simply be created after the event.
We would look for the records that already exist and test whether they support what the technical team says happened.
A polished R&D narrative prepared after year end with very little contemporaneous evidence showing the technical uncertainty, experiments and results.
Can internal software development qualify?
Section 355-25(2)(h) excludes from core R&D activities certain software development where the dominant purpose is use by the developer, a connected entity or certain affiliates for their internal administration, including the administration of business functions.
So the purpose and intended use of the software matter.
Software developed as a commercial product for customers is different from software developed predominantly to administer your own business.
Simply describing an internal system as a future commercial product does not change what actually happened.
We would want the records to support the purpose that existed while the development was being undertaken.
Does AI-assisted coding change the R&D test?
Using ChatGPT, Claude, Codex, GitHub Copilot or another AI coding tool does not automatically make software development eligible or ineligible.
The underlying test remains the same.
But AI can change the factual question.
If an experienced developer can use readily available AI tools, documentation and existing knowledge to determine the solution, we would want to understand why the claimed technical outcome genuinely could not have been determined in advance.
The important issue is the experimental activity, not who — or what — typed the code.
For the detailed treatment, see our AI and the R&D Tax Incentive guide.
Common problems we see with software R&D claims
Claiming novelty instead of technical uncertainty
A commercially unique product can still be built entirely with established technology and known development methods.
Describing features instead of experiments
“We developed a scalable platform” describes an output. It does not explain what could not be determined beforehand or what was tested.
Treating every technical problem as R&D
If an experienced developer can solve the problem using established engineering approaches, difficulty alone does not make it R&D.
Calling ordinary trial and error an experiment
The work should test a hypothesis and produce observations that can be evaluated to reach a logical conclusion.
Claiming too much of the development team
Software teams usually perform a mixture of experimental and routine work. The expenditure methodology should reflect what people actually worked on.
How Bulletpoint approaches software R&D claims
We don’t start by asking how much you spent on developers.
We start with the technical work.
For a meaningful software claim, that usually means speaking with the founder, CTO or technical lead and identifying the parts of the development where the outcome genuinely could not be determined beforehand.
We then separate:
- core R&D activities — experimental activities that meet the legislative requirements;
- supporting R&D activities — activities connected to the experiments that satisfy the applicable supporting-activity tests; and
- ordinary development — valuable engineering work that should not be presented as R&D.
A serious software company does not need its entire product roadmap rewritten as an R&D application. It needs the strongest activities identified, properly explained and supported by evidence — with routine development left out.
Related R&D Tax Incentive guidance
Artificial intelligence and R&D Tax
How AI development and AI-assisted coding affect R&D eligibility.
R&D record keeping and evidence
What records help support a defensible R&D claim.
Core R&D activities
How the core activity test works under the R&D Tax Incentive.
R&D tax consultant
How Bulletpoint approaches substantial and technically complex R&D claims.
Written and reviewed by
Ben Cusack
Managing Director, Bulletpoint Consulting
Ben works with Australian companies on R&D Tax Incentive claims, including software, AI and technically complex development projects. His focus is identifying the genuine experimental activity, testing the technical story and making sure material claims are properly supported.
Need a specialist review of your software R&D?
If your company is investing materially in software development and you’re unsure where ordinary development ends and eligible R&D begins, we can review the technical work with you.