There has been much (negative) publicity in recent times about software R&DTI submissions being disallowed by AusIndustry and that AusIndustry is cracking down on software applications. See Royal Wins Pty Ltd and Innovation and Science Australia.
This increased scrutiny of software applications has generated a perception that the rules are changing or that the government is targeting software R&DTI applications.
Neither is true. The requirements of the R&DTI have been stable since 2011, and are unlike to change soon. Software applications are subject to the same rules as all other R&DTI applications.
As long as you are scrupulous about the application of R&DTI principles to your software R&D, there should be no problems with your software R&DTI application. Issues only arise where applicants ‘push the boundaries’ or use a creative interpretation of the rules.
This increased scrutiny has led to many companies engaged in software R&D to shy away from the R&DTI program as being too risky (see Software R&D tax Incentive applications – are they risky?). Some R&DTI consultants are also reluctant to submit software R&DTI applications or restrict the scope of applications that they do submit.
Software-based applications are perfectly acceptable under R&DTI – as long as they comply with the requirements of the R&DTI.
Is Software R&D different?
The problem is that the requirements of R&DTI seem very unnatural to most people involved in software R&D, more so than most people involved in R&D. Whether you agree with them or not, the R&DTI requirements are defined in legislation, so we need to work within them.
Unfortunately, there is a lot of very innovative software development that is (for one reason or another) not eligible. The R&DTI is an R&D assistance program, not an innovation program. An idea can be extremely clever and innovative, but without a knowledge gap and an experiment, it will not be eligible for the R&DTI.
Another issue with software engineering is that it is a bit intangible – it is difficult for many R&DTI consultants to explain software R&D concepts. It is certainly difficult for AusIndustry to grasp those concepts and fairly assess software R&DTI applications.
AusIndustry recognizes that software is a bit different and publishes extensive guidance on eligible software R&DTI applications – see Software Development.
AusIndustry recognizes that software development processes bear a superficial resemblance to the R&D process required by the R&DTI. For example, software development is systematic and involves testing. However, that testing is not usually experimental as required by the R&DTI.
“The application of a software development lifecycle does not automatically mean that eligible experimental activities are taking place, nor that the outcome of any technical issues being solved are not using existing knowledge, information or expertise.”
The use of Agile software methodologies is also no excuse for having no supporting documentation for your R&DTI application.
The eligible software R&D Checklist
The checklist you should follow is no different to any other R&D. See “Do You Have Eligible R&D”.
The following areas seem to cause problems with software R&DTI applications:
- What is a knowledge gap?
- What is a hypothesis?
- What is an experiment?
The knowledge gap must be specific – it will be at the detail level, not at the system level. It must also relate to a technical problem (not a business problem or product problem).
There is a bit of a tendency in some software engineering circles to re-invent solutions to problems that others have already solved rather than taking the time to look for that knowledge. Software engineers may also ‘experiment’ with possible solutions because it is easier than undertaking better analysis or looking that bit harder (or at all) in the public domain. While such activities may well be commercially cost-effective, they are not eligible for the R&DTI.
The solution cannot be determinable upfront – either from in-house knowledge, publicly available information or logical reasoning. See Prior art searching for R&D Tax Incentive. You need to be confident that the knowledge you need is not out there somewhere.
“The test is not simply whether the staff in a company could know or determine the outcome without conducting an experiment. The R&D Tax Incentive: A Guide to Interpretation clarifies this on page 11:
Whether an outcome can be known or determined in advance without applying a relevant systematic progression of work is judged by:
- whether a competent professional in the field knows or can determine the outcome (i.e. whether the hypothesis is true or false), without conducting an experiment as part of a systematic progression of work;
- on the basis of knowledge, information or experience that is publicly available or reasonably accessible, anywhere in the world.
The test is an objective test that applies equally to all companies. The test is not solely whether you know the outcome or are able to determine the outcome in advance.”
This is the step in the R&DTI process that many skip over, especially in software R&DTI applications. It is always tempting to jump into code and try something, especially in these days of rapid prototyping and agile development. In software engineering terms, the R&DTI is more like the traditional ‘waterfall’ development methodology – sort of.
The R&DTI doesn’t expect you to do formal analysis and design of your experimental software. Still, you need to stop, think about it and document what you are trying to achieve with your software experiment. What theory or proposition are you testing, and how did you come up with this hypothesis?
This is one of the areas that causes angst in software circles with the R&DTI.
Software development typically involves a lot of testing. Much of it is not experimentation in the R&DTI because it is not undertaken with the objective of generating new knowledge. Most software testing is aimed at showing that the software performs as intended.
AusIndustry considers that the following are not eligible experiments under the R&DTI:
- bug testing
- beta testing
- user acceptance testing
- system testing
- requirements testing
- data mapping and data migration testing
- testing the efficiency of different algorithms that are already known to work
- testing websites in operation by measuring the number of hits.
Prototyping or predictive modelling may well be eligible experiments if the outcome is unknown or involves a significant degree of technical risk.
To have an eligible experiment, there must be a significant chance that the experiment could fail. You will have a theory (hypothesis) that you are testing in the experiment, that may work, but success is far from guaranteed. However, that risk cannot exist because you failed to do adequate searching for the knowledge you needed.
If your R&DTI application is subject to review by AusIndustry, you will be expected to justify your knowledge gap and your experiment.
Where TechAbstract can help with eligible software R&D
TechAbstract has deep expertise in software engineering and has had many years of experience in cutting-edge software R&D. This expertise coupled with a deep understanding of R&DTI requirements allow us to tease out the eligible R&D activities in your software development, and to present those activities in clear and concise terms that AusIndustry can fairly assess.
TechAbstract can work with you to ensure that you have the right supporting documentation in place.
40% of TechAbstract R&DTI submissions are software-based. Tech Abstract will only submit R&DTI applications that we would be happy to defend in an AusIndustry review including, software applications.
So why not talk to us about your software R&D activities today? You may well have eligible R&D activities that you could claim under R&DTI.