April Fool’s – Response to R&D Taxpayer Alert clickbait

April 1, 2017 by Ben Thompson

The ATO’s release of Taxpayer Alerts regarding the R&D Tax Incentive, and the relative deluge of freak-out responses from industry and consulting firms was, for better use of the term, a case of ‘fake news’.

Given we’re a month out from the 30 April deadline for FY16 claims, and despite being flat-chat with last-minute applications, I couldn’t pass up the chance, on All Fools day, to call out the many clickbait articles posted in the last month (eg: “…R&D advice is a bombshell”“…warning on R&D tax claims… ““Industry of ripoffs…” and “Am I (still) eligible…”).

Nothing the ATO said was new. Rather they restated what is already clearly articulated in legislation and in all guidance materials provided by the ATO and AusIndustry. The ATO did say they will be looking at software development closer as they have impression there are bogus claims out there. And yes, they are absolutely right there are dodgy claims which are being knowingly being prepared by self-applicants and consultants alike.

I believe those complaining about this being a new and terrible approach are by virtue demonstrating their lack of proper understanding and/or complicit ignorance of what constitutes eligible R&D.

Below are some of the key areas the ATO is concerned about and what you need to think about and do as software developers to ensure compliance.

Typical ineligible claims seen by the ATO

All of the project, or a substantial part of it, is registered as R&D activities.

Software projects are typically scoped around business goals, user stories and system requirements. Often the technical implementation of these objectives requires development in untested waters. The successful implementation is not guaranteed and several iterations are required before success is achieved or before failure is accepted.

In these cases R&D activities are conducted as parallel projects in order to achieve broader project goals. The purpose of these activities is specifically to generate new knowledge, with which a successful implementation of a broader project can be achieved.

What you need to do:

  • In your projects separate the R&D activities from the tasks with known outcomes and track time spent for each activity separately
  • Document R&D activities at the point of development. Ensure they are specific and not broadly described. Do not describe project objectives or business and system requirements
  • Do not include the whole, or a large proportion, of your expenditure on the software development project in the calculation of their R&D Tax Incentive claim if most of the tasks within your project had a known outcome

Routine testing steps in software development projects claimed as core R&D activities

Agile software development often uses the language of innovation to describe routine activities. Regular releases, testing and analysis cycles can make it seem like all software development is R&D. This makes it difficult to separate routine activities from eligible R&D. The ATO provides the following examples of activities that are not eligible, however could form a supporting activity if they are directly related to core R&D activities:

  • Bug testing
  • Beta testing
  • System testing
  • Requirements testing
  • User Acceptance Testing
  • Data mapping and data migration testing
  • Testing the efficiency of different algorithms that are already known to work, and
  • Testing websites in operation by measuring the number of hits.

What you need to do:

  • Don’t present routine activities as a core R&D. They can be a supporting activity if they are performed in aid of a core activity, but they are ineligible if they are performed in aid of a feature with a known technical outcome.

Undertaking activities that involve business risk rather than technical uncertainty

The crux of an R&D activity is an experiment seeking to prove or disprove a technical hypothesis. The hypothesis must be a technical one (ie will this software work) not a commercial one (ie will users click it?). Not all activities which seemingly have uncertainty or follow a systematic process are eligible R&D activities.

In the initial phase of a new software project, it’s typical to document all the known risks. The audience for this risk log is usually business staff, so business risks are highlighted over technical ones. Sometimes, technical staff can feel they are underselling their abilities if they overstate very real uncertainties. It’s important that all technical uncertainties are well documented both at the beginning and during the life-cycle of a software development project

What you need to do:

  • Technical staff write and maintain a document of technical risks and uncertainties throughout a project lifespan
  • Categorise and separate commercial risks from technical risks. Don’t submit commercial risks in your R&D application

Still unsure about your own claims or that of your advisors?

If you’re unsure whether activities are eligible for the R&D tax incentive don’t be put off applying by the ATO alert. The best AusIndustry docs are ‘The Guide to Interpretation’ and Sectoral Guidance for ICT, both contain the basics, applying them to different scenarios. Still in doubt, speak with AusIndustry or an expert for free advice.

In closing, there is no need to be alarmed. If you are playing the rules then keep calm and carry on. If you’re not then best make amends and re-evaluate which trusted advisors you keep in your corner.

Insert marketing here:

No article would be complete without some kind of pitch, so here it is ours; TechLever’s approach to identifying R&D is different to many consultants by virtue of the team being scientists first, and tax agents second. We thirst for knowledge before dollars which means if a client’s ‘story’ doesn’t stack up and it lacks detail or documentation then we don’t proceed. We unashamedly put our clients through the wringer as part of our due diligence. If a client can’t provide answers for us to write their submission – then they aren’t doing R&D as defined in legislation, simple as that.

We present strong coherent arguments which are backed up by data and a basis of why work stands out from business-as-usual. Our process involves not just pointing at what is R&D inside a business but explaining why it is such. If a client isn’t on board with a claim, and an audit matter arises, then we can’t fight it to the death if we’re all not equally committed. Having written over 250 applications since the inception of the Incentive, with 100% success, our hard-line approach works.