Quick answer: Installing sensors, integrating a building management system and setting alarm thresholds is generally not a core R&D activity. A bounded experiment — whether a fault can be predicted from sparse failure data — may be a core activity only where every element of the core test in s 355-25 is met. Instrumentation fitted to generate experimental data may qualify as a supporting R&D activity where it is directly related to a core R&D activity and, where the additional test in s 355-30(2) applies, is conducted for the dominant purpose of supporting that core activity. Efficiency surveys and internal-administration software are named exclusions that may prevent core treatment. You self-assess.
7 August 2026 — this article describes the current rules. The 2026–27 Federal Budget announced proposed R&DTI reforms for income years starting on or after 1 July 2028. Until any amendments take effect, the R&DTI continues to be administered under the current legislation.
A smart-building programme usually arrives as one budget line: a mesh of IoT sensors across HVAC, lifts, metering, water and air quality; a modern building management system with an open protocol layer over the legacy controllers; a dashboard; and an analytics tier intended to predict faults before they happen. The R&DTI does not look at the budget line. It looks at activities, one at a time.
Sensors, gateways, protocol bridges, historian databases, dashboards, rule-based alarms and threshold tuning are typically work whose outcome could be known or determined in advance on the basis of current knowledge, information or experience — but that is assessed activity by activity against s 355-25, and you self-assess it; it does not follow automatically from the technology involved. Where the unknown is cost, schedule and integration pain rather than whether the result is attainable at all, it sits on the business-risk side of the line. Work that is not a core activity in its own right may still be a supporting activity — see below.
What the Core Test Asks of a Smart-Building Programme
A core R&D activity is an experimental activity whose outcome could not be known or determined in advance on the basis of current knowledge, information or experience, and could only be determined by applying a systematic progression of work that is based on principles of established science and proceeds from hypothesis to experiment, observation and evaluation and leads to logical conclusions, and which is conducted for the purpose of generating new knowledge (business.gov.au). Both limbs have to hold.
The established-science qualifier does real work in this field. A disciplined measure-and-iterate loop over building telemetry is not enough on its own: an anomaly-detection or control experiment has to rest on the established science of how the plant behaves and degrades — the failure physics of the asset, the thermodynamics of the zone, the signal characteristics of the instrument — rather than on trying model configurations until one of them scores well.
Three questions do most of the work when that test meets a building programme:
Was the achievable performance unknown, or only the effort? "We did not know how long the BACnet integration would take" is effort. "We could not determine, from existing knowledge, whether a useful fault-prediction signal was recoverable at all from this data" describes a candidate unknown.
Was there a testable hypothesis and an appropriate evaluation approach? The records should show how the experiment was designed to test the hypothesis and how the results were observed and evaluated.
Was the work genuinely directed at resolving the technical hypothesis, rather than merely implementing a predetermined system? The commercial decision to proceed with deployment does not by itself determine the R&DTI treatment of the experimental activity.
These tests apply to an activity, not to a project, a product or a department. A smart-building programme may contain one or more narrowly defined candidate R&D activities alongside a larger body of routine engineering and deployment work.
Two Exclusions That Shape Most Smart-Building Programmes
Subsection 355-25(2) of the ITAA 1997 lists categories of activity that cannot be core R&D activities at all, however difficult they were. Two of them sit directly over this space.
Management studies or efficiency surveys
"We optimised our energy use", "we benchmarked plant performance across the portfolio", "we surveyed our buildings and reduced consumption by X per cent" — each of those raises the excluded "management studies or efficiency surveys" category, and AusIndustry's eligibility guidance uses the energy efficiency of a business as an illustration of it (business.gov.au). Whether a given activity falls inside the exclusion turns on its substance, so a portfolio measurement exercise raises the exclusion and would require analysis of what the activity actually consisted of. Our Insight on process-heat electrification works through how an energy audit differs from a hypothesis-driven trial — find it in Insights or via R&D for renewable energy.
Internal-administration software
The same subsection excludes activities related to developing, modifying or customising computer software for the dominant purpose of the internal administration of business functions of the developer, an entity connected with it, or an affiliate of it. Australia has no internal-use-software four-part test; the dominant-purpose exclusion is the rule.
It matters here because a large share of smart-building software is built to run the owner's or manager's own operations: facilities management, work-order dispatch, compliance reporting, asset registers, tenant billing. Software of that description raises the exclusion, and resolving it requires analysis of the software activity's dominant purpose and of the connected-entity and affiliate tests — not a conclusion drawn from the fact that the platform is technically demanding or may be sold externally one day. We cover that analysis separately in Insights and in what does not qualify.
A third category matters for infrastructure owners: activities undertaken to demonstrate or satisfy compliance with a statutory requirement or standard may also be excluded from being core R&D activities. This may include commissioning, testing, logging or reporting where those activities are required under legislation or by a regulator acting under legislation.
Where a Core R&D Activity Can Genuinely Sit
Across buildings and infrastructure assets the pattern is consistent: the candidate unknown is the achievable predictive or control performance, not the feasibility of building the system.
Often closer to core R&D
Usually implementation, not core R&D
Establishing whether a fault can be predicted at all with a useful lead time from sparse failure data — where an asset class fails rarely and the achievable precision/recall trade-off cannot be predicted from existing knowledge
Rule-based alarms, threshold and deadband tuning, or applying a vendor's analytics module to your plant
A control strategy that must satisfy competing comfort and energy objectives simultaneously across coupled zones, where no reliable predictive basis exists for the achievable trade-off
Implementing published control sequences, scheduling, optimum start/stop or standard PID loop tuning
Sensor fusion where each individual signal is unreliable, sparse or drifting, and whether a dependable inferred state is recoverable from the combination is unknown
Adding more sensors, calibrating instruments, or filtering with established methods
Transferability experiments: whether a model that holds on one asset class or plant type can be made to hold on another whose behaviour differs materially
Retraining or recalibrating an existing model on new data
Establishing whether a required inference can run within a hard constraint — edge power, bandwidth or latency budget — where the achievable envelope is unknown
Deploying an existing model to an edge gateway that is known to be adequate
Two things that left column does not mean:
Using machine learning does not make an activity R&D: A model that is expected to work once it has enough data is a build. The statutory question is whether the outcome could be known or determined in advance and whether the work was designed to find out. AusIndustry publishes a software development sector guide and an AI-related activities sub-guide worth reading before registration; R&D for software and AI covers the same ground for a general software programme.
Portfolio size on its own is delivery scale, not uncertainty: Rolling the same solution to a thousand buildings is deployment. Heterogeneity across those buildings is a different matter: where plant types, occupancy patterns or control topologies differ materially, domain shift or coupled-system behaviour may create a separately defined technical unknown — but it has to be defined and tested as its own activity, not asserted as a property of the portfolio.
Where the Sensor Network Fits: Supporting Activities
Instrumentation is not wasted for R&DTI purposes just because it is not core. Activities that are not core may qualify as supporting R&D activities where they are directly related to core R&D activities. Under s 355-30, an extra hurdle applies where the activity is of a kind referred to in s 355-25(2) (an excluded kind), or produces goods or services, or is directly related to producing goods or services: in those cases the activity qualifies only where it is conducted for the dominant purpose of supporting a core activity (business.gov.au). The production-related limb can be relevant in building programmes. Where an installation, commissioning or delivery activity produces, or is directly related to producing, goods or services, it must also satisfy the dominant-purpose test if it is being assessed as supporting R&D.
The practical consequence is that a sensor deployment installed to run the building and a sensor deployment specified inside an experimental design are different activities. The purpose for which instrumentation is specified and used is a factual matter that should be supported by contemporaneous records. Records created as the work progresses will generally provide stronger support than a characterisation reconstructed only at lodgement. Procurement documentation may not, by itself, explain the experimental purpose of the instrumentation.
Supporting activities also need a core activity to support. Where there is no core activity, there is nothing for them to attach to.
A Worked Example — Hypothetical
Illustrative and hypothetical only. It is not a ruling, not a representation about any client, and nothing here says the activities described would be eligible.
A property group operates 41 water-cooled chillers across 12 commercial buildings. Six years of maintenance records contain 9 confirmed compressor failures on that fleet. Existing BMS trip alarms detect a failure at or after it happens — effective lead time zero. The group wants to know whether a usable early warning exists at all.
The recorded question and measure, dated before any instrumentation was ordered: Can compressor degradation be detected with at least 14 days lead time, at no more than one false alert per chiller per quarter? Both figures were set from the group's own maintenance planning cycle, and a stated failure condition was written down: if no configuration reached 14 days lead at that alert rate, the answer to the question is no.
Design: 8 chillers of one model family were designated trial assets and instrumented at high rate — tri-axial vibration on the compressor housing, per-phase current, and suction and discharge temperature and pressure. The remaining 33 stayed on standard BMS points at 15-minute intervals and served as the comparison population.
Trial 1 — failed, and the failure was informative: A supervised classifier trained on the 9 historical failure events using only the existing 15-minute BMS points could not separate failure precursors from ordinary load and weather variation. That ruled out the cheapest hypothesis — that the existing point set and sampling interval already carried the signal — and fixed sampling rate as a variable that had to change.
Trial 2 — partial: Unsupervised anomaly detection on high-rate vibration from the trial assets, against a six-week normal-behaviour baseline, flagged 2 of the 3 degradation events observed on those units during the period, at 19 and 11 days lead. Lead time on one event fell short of the target, and the alert rate ran above it.
Trial 3 — inconclusive at year end: Fusing current signature with vibration reduced alerts, but the trial period contained too few degradation events to establish the alert rate against the stated measure. The question remained open and a second cooling season was scheduled.
Where the boundaries fall on these assumed facts: For this illustrative example, the candidate experimental activity is documented from the point at which the technical hypothesis and experimental approach are established through to the trials, evaluation and recorded conclusion for the income year. The 8 trial assets carry experimental asset IDs; the 33 others are operational. High-rate instrumentation fitted to the 8 trial units was specified in the experimental design; identical sensors fitted to the rest of the fleet under the standard rollout are operations. Three engineers booked hours to an experiment time code only against the written trial protocol; rollout hours went to a separate code, and one data engineer working across both split time at task level in the timesheet, weekly. Separately, the portfolio energy-benchmarking exercise raises the efficiency-survey exclusion, and the work-order module built to run the group's own facilities function raises the internal-administration exclusion; both would require analysis of the activity's substance and dominant purpose.
On these assumed facts, only a bounded subset of the programme would warrant assessment as candidate core or supporting activities; eligibility and expenditure treatment remain matters for self-assessment and tax advice.
Records That May Support the Activity Assessment
Building-technology programmes generate commissioning reports, as-built documentation and vendor sign-offs. Those records can corroborate configuration, timing, observations and activity boundaries, but they are not sufficient on their own, because they describe what was delivered rather than what was unknown. AusIndustry expects contemporaneous records showing the activities were conducted and were eligible (business.gov.au).
What a structured programme in this discipline actually leaves behind:
• An activity map naming each activity, its start and end trigger, and the assets in scope — with experimental asset IDs listed explicitly, so an analytics run can be traced to the units it was performed on.
• Contemporaneous records of the technical unknown and prior-knowledge assessment, including relevant vendor documentation, literature, expert input or other sources considered. The question is whether a competent professional could have known or determined the outcome from knowledge, information or experience that was publicly available or reasonably accessible worldwide at the time.
• A versioned baseline and change log — model version, feature set, control sequence and threshold configuration, each change timestamped so it can be read against the observation that prompted it. Where a control strategy is being tested on live plant, the BMS change record is the experimental log.
• Separated data collection. Operational telemetry and experiment telemetry come off the same buildings; if they land in the same store with no flag, no one can later say which data the experiment used.
• Time booked as it is worked, with an apportionment basis written at the time for anyone splitting experimental and rollout hours.
A practical record-keeping risk is failing to distinguish the experimental period and activities from the surrounding rollout, integration and commissioning work. It is that the experiment's start and end were never fixed, so a year of rollout, integration and commissioning ends up described as one continuous activity — and nothing in the record can separate the part that was trying to find something out.
Where an RSP Fits
business.gov.au describes Research Service Providers as scientific or technical service providers you can engage to conduct R&D activities on your behalf, registered in specific fields of research (business.gov.au).
For a building-technology programme an RSP may assist with experimental design, technical R&D work and contemporaneous supporting records within the research fields for which it is registered. Earlier involvement can help ensure that the technical question, hypothesis, instrumentation and evaluation approach are documented as the work progresses.
There is also a threshold point for smaller entities. Notional R&D deductions for an income year must generally be at least $20,000 for the offset to be available — the lower bound in s 355-100(1) of the ITAA 1997 (ATO) — and qualifying expenditure incurred to a non-associate RSP may still form part of the offset where total notional deductions are below the usual $20,000 threshold. Where total notional deductions fall below $20,000, the offset base is generally limited to expenditure incurred to a non-associate RSP for services within a field for which it is registered, together with eligible CRC Program contributions, under the substituted base in s 355-100(2). See claiming R&D under $20,000. Using an RSP does not guarantee eligibility — you still self-assess, and an RSP supplies research capability, not tax advice.
Which offset applies to your company, and at what rate, is set out in refundable versus non-refundable offset and is a question for your registered tax agent.
Frequently Asked Questions
Q: Is installing a building management system eligible for the R&D Tax Incentive?
A: Generally not as a core R&D activity. Specifying, installing, integrating and commissioning a BMS, including protocol bridging to legacy controllers and setting alarm thresholds, will usually have an outcome that could be known or determined in advance on the basis of current knowledge, information or experience, which is what the core test in s 355-25 of the ITAA 1997 asks — assessed activity by activity, and self-assessed by you. That work may still qualify as a supporting R&D activity under s 355-30 where it is directly related to a core R&D activity and, where the dominant-purpose limb is triggered — an activity of an excluded kind under s 355-25(2), one that produces goods or services, or one directly related to producing goods or services — it is conducted for the dominant purpose of supporting that core activity.
Q: Is predictive maintenance software eligible R&D?
A: It may be, subject to self-assessment against all of the statutory requirements and exclusions, where you could not know in advance whether a useful fault-prediction signal was recoverable — for example from sparse failure data on a rarely failing asset class — and the activity addressed that unknown through the required systematic progression of work, supported by an appropriate documented evaluation approach.
Q: Is optimising our building's energy use an excluded efficiency survey?
A: Measuring and benchmarking your own operations to find savings raises the "management studies or efficiency surveys" category excluded from being a core R&D activity by s 355-25(2) of the ITAA 1997, and would require analysis of what the activity substantively consisted of. A hypothesis-driven experiment on a control strategy whose achievable comfort-versus-energy trade-off could not be predicted is a different activity, assessed on its own facts.
Q: Can a facilities-management platform we built for ourselves be claimed?
A: Software developed, modified or customised for the dominant purpose of the internal administration of business functions of your company, an entity connected with it or an affiliate raises the exclusion in s 355-25(2) of the ITAA 1997 from being a core R&D activity. Australia has no internal-use-software four-part test; the dominant-purpose exclusion is the rule, and applying it requires analysis of the software activity's substance and purpose on your facts.
Sources & Further Reading
legislation.gov.au — Income Tax Assessment Act 1997 — Div 355, incl. ss 355-25 and 355-30
Related: what does not qualify · refundable vs non-refundable offset · R&D for property and construction · R&D for software and AI · R&D for renewable energy · what an RSP is · claiming R&D under $20,000
Talk to Ignition Research if you are planning smart-building, predictive-maintenance or building-controls experimental work and need technical R&D support. As a Registered Research Service Provider based at Lot Fourteen in Adelaide, we assist property groups, infrastructure owners and building-technology companies with experimental design, technical R&D work and contemporaneous supporting records within our registered RSP scope. We do not determine R&DTI eligibility or provide tax advice: your company self-assesses and remains responsible for its own claim, with tax advice and lodgement handled by your tax adviser. Get in touch.
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.
Thinking about a project like this?
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.