Demand Response and VPP Aggregation: When Does Coordinating Distributed Devices Become R&D?

Demand Response and VPP Aggregation: When Does Coordinating Distributed Devices Become R&D?

·18-08-2026

Quick answer: Onboarding devices and configuring an aggregation platform to its documented modes is engineering — the outcome is determinable in advance. A core R&D activity may exist in the narrower case where no established basis predicts whether a control and communications approach can deliver a required aggregate response inside the latency, telemetry-resolution and device-heterogeneity limits of a real fleet, and the answer comes only from a systematic progression of work conducted to generate new knowledge. Market research, market testing and activities associated with complying with statutory requirements or standards are separately excluded from being core. You self-assess.

18 August 2026 — this article describes the current rules. The 2026-27 Federal Budget announced R&DTI changes proposed to apply to income years starting on or after 1 July 2028; those changes are not yet law.

A virtual power plant is a promise about a population: ten thousand batteries, hot water controllers and pool pumps, owned by ten thousand households, reached through four vendor clouds — and a commitment that a stated number of megawatts will move within a stated number of seconds of a signal.

This article is about the coordination layer that keeps that promise: how a dispatch instruction reaches heterogeneous devices, what the operator can observe while it happens, and whether the aggregate response can be produced at all inside the timing envelope. It is not about microgrid islanding and protection coordination, not about sizing solar and storage, and not about EV charging or vehicle-to-grid — each has its own article in our Insights, as does the separate question of defining a field trial that is separable from live commercial operation. This one is about aggregation and dispatch coordination, and it lands on a different part of the statute.

The Statutory Test the Activity Has to Meet, Stated in Full

Eligibility under the R&D Tax Incentive is assessed activity by activity, not project by project. Under s 355-25(1) of the Income Tax Assessment Act 1997, core R&D activities are experimental activities 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 is based on principles of established science and that proceeds from hypothesis to experiment, observation and evaluation, and leads to logical conclusions; and 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 (business.gov.au; ITAA 1997).

Aggregation work has a real body of established science available to it — control theory, estimation and statistical inference, and the queueing and network theory governing message delivery under contention — so the established-science limb is capable of being satisfied. Whether it is satisfied depends on how the particular progression is designed, conducted and recorded, self-assessed activity by activity. The limb that usually bites first is the other one: for most aggregation work the outcome is determinable in advance from protocol specifications, vendor API documentation and platform release notes. (AusIndustry guidance frames that limb by asking whether a competent professional in the field could have determined the outcome in advance; "competent professional" is guidance language, not s 355-25(1).) Scale, integration effort and novelty to the company are not the test.

Configuring a Platform Is Not the Same Problem as Not Knowing Whether the Approach Works

Most of what a demand response or VPP business does is configuration and integration — hard work with a knowable answer. Enrolling a device model whose API is documented, mapping it to a control mode the platform already supports, setting dispatch groups and opt-out rules, standing up dashboards: these apply documented products as designed. business.gov.au lists "running regression, acceptance, or functionality tests using established testing methods to confirm a system works as intended, where expected outcomes are already known" among activities that would not usually be core R&D (AI activities and the R&DTI).

The narrower case differs in kind. It arises when three constraints interact and no established basis says whether the combination can meet the requirement:

Latency: A response specified in seconds must survive a path through the dispatcher, the public internet, one or more third-party vendor clouds, a home gateway and the device firmware. Each hop publishes a typical figure and none of them composes: what matters is the tail across the whole population under simultaneous load — the one condition the vendors' figures were not measured under.

Telemetry resolution: What the operator can observe is coarser than what it must control. If device state arrives at five-minute intervals, the headroom available at dispatch is an estimate, not a measurement, and the response depends on that estimate being right at the peak — when it moves fastest.

Device heterogeneity: A multi-vendor fleet exposes no single control primitive. Some devices accept a pre-armed local trigger, some only a command relayed at the moment of the event, some report state on a fixed schedule. The achievable response is a property of the mix, which no datasheet describes.

Where a company can specify the aggregate outcome it needs but cannot determine from that documentation whether a proposed control and communications approach will reach it, and only instrumented dispatch trials against a hypothesis recorded in advance can settle it, an experimental activity may exist. Where the work is tuning a parameter whose effect is well understood, or scaling infrastructure to a documented throughput, it generally will not. See what does not qualify.

Market and Compliance Testing: Paragraphs (a), (f) and a Note on (g)

Section 355-25(2) lists activities that are not core R&D activities. Three paragraphs sit close to aggregation work:

Paragraph (a) — Market research and development

Excludes "market research, market testing or market development, or sales promotion (including consumer surveys)". Much demand response effort is customer-side — recruiting participants, designing the incentive or tariff, surveying acceptable comfort limits, trialling messaging to lift enrolment. However quantitative, that work sits where paragraph (a) points.

