Prior administration of the R&D Tax Incentive frequently misapplied understandings from the physical sciences to the software space, resulting in regulatory uncertainty and imposing ambiguous obligations on software claimants.
Promising new draft guidance from AusIndustry shows an improved awareness of software development processes and documentation.
Determining that the state of the art was insufficient, and R&D was indeed necessary, remains a key regulator focus area. While proving due diligence in this area has been clarified somewhat, explicitly specifying an ‘on balance’ threshold would be better still.
Ambiguity in the legislation permits significant regulator discretion. Manifesting these positive changes will be a product of sustained education within the regulator organisations, of which this is a positive first step.
Following feedback that greater clarity is required for identifying R&D in the software development field, AusIndustry has released draft software industry guidance in the hope of achieving this. This updated guidance is still in draft and subject to consultation.
We welcome the attempts to provide clarity to claimants and re-instil confidence in the R&D Incentive program. Some of the areas that were more uncertain for software R&D claimants have been addressed. In general, these were present in areas where it was implied that a very academia-style project, or biotech/pharma documentation process with explicit records should be present. Some of the language and references that remain may still imply this.
Commercial software R&D typically occurs in a more iterative, agile manner, and whilst records are kept, these often require a degree of cross-referencing and more rigour being applied to capture key aspects (outcomes of research and enquiries being key).
The upfront focus on ‘unknown outcomes’ is great to see as this is critical. Although, this test would be an ‘on balance’ assessment in each case. For example, questions may still remain as to the degree of research and enquiries required to establish the outcome cannot be determined in advance. That is, does a claimant need to have consulted external experts, if it employs experts or competent professionals? Or does worldwide literature research suffice if the employees engaged are demonstrably competent professionals? Also, companies seldom detail why existing approaches/knowledge are inadequate, more so referencing the investigations that occurred. Do these suffice if it is demonstrable existing approaches/knowledge investigated were deficient?
The references to ‘less formal’ format of record-keeping being acceptable, and explanations of what constitutes ‘experimentation’ in software development involving known, repeatable series of steps or methods, are also welcome (albeit could be made even clearer). Previously, defining certain types of tests, or the broadly used term ‘bug fixing’, as rarely being part of a core R&D activity introduced confusion and uncertainty, so it was positive to see a more balanced acknowledgement of this.
Software development predominantly makes use of existing frameworks and methods, yet can still involve R&D. Acknowledging this, and also providing a list of software R&D areas which are emerging, and how this R&D occurs in a commercial scenario would be further welcome.
Ultimately, guidance can be interpreted in a very strict manner, or with a more pragmatic industry-specific lens. We feel that this is a step in the right direction as it shows a focus by AusIndustry to understand and support how software R&D occurs in a commercial environment. Reinforcing commercial confidence in the program’s predictable administration will require positive guidance to be reflected in the regulators’ day-to-day interpretations and judgements.
AusIndustry’s draft software R&D guidance, and the public consultation link can be found here.