What counts as technical uncertainty for the R&D Tax Incentive?

What does “technical uncertainty” mean for the R&D Tax Incentive?

Technical uncertainty, in R&D Tax Incentive terms, means the outcome of an activity “cannot be known or determined in advance on the basis of current knowledge, information or experience” and can only be found by experiment. The phrase comes from section 355-25(1) of the Income Tax Assessment Act 1997, which defines core R&D activities as experimental activities:

(a) whose outcome cannot be known or determined in advance on the basis of current knowledge, information or experience, but can only be determined by applying a systematic progression of work that: (i) is based on principles of established science; and (ii) proceeds from hypothesis to experiment, observation and evaluation, and leads to logical conclusions; and (b) that are conducted for the purpose of generating new knowledge (including new knowledge in the form of new or improved materials, products, devices, processes or services).

The legislation doesn’t use the words “technical uncertainty”, but it’s the common shorthand for limb (a), and business.gov.au’s own guidance uses the term. business.gov.au’s software guidance talks about a “technical hurdle” that no existing knowledge, method or solution can resolve, “even for experienced professionals”.

This page explains the concept for software buyers. It isn’t tax advice, and it can’t tell you whether your project is eligible.

Technical uncertainty vs difficulty, novelty and commercial risk

Technical uncertainty is about whether the outcome could be known from existing knowledge, not about how hard, new or risky the work feels. business.gov.au’s software sector guide makes the distinction directly: “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.”

What you might have	Is it technical uncertainty?
The work is technically complex or will take a long time	Not by itself
The technology or technique is new to your team	Not by itself, if it’s documented elsewhere
The product is new to the market	Not by itself; that’s commercial novelty
You don’t know if customers will buy it	No; that’s commercial risk
You’re choosing between known options by trial and error	Generally no, per business.gov.au
A competent professional couldn’t know from worldwide knowledge whether any approach will achieve the result, and you test hypotheses to find out	This is what the test describes

Whose knowledge counts?

A competent professional’s, drawing on everything publicly available or reasonably accessible anywhere in the world when the work starts. Not just your team’s knowledge, and not just what’s known in Australia.

business.gov.au describes a competent professional as someone in the relevant field who has knowledge and experience, keeps up to date, and has access to worldwide resources including the internet, industry journals and other professionals. It suggests checking by reviewing technical literature, searching the internet and patents, and asking experts, and says you should keep records of how you determined the outcome was unknown.

Two consequences follow for software:

• “New to us” isn’t enough. If the technique is documented in a vendor guide, a conference paper or a well-known open-source project, the outcome was knowable.
• Trade secrets are different. Information held privately by a competitor, which isn’t reasonably accessible, doesn’t count as available knowledge.

What does a systematic progression of work look like in software?

A written hypothesis, a designed experiment to test it, recorded observations, an evaluation and a conclusion. Trial and error across known options doesn’t meet the test. business.gov.au notes that when a technical question is resolved “by selecting from available options through trial and error (rather than testing a hypothesis through experimentation)”, the activity won’t qualify as core R&D.

A software illustration of the full cycle:

Step	What it looks like in a software team
Technical hurdle	Existing approaches to matching handwritten field notes to asset records fail on the company’s data; published methods assume printed text
Background research	Literature, vendor documentation and expert advice reviewed and recorded; no known method handles this data
Hypothesis	”Combining approach X with constraint Y will reach the target match accuracy on this data, because…”
Experiment	Planned test runs varying defined parameters against a held-out evaluation set
Observation	Results logged with dates, configurations and metrics
Evaluation	Results compared with the target and with the hypothesis
Conclusion	Hypothesis supported, refuted or refined; next experiment planned

business.gov.au lists the kinds of records that support this: spike tickets, architecture decision records, test plans and outputs, logs, performance graphs, meeting notes and even saved technical forum questions showing that nobody had an answer.

Which software activities generally don’t qualify as core R&D?

Work that applies known tools, methods or techniques with predictable outcomes, however complex or commercially new it is. business.gov.au’s software sector guide lists these as generally routine:

• applying documented configuration options with known outcomes
• integrating third-party services or APIs by following vendor documentation
• assembling user interfaces from known components, style guides or frameworks
• building dashboards using established design and development patterns
• migrating data between systems with known tools and approaches

