On this page

Disclaimer

The information provided in this guidance is general in nature and is intended to assist you to self-assess the eligibility of your R&D activities. If the Department of Industry, Science and Resources undertakes a formal review, your activities will be assessed against the legislative criteria set out in sections 355-25 and 355-30 of the Income Tax Assessment Act 1997.

Common risk areas for software-related R&DTI applications

The software development sector covers the development, integration, testing, deployment and ongoing improvement of computer software. AI represents an evolving area within the broader software sector.

When self-assessing your eligibility for the R&DTI, there are some common risk areas to be aware of if you are conducting software-related activities.

Applying a particular software development methodology does not, by itself, make an activity eligible or ineligible for the R&DTI. Individual activities undertaken as part of any methodology such as agile, waterfall, rapid or similar methodologies may be eligible for the program if they meet all the requirements for either a core R&D activity or a supporting R&D activity.

In software development, a core R&D activity may occur when you encounter a specific technical hurdle that stops you progressing the work because no existing knowledge, method, or solution can resolve it, even for experienced professionals. This may be a specific technical hurdle when adding a new functionality to an application or integrating a new AI agent into a platform.

To overcome this technical hurdle, you work with experts in the field to come up with a proposed solution (the hypothesis) that can be tested. If there is no available information on whether this proposed solution will work (unknown or indeterminable outcome), you may plan and carry out work to test it (the experiment). This progression of work may be eligible as a core R&D activity as long as it is not an excluded activity.

Under the R&DTI, core R&D activities must follow a systematic progression of work. Activities involving testing that do not require a hypothesis to resolve a technical hurdle do not meet this requirement.

While software development work may be technically complex, have implementation challenges or be commercially novel, it often involves applying existing knowledge, techniques, tools and established practices to achieve a defined outcome. Such activities rarely involve a technical hurdle that can only be resolved by undertaking hypothesis-driven experiments.

The following activities are generally considered routine as they involve applying known tools, methods or techniques with predictable outcomes:

  • applying documented configuration options with known outcomes
  • integrating third party services or application programming interfaces by following vendor documentation
  • assembling user interfaces using known user interface components, style guides or frontend frameworks
  • building a dashboard for a website or an application by implementing established design and development patterns, functions and methods
  • migrating data between systems using known tools and established migration approaches.

While these activities are unlikely to be eligible as core R&D activities, they may be eligible as supporting R&D activities.

When applying for the R&DTI, you should carefully group and classify your R&D activities as either core or supporting R&D activities. Avoid combining too many activities into a single core R&D activity, as this can make the description unclear and may affect eligibility. The How should companies group R&D activities guidance provides advice on when and how to do this.

For guidance on AI-related activities, please visit the AI-related activities and the R&DTI page.

Software activity exclusions

Certain activities are not eligible to be registered as core R&D activities under the R&DTI program. A list and detailed explanation of excluded activities is contained in the Guide to Interpretation.

The exclusion that applies specifically to certain software activities is:

  • developing, modifying or customising computer software for the dominant purpose of use by any of the following entities for their internal administration (including the internal administration of their business functions):
    • the entity (the developer) for which the software is developed, modified or customised
    • an entity connected with the developer
    • an affiliate of the developer, or an entity of which the developer is an affiliate.

There are additional exclusions that may also apply to software R&D including:

  • research in social sciences, arts or humanities
  • management studies or efficiency surveys
  • activities undertaken to comply with statutory requirements or standards
  • reproducing a commercial product or process from existing plans, blueprints or publicly available information.

Activities excluded from being core R&D activities may still qualify as supporting R&D activities.

Record keeping for software-related activities

You must keep records to demonstrate the eligibility of your activities and expenditure for the R&DTI. The Record keeping for the R&DTI page provides more information about record keeping requirements and recommended practices.

The following table provides examples of records that may demonstrate the eligibility of software-specific R&D activities. Remember, it is the content contained in the records, rather than the format in which they are kept, that is important when demonstrating eligibility.

Eligibility requirement

Example of records

Outcome that could not have been known or determined in advance

An unknown outcome generally occurs when a technical hurdle exists that could not be solved using known tools, methods or techniques.

The records you keep should show:

  • the existence of a technical hurdle, including details about the specific issue
  • the actions taken to overcome the technical hurdle, including attempts that failed and why those actions were unsuccessful
  • the limitations of existing software technologies, tools, or methods, and why these could not resolve the technical hurdle
  • the actions undertaken to identify and assess alternative solutions, including research, consultation, or preliminary testing
  • the proposed solution or approach, including the technical rationale for why it may overcome the hurdle, despite the outcome still being uncertain.

These may be captured in digital boards, workshop notes, screenshots of questions on technical forums, saved Q&A threads, issue-tracking systems, emails or screenshots of chat messages or dashboards, technical reports, research or meeting notes, and comparison tables or correspondence with experts.

Systematic progression of work (hypothesis, experiment, observation, evaluation and conclusion)

Your records should show how the hypothesis-led experiment was undertaken to solve the technical hurdle. For example, your records may show:

  • the planning of, and the preparations undertaken for, the experiments to resolve the technical hurdle
  • the actions taken, including the description of what was tested and how the test was undertaken
  • the data and results collected, the assessment and analysis undertaken, and conclusions.

This information may be captured in spike tickets or investigation tasks, design notes, architecture decision records, emails and chat messages, test plans and outputs, logs, screenshots of dashboards and system behaviour, meeting minutes, or performance graphs.

Conducted for the purpose of generating new knowledge

Your records should show the purpose of undertaking the activity. This may be found in meeting notes, or reviews undertaken that identify the need to conduct experiments.

Supporting R&D activities directly related to a core R&D activity

Your records should show how the activity supports refining the hypothesis, conducting the experiments, gathering and evaluating the results, and/or formulating conclusions.

Examples

The following hypothetical case studies are designed to help you better understand the eligibility requirements of the R&DTI and identify which of your activities may qualify for the program. These examples provide general guidance only and do not replace the legislative definitions.

Hypothetical Machine Learning case study

Hypothetical case study: Far Side – R&D in a new space