This week AusIndustry released an updated guideline to claiming software development as an eligible core R&D activity under the R&D Tax Incentive.

What can software developers do to ensure that their software development activities are more likely to pass as eligible core R&D activities?

Tightly frame the experimental hypothesis

The challenge for all experiments is in the planning and set-up phase. First, the experiment must be framed as a hypothesis. A hypothesis is a statement of an intended (positive or negative) outcome that can be proved right or wrong by experiment. For example, framing the development hypothesis of a new algorithm to improve early diagnosis of melanoma might be “That the relationship between variable B, C, and D provides a 20% increase in early detection of a specific type of melanoma compared to standard clinical mole screening tests”.

A well-framed hypothesis allows the experimenter to define a set of sequential questions that must be answered for the hypothesised outcome to be true. In the above example, to deliver a 20% better outcome the experimenter will be able to describe the supposed relationship between variables B, C and D that needs testing, and list the reasons why this might be true or not true. Articulating the hypothesis foundations helps to clarify the reasons for the experiment. It also helps to show why the answers to the questions above cannot be determined without experimentation, or by extrapolating existing knowledge, information or experience (the knowledge baseline).

Document the knowledge baseline

The knowledge baseline represents the information reasonably accessible at the time of the experiment. Experience means the expertise of a competent professional (not a novice) in the field. Searching the literature, the internet, or speaking with external experts, where this is not commercially sensitive, is expected to show that the experimental questions have not already been answered elsewhere. Documenting why the knowledge baseline cannot answer the experimental questions is important.

The guideline says that the search should be worldwide. Although not a legislated requirement, our interpretation is that the search should be across the applicant’s industry at least, if not across the field of technical expertise. It should be purposeful and diligent. This recognises that it’s not possible to determine that no one else has ever solved your experimental questions; only that reasonable attempts have been made in this direction.

Demonstrate new knowledge

The legislation and guideline says that the purpose of the experiment must be to develop new knowledge. This is more easily proved if the searches described above have been properly done because they show the knowledge baseline at the time of the experiment, and that the experimental questions extend beyond it, creating a knowledge gap the experiment will close.

Document experimental activity

Maintaining good contemporaneous documentation from hypothesis to experiment to what was learned about the hypothesis and the next stage of work is good practice and required.

The process of systematic experimentation is what sets eligible R&D apart from standard software development work. Activities that lack process and are not well documented or chase end of year R&D tax incentive rebates may aim at new knowledge but are much more exposed to audit scrutiny.

Is software R&D dead?

No. However, software engineers developing innovative algorithms driving AI, AR, defence, medical IoT, and manufacturing systems must implement the procedures needed to qualify their developments as eligible R&D activities.

Alternatively, if these innovations can be linked to hardware innovations that independently qualify as eligible core R&D activities, they can be claimed as support R&D activities. For many, this might seem a safer path.




Share This