Since the R&D Tax Concession (the Concession) began in 1985, the eligibility of software R&D has been the subject of continuous conjecture and debate so much so that many have likened making a successful software R&D tax claim to untwisting a pretzel.

At the recent AusIndustry workshop which is driving this current series of blog posts, a series of concerns were raised about software claims under the rules of the current R&D Tax Incentive (the Incentive) in the context of the fact that software R&D expenditure represents some 25 to 30% of total claimed expenditure.

These concerns would excuse anyone who concluded that the pretzel is still pretty twisted.
They include:

• Too many projects claimed with only one core R&D activity and an overarching hypothesis
• Failure to differentiate between core and supporting software R&D activities in Incentive   registrations
  Failure to identify acceptable technical unknowns
• Inappropriate claims simply based on the employment of Agile development and incremental methodologies
• Claims predicated on internal business administration software

Despite these concerns, the pretzel can be straightened out. It just takes some time, thought and care. The heart of the issue is that software R&D is harder to separate from software activities that are not R&D than is the case with more traditional industries (eg. product development in a manufacturing environment; process and device development in an engineering environment).

For example, there can be a mistaken assumption that just because new code is being created and tested using an established method (eg. Agile), then the work must involve eligible R&D. Another problem area is the belief that if the hypothesis is centred on the development of a new app, then R&D must necessarily follow. If either of these assumptions is falsely held, this does not mean the project does not include some R&D. It does, however, mean that if the project registration contains these bare assumptions and is reviewed, then there is an increased likelihood that the registration will not have clearly demonstrated that the activities are very likely to be R&D. It will increase the chances that the project will be subject to a compliance review by AusIndustry.

In this blog post, we will look at how an eligible software R&D project is different from a non-R&D project? In the next post, we will look at expenditure eligibility issues.

When does creating, coding, configuring or testing software involve eligible R&D?

In engineering, the activities to design, construct and test something that is clearly not R&D, say a fence, are conducted using a standard methodology. This standard methodology can also be applied to the design, construction and testing of something that is, or includes, clear R&D activities. This is generally understood by most engineers. In the same way, a standard software code development process can be employed to develop new code that is not R&D, say the creation of an alternative standard calculator to replace the one in Windows 10. Yet the same code development process can be used to create new or improved  functionality in a piece of software making it eligible under the Incentive.

The difference lies in the existence of technical uncertainty. For software, just as in engineering, it is not the process that makes the project eligible R&D. It is when the process is used to provide the experimental steps to overcome the prevailing uncertainty. It is the development of the functionality or the new or improved performance aspects which differentiate the software from what is available that give rise to an eligible claim.

The important thing is that it is not known at the time the activity is commenced as to how the uncertainty can be overcome, how the new functionality can be created or how the improved performance can be achieved. Of critical importance is the fact that the way to resolve these uncertainties is by the application of the code creation process which specifically involves a series of experiments that are tested against the hypothesis to establish whether that hypothesis is correct. The application of management techniques to create code using known methodologies and processes is not enough to put the mustard of eligibility on the software pretzel.

We will expand these concepts in our next post about eligible software R&D expenditure.