R&D Tax guidance for software ‘grossly inadequate’


Denham Sadler
National Affairs Editor

The sole case study featured in the federal government’s guidance for software claims under the research and development tax incentive contains a number of errors and would likely not actually be eligible for the scheme, according to a number of tax experts.

AusIndustry earlier this month release new guidance for the self-assessment of software-related R&D activities under the research and development tax incentive (RDTI), which aims to provide clarity around what forms of software development are eligible for the tax break, what record keeping is needed by companies and an example of a hypothetical company applying for the scheme.

A draft version of the guidelines was released in April last year, with submissions on this closing in June 2021. The final version has now been released, nearly a year after consultation finished. AusIndustry also consulted with the Tech Council of Australia and the Australian Tax Office in developing the guidance.

Business fibre

The key piece of information from the guidance is clarification that software R&D under the scheme can make use of existing methodologies, including Agile, Waterfall and Rapid.

The use of these methodologies had previously been used as a reason why a company is ineligible for the RDTI, Michael Johnson Associates chair Kris Gale said.

“This is a very welcome development as use of existing methodologies was recurrently put forward by AusIndustry as a reason to disallow claims in assessments in years gone past,” Mr Gale said.

The guidelines acknowledge that software testing can be experimental development, leaving tech companies on much sounder footing to claim the RDTI with greater confidence, he said.

But the only case study included in the guidelines is significantly flawed and should be removed and replaced entirely.

The guidance includes an example of Far Side, a fictional tech company, applying for the RDTI as its only case study.

But this case study doesn’t reflect how an application should actually be prepared across several aspects, according to Mr Gale.

“It is our contention that a taxpayer application that followed the precedent set out in the example would be at a very high risk of failing any form of assessment or audit activity,” he said.

The AusIndustry case study includes sections that aren’t part of the current RDTI application, and does not match the registration portal application. The sample copy also sets a 1000 character limit but includes 1500 characters in one response.

Another response has a 4000 character limit but the example copy from AusIndustry consists of only 200 characters. This is “grossly inadequate”, Mr Gale said.

“It is highly misleading and would not pass muster in an audit situation.”

This example should be immediately removed from the guidance and a working group should be formed to create more suitable case studies, he said.

“If we are correct regarding the immediate concerns detailed above, the question must be asked about how it is possible that the guidance was released to the market, particularly in light of the working group that has been involved in the revision process for several months.”

“The published guidance is a significantly diminished product in comparison to the original draft,” Mr Gale said.

This case study was also criticised by BDO Australia associate director in tax, research and development Dave Smith, who said some of the answers provided do not include enough detail as previously required by AusIndustry.

“Whilst we agree with the concepts and general approach with the new software guidance material, the lack of detail in the example registration form is a concern that could lead to complacency by some claimants,” Mr Smith said.

“We would have liked to have seen a better example of what details should be included to avoid the likelihood of claimants undergoing further scrutiny of their software R&D claims.”

The software guidance clarifies that existing software development methodologies are eligible for the RDTI.

“You will need to show that the outcome could not be determined in advance and that your methodologies were either used as part of a systematic progression of work that you applied when conducting a core R&D activity, or were used in supporting R&D activities in relation to a core R&D activity,” the AusIndustry guidance said.

The guidance also states that routine testing activities such as debugging and beta testing can qualify as part of a core R&D activity when they are part of a “systematic progression of work”.

Companies must consult a “competent professional” to determine whether the outcome of the R&D activity can be known in advance, the guidance states. But this is not a legislative requirement in the R&D provisions, Mr Smith said.

“It is unreasonable to suggest claimants should be contacting or determining a ‘competent professional’ cannot know an outcome to their idea before undertaking the activity. In most cases, if there was existing knowledge readily accessible, companies would use it,” he said.

Fitting software into the RDTI has been a continual bugbear for the tech sector, leading to calls for an entirely separate scheme for these claims. This has been rejected by the federal government and the Board of Taxation in a recent report.

Do you know more? Contact James Riley via Email.

1 Comment
  1. Napost13@gmail.com 8 months ago
    Reply

    Shock horror the gov might ask some to tough questions to software developers seeking R& D gravy train funding.

Leave a Comment

Your email address will not be published.

Related stories