As a startup, the R&D tax incentive is possibly one of your main funding sources. And as dedicated startup accountants, we’ve been watching the government’s treatment of it closely.
Here are the main takeaways
To avoid kickback from AusIndustry reviewers of your software development R&D tax claim in future, you’ll need to:
- Take more time upfront to really consider if you’re eligible for it at a more detailed activity level. Rather than assuming you can claim it for an entire project, you’ll need to consider and frame activities as having an unknown outcome that you’re trying to test
- Keep detailed time-based records, as you are doing the work. Not retrospectively. You’ll need to do this for your own time, and work with any contractors to do it for theirs too. Broad percentages of project costs are not likely to be accepted
These definitions aren’t necessarily new but by releasing this guidance, AusIndustry is sending a clear message that it’s going to be paying more attention to these things in particular.
Examples of R&D tax eligibility
The guidance provides some examples to help you understand whether your software development will be eligible for the R&D tax incentive, including:
- Resolving conflicts within hardware or software (think integration)
- Creating new or more efficient algorithms based on new techniques (including all machine learning)
- Creating new and original encryption or security techniques (this is a narrow example, but at least it’s good news for cyber security companies currently grappling with the AA Bill)
It also suggests doing a GitHub search or searching tech blogs and forums to help determine whether or not you’re developing new knowledge.
Examples of what’s not eligible for R&D tax claims
The guidance also provides some examples of what will not be eligible for R&D tax, including:
- Any software for internal business purposes (this has always been the case)
- Customising a product for a particular use, unless during the process knowledge is added that significantly improves the base program (modifying open source software without new knowledge for a different application won’t cut it)
- ‘Routine’ debugging and testing of existing systems and programs (unless this is done prior to the end of the experimental development process). This is worth spelling out. If you’ve got an initial (eligible) development activity that ticks all the new knowledge, hypothesis and experimental boxes, and debugging is part of this, then it would count. But once the system has been launched, any bug fixes will not be eligible, so if your developers are also doing some of this, you’ll need to identify their time on that and exclude it from your R&D claim
If you want to learn more, including the full definitions of experiments, hypothesis and knowledge (and while you’re there, learn more about the Frascati Manual for R&D …!), then download the full guidance materials and a guide to common errors.
Or if you want to chat about your particular case, you could book in a free call with us too.