Paragraph (f) — Statutory requirements and standards

Excludes "activities associated with complying with statutory requirements or standards, including one or more of the following: (i) maintaining national standards; (ii) calibrating secondary standards; (iii) routine testing and analysis of materials, components, products, processes, soils, atmospheres and other things". Market registration and conformance testing may fall within paragraph (f) where the activities are undertaken to demonstrate compliance with a statutory requirement or standard, including a requirement imposed by a regulator under legislation. The exclusion is not defeated by the result being unknown: a conformance test can be failed and the activity is still one associated with complying. Nor is there a carve-out running the other way. "Associated with" is broad wording, and where a standard states a required outcome but no established means of achieving it on a particular fleet, whether the work of finding that means falls inside paragraph (f) is a question of fact, assessed activity by activity, and the company self-assesses.

Paragraph (g) — Reproduction of a commercial product or process

Excludes "any activity related to the reproduction of a commercial product or process: (i) by a physical examination of an existing system; or (ii) from plans, blueprints, detailed specifications or publicly available information". Aggregation is protocol-dense, and it is sometimes assumed that implementing a published communications profile lands here automatically. Both elements of (g) must be present: reproduction of a commercial product or process, and by physical examination or from plans, specifications or publicly available information. A published specification or an open-source reference implementation is not by itself a commercial product or process. Rebuilding a competitor's commercial aggregation product from its public documentation is a different fact pattern from writing an interface to a published profile.

Where the excluded work can still count: An activity that cannot be core may still be a supporting R&D activity, but s 355-30(2) applies a higher bar to exactly this kind of work: where an activity (a) is an activity referred to in s 355-25(2), or (b) produces goods or services, or (c) is directly related to producing goods or services, it is a supporting R&D activity only if it is undertaken for the dominant purpose of supporting core R&D activities. Each limb is tested against the particular activity, never against the platform or the business as a whole: a VPP delivering dispatched energy into a market does not thereby make every activity within it one that produces goods or services. Where compliance or market-registration work is of a kind referred to in s 355-25(2), limb (a) applies. Where device installation or delivery of a dispatched response produces, or is directly related to producing, goods or services, limbs (b) or (c) may apply.

A Worked Example (Hypothetical and Illustrative Only)

Invented to show where the boundary falls. It is not a real project and says nothing about whether any actual claim would be accepted.

An Adelaide aggregator operates 2,400 residential devices: 62% home batteries across four vendor brands, 28% resistive hot water controllers behind a third-party cloud, 10% pool pump controllers. It wants to offer a fast aggregate reduction product.

Baseline & target: On the existing platform a broadcast dispatch reached devices with a median end-to-end latency of 4.2 s and a p95 of 22 s, and device state arrived on a five-minute schedule. The target recorded in advance: an aggregate reduction of at least 2.0 MW within 6 s of the dispatch instruction, held within ±5% for 5 minutes, verified from 2-second telemetry at 40 instrumented reference sites plus interval meters, with p95 actuation latency at or under 4 s.

Held and varied: Held: the device population and vendor mix, the 17:00–19:00 weekday window, summer conditions, the 2.0 MW target and the measurement method. Varied: the control architecture, the telemetry cadence requested from each vendor, and the method used to estimate headroom at dispatch. Eleven instrumented dispatch events.

Strategy A — simultaneous cloud broadcast (Failed): Reached a p95 of 19 s due to request bursts from 2,400 devices causing rate limits on two third-party clouds (31% arrived >30 s late). Quadrupling dispatcher capacity only shifted p95 to 17 s. What it ruled out: no architecture requiring a per-event command to traverse a third-party cloud for every device can meet a 6-second aggregate target on this fleet.

Strategy B — staggered commands: Staggered over 20 s to avoid rate limits. Delivered only 1.35 MW against 2.0 MW because five-minute telemetry overstated battery headroom by ~28% during rapid evening ramp. Located an independent shortfall in state estimation.

Strategy C — pre-armed local triggers: Removed latency for supporting devices, but only the battery segment (62% of fleet) exposed a pre-arm primitive.

Strategy D — combined approach: Pre-armed triggers on the battery subset sized with 30-second telemetry availability models, with cloud-commanded units carrying only the sustained tail. Delivered median 2.6 s to 90% of head response, and 2.08 MW at 6 s on 9 of 11 runs (±5% hold achieved on 8 runs). The full target was therefore not demonstrated consistently across all eleven events.

Result and boundary: The knowledge produced was as much the bound as the result: the results indicated that the achievable head response was constrained by the pre-armable fraction of the population under the architecture tested, with availability estimation remaining a source of uncertainty. For this example, the candidate experimental activity is documented from the formulation of the hypothesis and experimental approach through to the instrumented trials, evaluation and recorded conclusion. Outside it: onboarding devices, participant recruitment, market registration and commercial operation.