Its AI guidance adds: standard monitoring and logging, routine data cleaning to meet a model’s documented input format, regression and acceptance testing where expected results are known, tuning parameters with established methods where the effect is understood, and plugging known model outputs into applications. One of its worked examples concludes that desktop research to choose a technology stack for a RAG chatbot built from proven platforms is not core R&D, because the outcome could be determined from existing knowledge.

Routine activities like these may still be eligible as supporting R&D activities if they directly relate to a genuine core R&D activity, subject to the rules for supporting activities.

Examples: what might and might not involve technical uncertainty

Scenario	Likely view	Why
Building a customer portal on Next.js with Stripe payments and a CRM integration	Unlikely to be core R&D	Established frameworks and documented APIs; outcome predictable
Adding a RAG assistant over company policies using a standard vector database and a hosted model	Unlikely to be core R&D	business.gov.au’s own example treats this pattern as determinable from existing knowledge
Developing a new approach to real-time scheduling where published algorithms fail under the product’s specific constraints, and testing hypotheses about a new method	May involve technical uncertainty	Specific hurdle, known methods tried and failed, hypothesis-led experiments
Testing whether a model architecture can meet accuracy targets in a domain with sparse, unusual data where it’s not known to work	May involve technical uncertainty	Matches business.gov.au’s AI examples of experimentally testing an architecture in a new domain
Custom HR and payroll workflow software built for the company’s own use	Excluded from core R&D	Internal administration exclusion, s355-25(2)(h)
Rebuilding a competitor’s product feature from its public documentation	Excluded from core R&D	Reproduction of a commercial product, s355-25(2)(g)

These are simplified illustrations to show how the test works. Real eligibility depends on the specific facts, records and how activities are grouped.

What is the internal administration software exclusion?

Section 355-25(2)(h) excludes from core R&D any “developing, modifying or customising computer software for the dominant purpose of use by” the developer, or connected entities or affiliates, “for their internal administration (including the internal administration of their business functions)”. In plain terms: software built mainly to run your own back office, such as finance, HR, rostering or internal reporting, can’t be core R&D however technically challenging it is.

The key words are “dominant purpose”. Software built mainly to sell, license or provide to customers isn’t caught by this exclusion, though it still has to meet the core R&D test. Mixed-purpose projects need careful analysis by an adviser. Other exclusions in s355-25(2) that often touch software include market research, management studies or efficiency surveys, compliance with statutory requirements or standards, and reproducing a commercial product.

Self-check before you talk to an adviser

Use this to prepare for a conversation with a registered R&D tax agent, not to decide eligibility yourself:

• Can you state the specific technical hurdle in one or two sentences?
• Have you recorded searches showing no existing solution worldwide?
• Is there a written hypothesis that could be proven wrong?
• Were experiments planned, with results and conclusions recorded?
• Is the software mainly for customers or sale, not internal administration?
• Are core activities separated from routine build work in your records?
• Is the company the eligible entity that conducts the R&D and bears the cost?
• Do you know the registration deadline, 10 months after your income year ends?

Where to get a reliable answer

From a registered tax agent who specialises in the R&D Tax Incentive, backed by the official guidance. The program is self-assessed, which means your company carries the risk if the Department of Industry, Science and Resources or the ATO later disagrees. You can check an adviser’s registration on the Tax Practitioners Board public register. For certainty before spending, the department offers binding advance findings.

business.gov.au also notes that the Government announced changes to the R&D Tax Incentive in the 2026 to 27 Budget, starting from 1 July 2028, with the current rules continuing until then. As announced, they include removing supporting R&D activities from the offset and raising the minimum spend from $20,000 to $50,000; the ATO notes the measure is not yet law. Check the latest position with your adviser.

For how the incentive interacts with project budgets, see how the R&D Tax Incentive affects the cost of building software, and for the broader rules, what qualifies for software development and AI and machine learning projects.

How All Webbed Labs approaches this

We aren’t a registered tax agent and we don’t assess or promise eligibility. What we can do as your engineering team is keep the kind of records the guidance describes as the work happens: technical hurdles, research notes, hypotheses, experiment plans, results and decisions, stored in your repository alongside the code. We identify likely areas of genuine technical uncertainty during discovery so you can raise them with your adviser before the build starts. See our R&D Tax Incentive page for how we structure and document software projects with the incentive in mind.