Is performance engineering eligible for R&D tax?

Is performance and scale engineering eligible R&D?

Sometimes eligible

Sometimes. Performance work is core R&D when you must hit a measurable latency, throughput, memory or cost target at a scale where no published approach is known to work, and you resolve it by testing a proposed mechanism. Profiling, caching, indexing and scaling out with documented techniques is routine, however hard it is.

Reviewed by George WalchFacts last verified 24 October 2026

Ordered writes beyond published benchmarks

An illustrative payments ledger built on event sourcing needs 150,000 writes per second with strict per-account ordering in one region. Its review of vendor and independent benchmarks finds the chosen database documented at about 60,000 writes per second under that ordering constraint, and no published design claiming more. The team hypothesises that partitioning by account hash with grouped commits will hold ordering at the target without raising p99 commit latency above 40 ms, and replays recorded traffic at one, two and three times peak against each variant.

Getting ready for peak season

Before its busiest month a retailer profiles slow endpoints, adds two read replicas, puts a cache in front of the catalogue, turns on autoscaling and runs a load test confirming four times normal traffic. It is demanding work and the stakes are high, but every technique is documented and each change behaved as expected. Difficulty and urgency are not uncertainty.

The evidence that supports it

A baseline benchmark with the hardware, configuration and data volume recorded, taken before the experiment began.

A dated review of vendor documentation, published benchmarks and engineering write-ups showing nobody had reached the target under your constraint.

The hypothesis naming the mechanism, the numeric target and the result that would disprove it.

Versioned load-test scripts or traffic replays, so every variant faces the same load.

Results per variant (latency percentiles, throughput, resource use) with profiler output where it explains a result.

The time windows of any production experiment, kept separate from routine monitoring.

Engineers often feel that making a system fast at scale is the most research-like thing they do. Sometimes it is. But the R&D Tax Incentive does not reward difficulty, and a large share of performance work is the skilled application of techniques that are written down.

Turn the target into a test

A performance requirement is a goal: p99 under 50 ms, 100,000 requests per second, half the cloud cost per transaction. Royal Wins [2020] AATA 4320 is a reminder that a hypothesis is a proposition tested by experiment, not an objective. To become one, the target needs three more things:

A proposed mechanism. The specific design, data structure, partitioning scheme or concurrency model you expect to reach the target.
A reason it is unknown. Published benchmarks, vendor limits and engineering write-ups either do not cover your scale and constraint or show others falling short. "Nobody here has done it" does not count.
A disproof condition. The measured result that would show the mechanism does not work.

AusIndustry's software guide puts this as a specific technical hurdle that stops you progressing and that no existing method resolves.

Write the baseline down first. A measured starting point, taken on stated hardware and data before any change, is what lets each later run show whether the mechanism moved the number, and it is the record most often missing when a performance claim is reviewed.

What is routine, however hard

A principle from physical scale-up applies equally to software, and Rand applies it: bigger than before is not uncertainty, and complexity is not uncertainty. In practice the following are usually routine:

Profiling and fixing hot paths, query tuning and adding indexes as the database documentation describes.
Caching, CDNs, read replicas, connection pooling, horizontal scaling and autoscaling.
Upgrading instance types or runtimes and measuring the gain.
Load testing to confirm capacity. The ATO's alert TA 2017/5 lists system testing as ineligible unless it is an experiment that resolves a hypothesis about a specific technical issue.

Edge cases peculiar to performance work

Experiments in production. Many performance hypotheses can only be tested under real traffic. That is allowed, but only the period the test actually ran counts, and the rest of the year's operation does not. Some experiments need weeks of continuous observation, for example to see behaviour across full weekly traffic cycles; then the whole planned window is the experiment, as the plan and records show.
Always-on observability. Dashboards and tracing that run all year serve operations. Monitoring that is not part of an experiment's design is usually neither core nor supporting, even when it later informs one. Observation the plan calls for, such as a dedicated trace or metric captured to evaluate the hypothesis, belongs to the experiment.
Incidents. Outage fixes are routine work under pressure. A genuine unknown exposed by an outage can be investigated later as its own activity.
Rolling out the answer. Once a mechanism is proven, applying it to other services is ordinary work unless a new gap appears.
Load-test rigs. Purpose-built rigs can be supporting for a named experiment.

When the bottleneck is coordination between nodes rather than a single component, see distributed systems; when it is the algorithm itself, see novel algorithms. The compute used for load tests is covered under cloud compute costs, and benchmark records count as contemporaneous evidence only when they were made at the time.

Frequently asked questions

Are load-testing rigs and benchmark harnesses claimable?

They can be supporting activities when they were built to run a specific core experiment, and their records should say which one. A load-test suite kept for routine release checks supports the product, not an experiment.

We hit a hard scaling wall during an outage. Was fixing it R&D?

Rarely. Incident work restores service using known techniques under time pressure. If the outage exposed a genuine unknown that you then investigated through planned tests, that later investigation can be assessed on its own, with records dated from when it started.

Does a performance target written in a ticket count as a hypothesis?

Not by itself. A ticket saying p95 must be under 200 ms is an objective. A hypothesis names the mechanism you expect to reach it, why published results do not settle that, and what result would disprove it.

The R&D Tax Incentive is a self-assessment program. This page is general information, not tax, legal or financial advice; eligibility depends on your circumstances and you should seek independent advice for them.