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.
- What the Core Activity was
- What Knowledge Gap existed
- What hypothesis was being researched
- What experiments were performed, ie the results (including failed experiments)
- What new knowledge was gained, and
- What supporting activities were done to support the core research
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.
Developers should avoid using "General" project in their timesheets.
"General" should only be used in rare cases, when you're doing something that:
- Doesn’t fit in any of the existing projects
- Isn’t worth creating a new project, as it won’t be a long term project or repeated in the future