Software R&D Tax Incentive applications reported in the media
In recent years, there have been a number of media reports of software R&D Tax Incentive applications (some high-profile) being rejected by AusIndustry as being non-compliant. If you have been following these reports, you will also know that AusIndustry has been cracking down on software R&D Tax Incentive (R&DTI )applications, and you may likely be concerned about this.
Based on those publicized reports, you might even believe that software R&D Tax Incentive applications are in fact very risky in general. From what Tech Abstract has seen, how many companies (and sadly, many consultants) approach software R&D Tax Incentive applications does certainly make them risky. However, just as certainly, they don’t need to be risky, and shouldn’t be risky, as explained below.
Just recently, there was an article by Innovation Australia – Software as an R&D tax incentive claim, which addressed this exact point. This article contained an interview with RDTI advisor Mr Marty Gauvin, who makes several great observations. The first point is that “Australia just does not have a general, tax-based innovation support program”, and Tech Abstract believes that this is what trips up many R&DTI claimants because they think we do, or at least should have.
Again, the article notes that what we do have is “a program forged by scientists, lawyers and economists that supports a strict definition of R&D that does not necessarily support software development”. That may be very true, but it is the situation we currently need to deal with. Also as suggested by the article, rather than criticize the R&DTI program, it is much more productive to work with it. Relatively small changes are needed to how companies do R&D to fit in with what the R&DTI expects.
What is needed in a shift in mindset – true, software development is not a series of scientific experiments, but a lot of software R&D can be cast in this mould. However, to get the most value from the R&DTI, you need to know how to structure your R&D so that you can maximise your claim. As advised in the article, you should talk to your R&D Tax Incentive consultant before you start your R&D, and definitely before the end of the financial year, after which it will be too late to make changes to your documentation.
The purpose of this Tech Abstract blog article is not to debate the definition of R&D in the R&DTI program, but to shed some light on how to productively deal with this definition of R&D. This article will also not go into how to structure your R&D – lookout for a future blog article on that subject.
The goal of Tech Abstract is to assist clients in accessing the funding support available from the R&DTI in its current form. Software R&DTI applications are a specialty.
The background
To understand how the current mindset about the R&DTI came to exist, you need to appreciate how the industry around the R&D Tax incentive scheme has developed.
To provide services in this area, you need to be a registered tax agent. No surprises then that the industry has come to be dominated by accounting firms, who see the R&DTI as another service they can provide to their clients.
The problem is that submitting an R&DTI application is not quite like submitting your tax return. Yes, a tax schedule that needs to be submitted to the ATO as part of the R&DTI application (which is where the tax advisor requirement comes in).
The problem is that before you get to that stage, you first need to register your R&D activities with AusIndustry and get a registration number. Whilst the AusIndustry application also has some financial information in it (and hence needs to be submitted by a registered tax agent), the bulk of the AusIndustry application is actually technical – you need to describe what R&D activities you are claiming and how you believe those activities are eligible for the R&DTI.
Why is there a problem with software R&DTI applications?
The problem is that anyone can write that technical description – you aren’t required to have any particular qualifications. Since most applications are submitted by accounting firms, the technical description is sometimes treated as a means to an end. The task often being given to someone with no technical knowledge and little understanding of R&D.
The danger in that is that in this case, the author will rely very heavily on the quality of the documentation that you (the client) have given to them. Worse, many clients treat their R&D Tax Incentive application as a distraction and don’t go out of their way to provide clear and understandable descriptions of their R&D activities. Hopefully, that doesn’t describe you!
It is common for the client to just hand over project plans or other internal technical documentation that are difficult to fathom by outsiders, and by non-software people. If the consultant isn’t familiar with software concepts (never mind your particular industry or R&D topic), they will really struggle to make sense of your technical documentation. Worse, they are trying to explain the R&D activities to someone in AusIndustry who will not be software-literate either.
The consultant may just want to get the application submitted, so they will often stitch together a description using the material you provide. Not surprisingly, the explanation often becomes quite garbled. The words may look familiar (because they have been copied from your documentation), but maybe out of context. The thread of the narrative will often not make sense because the concepts are not linked together coherently. Why? Because the consultant cannot understand the concepts, you are talking about.
Since they often have no technical knowledge, they are typically in a position where they really cannot judge if the explanation makes sense or not. They certainly cannot infer technical information from your description.
Where things all go wrong
The R&DTI is a self-assessment program – the claimant (you the client, not the consultant) is responsible for ensuring that they comply with the requirements of the program. Being a self-assessment program, just because AusIndustry issues a registration number, doesn’t mean that AusIndustry accepts that your claimed R&D activities are in fact eligible.
So, you the client are lulled into a false sense of security because in all likelihood your claim will be approved by the ATO, and you will receive your refund. However, AusIndustry (and occasionally the ATO) do conduct random (and targeted) audits to check compliance of submitted R&DTI applications much more carefully, and that is where the problems start. This can be up to four years after submission.
All this applies to any R&DTI application, not just software applications. Software-based R&DTI applications seem to have been a particular concern for AusIndustry however. This is partly because AusIndustry does not have in-house software engineering specialists that they can call on. Software engineering by its nature is also a bit intangible and notoriously difficult to understand by outsiders.
The other problem though is that the typical software development process followed by many companies bears a superficial similarity to the R&D process that AusIndustry expects you to follow with your claimed R&D. However, there are important (if subtle) differences.
As an example, most software testing is not experimentation (as required by the R&DTI) – you are merely confirming that the software behaves as it was designed to – no knowledge gap. Also, technical problems are often resolved by analysis, past experience, or by online research – i.e. no experimentation needed. Yes, that is a limitation in the R&DTI, but that’s the way it is…
Software prototyping, on the other hand, may well be valid R&D – you have a theory (hypothesis) for what may work, but you aren’t sure, so an experiment is required – there is a technical risk.
In addition, whilst many software engineers (and indeed some companies) believe that they are doing R&D, they are merely undertaking routine software development. The principles underpinning the R&DTI are not applied to their R&DTI application – there are no knowledge gaps that require R&D or experimentation.
Quite often, however, there is valid R&D, but it is poorly described by the consultant and is not corrected by the client. Or, perhaps the explanation of the R&D isn’t the problem, but the explanation of how the R&D complies with the R&DTI requirements is.
The software R&D Tax Incentive applications checklist
The basic R&DTI checklist is straight-forward:
- You must have a technical gap (a problem)
- Your solution cannot be determinable upfront – either from in-house knowledge, publicly available information, or logical reasoning.
- You need an experiment (e.g. prototyping) to gain the required knowledge needed to test the hypothesis.
- You must have a methodology and structure to your experiment – a logical progression of work that is decided upfront before the experiment is performed.
- Your results from the experiment must show that the hypothesis is confirmed or not.
If you apply these basic principles to your software R&DTI application, you will greatly reduce the risk that your R&DTI application will be rejected by AusIndustry.
In many cases, it is a matter of thinking about the activities in a different way – few people are accustomed to thinking about software development activities as scientific experimentation.
Why software R&D expertise is critical
Whilst this applies to any R&DTI application, with software-based applications it is imperative that the R&DTI consultant have the appropriate (software) technical knowledge and the industry R&D experience to translate your technical explanation into a technically correct, but understandable narrative that presents your R&D in terms that AusIndustry can follow. That narrative must also show how the claimed R&D complies with R&DTI requirements.
Achieving this outcome reliably and successfully simply cannot be done without the technical skills needed to paraphrase or reinterpret the technical explanation you provide to the consultant. Simply recycling your software technical explanation is rarely good enough, as most software engineers are unaware of the amount of jargon they use or the level of assumed knowledge implicit in their explanation.
The point most commonly missed, however, is that the AusIndustry reviewer is not trying to understand your R&D – they are just trying to decide if your R&D is eligible for the R&DTI or not. Claimants who write their own applications sometimes fall into the trap of trying to ‘teach’ their R&D to AusIndustry, sometimes verging into a ‘sales’ document.
How Tech Abstract can help
Tech Abstract has deep expertise in software engineering and has had many years of experience in leading-edge software R&D in industry. This expertise coupled with a deep understanding of RDTI requirements allows 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.
40% of Tech Abstract RDTI submissions are software-based. Tech Abstract will only submit R&DTI applications that we would be happy to defend in an AusIndustry review, and this includes software applications.
So why not talk to us about your software development activities today? You may well have eligible R&D activities that you could claim under R&DTI.
info@techabstract.com