R&D Tax Incentive for climate and energy software

The R&D Tax Incentive for climate and energy software companies

Climate and energy software companies can claim forecasting, control, optimisation and measurement methods where a competent engineer or data scientist could not predict whether the method would hit a stated accuracy or performance target on real assets. The deciding test is genuine uncertainty: tuning vendor settings, reporting to prescribed methods and standard integrations do not qualify.

Reviewed by George WalchFacts last verified 31 October 2026

Where the R&D usually sits

The genuine unknowns in climate and energy software usually involve physical systems behaving in ways a model has not captured: whether a forecast can hold a stated error at short horizons under cloud or wind ramps; whether a control method can dispatch thousands of small batteries to a network constraint without breaching customer comfort or degrading cells faster; whether a grid model reproduces measured fault or harmonic behaviour; whether a remote sensing method estimates emissions or carbon stocks within a stated error against direct measurement.

What usually qualifies

Climate and energy software activities and how they usually fare
Fact	Usually	Why
Developing a short-horizon solar or wind forecasting method that must beat a stated error threshold where published methods fall short for the site type	Likely core	Achievable accuracy is unknown until candidate methods are tested
Testing a control method that coordinates distributed batteries or loads against network, comfort and degradation targets at once	Likely core	Behaviour of the combined system cannot be predicted from vendor documentation
Building data pipelines, simulation environments and hardware-in-the-loop rigs for those experiments	Supporting	Directly enables the core experiment
Adjusting a vendor's dispatch or inverter settings for a particular site	No	Not core; the relationship between settings and outcomes is already established. Setting up a trial site for a core experiment can be supporting
Building market bidding, metering or emissions reports to methods the rules prescribe	No	Not core; compliance or routine development with a known outcome
Integrating with retailer, meter data or inverter APIs as documented	No	Not core; routine integration, though an integration built only to run a core trial can support it

Coordinating home batteries under a network limit

This is an illustrative company, not a client. A Brisbane software business aggregates customers' home batteries into a virtual power plant. Core activity 1 tests whether a dispatch method can keep a feeder's export under a dynamic limit while keeping each battery's cycle count under a stated annual figure and meeting a market response target, a combination its search of published work and vendor documentation did not settle. Core activity 2 tests whether a five-minute load forecast for each home can reach a stated error with only smart meter data. The simulation environment, data pipeline and trial enrolment tooling are supporting activities. Onboarding new inverter brands through documented APIs, the customer app and market compliance reporting are not R&D.

The evidence you already have

Energy software teams hold strong time-series evidence: forecast backtests with error metrics by horizon, control experiment logs with interval data from participating sites, telemetry from batteries and inverters, simulation runs, and the code history behind each version. The Energy guide also names grid modelling studies, failure analyses and SCADA records. Keep the target each experiment was meant to reach, the sites in and out of each trial, and the analysis that decided the next iteration.

Watch outs

The Energy guide's risk areas apply directly. Site-specific tuning and incremental adjustment of settings are unlikely to qualify. Testing that a commercial product performs as its documentation says is predictable. Work to meet market rules or reporting obligations is compliance. Software for the company's own billing, settlement or reporting is excluded internal administration. Experiments on customers' assets need clear control and ownership of results, and grants for the same work can trigger a clawback.

AusIndustry's Energy sector guide is written mostly for hardware companies, but its warnings carry straight over to software. It names off-the-shelf product testing, site-specific adaptation and routine performance testing as risk areas, and those are exactly where climate and energy software claims go wrong. This page applies that guidance, together with the software guide, to forecasting, control, grid modelling and emissions measurement businesses.

What the Energy guide says, read for software

Settings are not experiments. The guide says incremental adjustment of operating settings is unlikely to qualify where the manufacturer has established the relationship between settings and outcomes. For software, that covers configuring a vendor's battery dispatch modes, inverter limits or building management schedules for a site.
Known performance is not unknown. Testing a commercial product to confirm it meets its specification in local conditions is unlikely to be core, because performance is often known from the manufacturer's documentation. The guide's electrolyser example failed for this reason.
Routine performance testing. The guide lists solar output verification, wind turbine power-curve testing at commissioning, emissions testing for compliance, and battery capacity, cycle-life and round-trip efficiency testing. Software that automates these tests is routine development.
What does qualify. The guide's battery interlayer example qualified because experts confirmed the effect could not be predicted, and the company ran experiments to find out. Software claims need the same shape: a measurable target, a reason the outcome was unknown, and a test.

AusIndustry's machine learning case study, on irrigation decision support rather than energy, is a useful model. The core activity was the experiment testing a new way of selecting predictive variables; the literature review, data acquisition, dataset preparation and model tuning were registered as supporting activities.

Edge cases specific to energy software

Customer assets. Many experiments run on equipment the company does not own: home batteries, commercial loads, community storage. The company must control the experiment, own the results and bear the cost. A utility or network partner that funds a trial regardless of outcome, or takes the findings, weakens the claim.

Rules and reporting. Market bidding, metering, connection studies and emissions reporting built to methods the rules prescribe are compliance or routine work, so not core. Some of it can be supporting, for example registering trial sites so a core dispatch experiment can run, where that is its dominant purpose. A new measurement method, such as estimating methane or soil carbon from remote sensing to a stated error against direct sampling, is different, and its validation campaign can be core.

Own operations. An energy retailer or generator building software for its own billing, settlement or reporting is caught by the internal administration exclusion.

Grants. ARENA and other government grants for the same R&D can trigger a clawback adjustment. Whether one does, and by how much, depends on the grant's terms and the expenditure it pays for, and a grant paid whatever the results can instead raise the at-risk question under s 355-405. Map each grant to the costs it funded and settle the treatment before the claim.

How these registrations are usually split

Separate forecasting, control and measurement questions, since each needs its own hypothesis and evidence. Keep simulation environments, data pipelines and trial tooling as supporting activities under the core they serve. Forecasting and model work also follows the training ML models test, and control systems at fleet scale often share questions with distributed systems. The AI page covers model claims in general.

Rand is built for software, health and life science R&D, and in a climate or energy claim it helps with the software and data parts: forecasting, control and measurement work recorded in the tools it reads (GitHub, Jira, Linear, Notion and Xero). Site telemetry exports, trial agreements and any hardware testing are added manually.

Frequently asked questions

Is our solar or demand forecasting model eligible?

If the accuracy you need is not reached by published or commercially available methods for your data, horizon and location, and you test candidate approaches against a stated error threshold, the model work can be core. Retraining a known model on new data to an expected result is not.

We run trials on customers' home batteries. Whose R&D is it?

It can be yours if your company controls the experiment, owns the results and bears the cost. Check the customer terms and any utility partnership agreement: if a partner pays for the trial whatever the result, or owns the data and findings, the claim is weaker.

Does software for mandatory climate or emissions reporting qualify?

Building reporting to the methods the rules prescribe is routine development, and a company doing it for its own reporting can also fall within the compliance and internal administration exclusions. A genuinely new measurement method, tested against an independent reference, is a different question.

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.