Cracking the code – How to claim software R&D through the RDTI program

So, when the ATO conducted a review into potential improvements to the scheme in May 2021, you would also be forgiven for thinking that they would identify the need for a separate method of dealing with software based claims. Instead, they insisted that ‘through the release of refreshed guidance’¹ the scheme was more than capable of dealing with software R&D through the program.

And finally, in April 2022, when the Department of Industry, Science, Energy and Resources (AusIndustry) released this recent guidance, you’d again be forgiven for thinking this would help add some much needed clarification. But once again, this new guidance has provided little in the way of elucidating exactly what activities can be claimed, showcasing only one case study that has since been described as ‘grossly inadequate’².

So what’s the big fuss with software based R&D? Why are these claims anything but straightforward? What can you do to effectively claim your R&D? Can these questions be answered in a two minute read? Will it be a fun read? The answer to at least one of these questions is an emphatic ‘yes’!

While there are many issues associated with claiming software based activities under the RDTI, the biggest one surely lies in AusIndustry’s definition of a core activity:

An experimental activity, whose outcome cannot be known at the outset, performed for the purpose of generating new knowledge.

Or, to put it another way:

R&D work = activity; // define ‘work’ as variable type ‘R&D’, set value equal to activity
if (work == experimental && work == new knowledge && work == unknown outcomes) {
work = core activity; // determine whether work was a core activity
} else if (work == needed for core activity) {
work = supporting activity; // determine whether work was a supporting activity
} else {
work = ineligible; // work cannot be claimed
}

And herein lies the problem - applying software activities to this definition can elicit two entirely reasonable, and yet completely opposite, answers. For example, would writing an existing program in a new language be considered new knowledge? It looks the same, it acts the same, and it costs the same, but it is undeniably different. As there is no one-size-fits-all definition of ‘new knowledge’, answering this question depends purely on your own understanding of the term.

The guidance provided is just that: guidance. All you can do is seek the right advice from RDTI experts to align your R&D with the definitions and hope that AusIndustry interprets it the same way you do.

The definition works well for ‘physical’ research (engineering, clinical trials, lab work), where the world imposes limits on what is, and isn’t, possible. For example, I didn’t know if I could build an anti-gravity device and, by Jove, wouldn’t that be some fantastic new knowledge. However, it works far less well for ‘digital’ research, where the possibilities are endless and the unknowns are, consequently, few and far between. The grey area as to what constitutes software based R&D is so vast that being able to describe your R&D appropriately has become essential for a successful claim.

As for how to write a robust description of your R&D for the RDTI application? All R&D is different, but here are 5 quick tips for software:

1. Use metrics to form measurable hypotheses.
2. Describe, in detail, how these metrics were tested.
3. Keep a record of key bugs and issues throughout development.
4. Have a thorough understanding of current knowledge in the field.
5. Justify why any supporting activities were needed to conduct a core activity.

Or, you could save yourself the trouble of navigating this minefield and instead contact an experienced R&D tax consultant.