What Is Generally Unlikely to Be Core on Those Facts

Activity

Why

Configuring a vendor aggregation platform to its documented control and dispatch modes

Applying a documented product as designed

Recruiting participants, designing the incentive or tariff, surveying comfort limits

Market research, testing or development — paragraph (a)

Market registration and dispatch conformance testing to the applicable rules

Activity associated with complying with requirements or standards — paragraph (f)

Scheduled baseline and settlement verification

Routine testing and analysis under paragraph (f)(iii), where the facts support it

Scaling dispatcher infrastructure to a documented throughput figure

Known solution, effect well understood

Where an RSP Fits

An RSP is a scientific or technical service provider registered in specific fields that a company can engage to conduct R&D activities on its behalf (business.gov.au). On an aggregation programme, that work may sit upstream of the first dispatch event: framing the unknown as something a trial can settle, specifying the instrumentation and sampling resolution the measure requires, and separating the trial sequence from the commercial dispatch running on the same fleet, so the experimental record exists while the work happens (record keeping).

There is also a threshold point for smaller programmes: qualifying expenditure incurred to a non-associate RSP may still be taken into account in determining R&D tax offset entitlement where total notional deductions are below the usual $20,000 threshold, provided the services are within a research field for which the RSP is registered, and using an RSP does not guarantee eligibility — you still self-assess. Offset rates and the two tiers are covered in our article on the refundable and non-refundable offset; see also claiming R&D under $20,000, R&D for renewable energy and R&D Tax Incentive in Adelaide.

Talk to Ignition Research before the first instrumented dispatch event, while the trial sequence can still be separated from commercial operation of the same fleet. As a Registered Research Service Provider at Lot Fourteen in Adelaide, we design and conduct the experimental programme and produce the technical record while the work is happening. We are not a registered tax agent: your company self-assesses and remains responsible for its own claim. Get in touch.

Frequently Asked Questions

Q: Is building a virtual power plant eligible for the R&D Tax Incentive?
A: The platform as a whole is not the unit of assessment — eligibility is assessed activity by activity. Onboarding devices, configuring documented dispatch modes and standing up dashboards are generally unlikely to be core R&D activities on those facts, subject to the activity's own facts and the statutory tests. A core activity may exist in the narrower case where it is unknown whether a control and communications approach can deliver a required aggregate response inside the fleet's latency, telemetry and heterogeneity limits, and only a systematic progression of instrumented trials can determine it. You self-assess.

Q: Is market registration or dispatch conformance testing a core R&D activity?
A: Generally not. Section 355-25(2)(f) excludes activities associated with complying with statutory requirements or standards from being core R&D activities, including routine testing and analysis. That does not turn on whether the result is predictable — a conformance test can be failed and the activity is still one associated with complying. Such an activity may still qualify as a supporting R&D activity where it is directly related to a core R&D activity and, because s 355-30(2) applies, is undertaken for the dominant purpose of supporting that core activity.

Q: Does implementing a published aggregation or communications protocol count as R&D?
A: Writing an interface to a published profile using established methods, where the expected behaviour is documented, is generally unlikely to be a core R&D activity on those facts, subject to the activity's own facts and the statutory tests. Paragraph 355-25(2)(g) is narrower than it is often assumed to be: it requires reproduction of a commercial product or process, and by physical examination or from plans, specifications or publicly available information. A published specification or an open-source reference implementation is not by itself a commercial product or process.

Q: Can work on dispatch latency be claimed as R&D?
A: It depends on the activity, not the label. Provisioning more capacity to reach a documented throughput figure is a known solution with a well-understood effect. Determining whether any control and communications architecture can move a heterogeneous fleet within a specified number of seconds — where vendor documentation cannot answer it because the published figures were not measured under simultaneous load, and the answer comes from instrumented trials against a hypothesis recorded in advance — may be a core R&D activity. Installation and commercial dispatch are assessed separately; if an activity is directly related to a core R&D activity and s 355-30(2) applies, the dominant-purpose test must also be satisfied.

Sources & Further Reading

This article is general information from a Registered Research Service Provider about the R&D Tax Incentive. It is not tax, legal or financial advice; eligibility depends on your circumstances and you should self-assess and seek your own advice.

Joy Fang
Written byJoy FangFounder, Ignition Research

Joy Fang is the Founder of Ignition Research, helping Australian businesses solve uncertainty through structured, well-documented R&D.

View LinkedIn profile

If you're weighing up an AI, software or technical improvement project and can't tell yet whether it's implementation or research, start with a quick read on where it sits.

Check your project readinessDiscuss your project with IR