The R&D tax grant is very beneficial to growing companies doing innovative work. If you're considering R&D for your company, it's important to keep the right documents and follow the right steps in order to comply with Australian R&D requirements.
Each of the following rules are designed to ensure that the following items can be demonstrated in a submission for R&D Tax Incentives.
Read more on the ATO R&D Tax Incentive page.
Follow the below rules and you will be solving these issues, ensuring you're in accordance with the Australian R&D regulations.
When a visit comes from an R&D auditor, they will want to check on what work you have ‘experimented’ with. An experiment, in R&D terms, translates to an iterative series of changes over the same piece of code.
That means you will need to be able to show code you wrote that didn’t work. If you didn’t check that in at some stage, you are in trouble.
To improve visibility into what work has been done, link your PBIs and tasks to the related commits, branches, and pull requests. Every commit, branch, and PR should be associated with a PBI.
Australian R&D laws require you to show the separate attempts you make when developing a feature that counts towards R&D.
For this reason, you should make sure to commit in between every attempt you make even if it does not have the desired affect to record the history of experimentation.
If you have done significant research on a topic, this should be documented.
Create a new task under the PBI and place these resources in the description with a short summary of what you got from this link.
It is really important to understand the difference between a Proof of Concept (POC) and a Minimum Viable Product (MVP). It is also important that clients understand the difference so they know what to expect.
Once a year, someone has to go through every product, find the R&D work that was done, and write it up for the R&D Tax Incentive claim. If the team never defined what it was trying to learn, that person has to reconstruct it from commits and pull requests months later. It is slow, and the story often does not hold together.
Many developers only meet R&D as a section in the sprint review email, and never learn how their day-to-day work becomes part of an R&D claim. When work is not recognised as R&D at the time, the evidence is thin or missing when the report is written.
A pull request that says "I picked this LLM" shows a decision, not an experiment. An R&D assessor needs to see what you tried, what you measured, and why you chose what you chose. Without measured results, you cannot prove the work was experimental.
Business-as-usual (BAU) work such as upgrades, updates and maintenance does not qualify as R&D. Bug fixes usually do not qualify either (see below). If a team's backlog is mostly this kind of work, it will have little R&D to report, even if the work is hard.
R&D reporting is slow because the evidence is scattered across commits, pull requests, issues and people's memories. It is usually pieced together months after the work, when details have been forgotten.
AI agents are good at the gathering, cross-referencing and first-draft parts of this job. They are not good at deciding what is true, so a human must stay accountable for the claim.
Developers should avoid using "General" project in their timesheets.
"General" should only be used in rare cases, when you're doing something that: