Quick answer: Deploying established BIM coordination, automated clash detection, 4D sequencing and project-controls functionality using commercially available tools is generally implementation where the technical outcome can be determined in advance. What may qualify is narrower: activities 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 conducted to generate new knowledge, such as automated clash resolution under coupled constraints. Technical uncertainty alone is not sufficient — the s 355-25(2) exclusions for internal-administration software, management studies and efficiency surveys can still prevent core-R&D 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.
The recurring fact pattern in construction digitisation is a federated BIM model, a coordination cadence, automated clash detection between services, structure and architecture, 4D linkage of model objects to the programme, and machine-learning dashboards forecasting schedule risk, productivity and cost-to-complete.
The R&D Tax Incentive does not ask whether that programme was innovative for your company; it asks activity by activity whether the outcome was unknown in advance, resolvable only by a systematic progression of work, and pursued to generate new knowledge (business.gov.au). On that test, many routine construction-digitisation activities may be implementation rather than core R&D. This article covers BIM coordination and project controls only; the sector view sits on the property and construction page, and take-offs and estimating are a separate Insight.
Deployment Is Not Discovery
Almost everything in a digitisation roadmap is the purchase, configuration and rollout of commercial products: model authoring, federation, clash rule sets, tolerance settings, issue-tracking workflows, reporting-layer dashboards, integrations between model, programme and cost system. The vendor already sells the outcome; what is uncertain is effort, adoption and data quality, not whether the technical result is attainable.
Two arguments recur and neither is a technical unknown. "Nobody in Australia has done it this way" is a commercial position; the statutory question is whether the outcome could be determined from current knowledge, information or experience, including knowledge published overseas and embedded in commercially available tools. "The integration was brutal" describes delivery risk.
Automated clash detection is the clearest case: geometric interference checking between federated models is a well-established capability available in commercial BIM software. Where a competent professional can determine in advance that the configured process will perform the required interference checking, the activity is generally implementation rather than core R&D.
The Exclusions That Catch Project-Controls Software
Subsection 355-25(2) of the ITAA 1997 lists categories that cannot be core R&D activities at all, whatever the level of uncertainty. These are the ones that land on digitisation programmes:
Software for the dominant purpose of internal administration
The subsection excludes developing, modifying or customising computer software for the dominant purpose of use by the entity for which it is developed, an entity connected with it, or an affiliate, for their internal administration (including the internal administration of business functions).
Project-controls software used predominantly to manage the developer's or relevant connected entity's own delivery will often present an internal-administration issue. The hinge is why the software was built and how it is dominantly used, not how clever it is. A general intention to license the software in future, without supporting evidence of that purpose, may carry limited weight in assessing its dominant purpose.
The group test is wide: building the tool in the parent while using it on projects run by connected entities or affiliates does not step outside the exclusion, because those entities are named in the provision. But "connected with" and "affiliate" are defined terms with their own tests, and an SPV or JV partner is not automatically either one.
Management studies, efficiency surveys, and market testing
These are also excluded from being core activities, and the first two catch a surprising share of construction "innovation": productivity benchmarking across sites, time-and-motion observation of trades, lean process reviews, waste and rework studies, and the "what does our data tell us about how we build" programmes that sit alongside the BIM team. Testing operations against your own baseline is measurement of practice, not new technical knowledge. Market research, market testing and market development are excluded too, which catches piloting a tool with clients to gauge appetite.
Where a Core Activity Can Genuinely Survive
Needing a new algorithmic approach can be evidence that the outcome was unknown; it is not the requirement. Both limbs have to hold. The outcome must not have been known or determinable in advance on the basis of current knowledge, information or experience, and must have been determinable only 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 the activity must have been conducted for the purpose of generating new knowledge.
The established-science words do real work on this subject matter. A coordination team can run a disciplined try-measure-adjust loop on solver settings, tolerances and model inputs and still fail the test, because the progression has to rest on principles of established science — computational geometry, constraint optimisation, statistical inference — rather than on iterative tuning guided by site experience.
Often closer to core R&D
Usually not core R&D
Automated clash resolution — rerouting solutions simultaneously satisfying coupled constraints (clearance, access, gradient, penetration limits, buildability) where achievable solution quality and convergence were unknown
Automated clash detection — geometric interference checking against configured tolerances and rule sets
Schedule optimisation under resource, space and logistics constraints where no reliable predictive basis existed and the achievable trade-off had to be established experimentally
4D sequencing — linking model objects to programme activities and animating the result
Establishing whether a defined forecasting accuracy is attainable where no reliable predictive basis exists, if not caught by an exclusion
Building a delay-risk dashboard on your own project history using standard modelling techniques
Novel model-interrogation or semantic-enrichment methods where achievable accuracy on real, messy federated models was unknown
Model auditing, naming-convention enforcement and data-quality scripting
Two guardrails: Using machine learning does not make an activity core R&D: a model expected to work once trained on enough data is a build. And the exclusions apply on top — a genuinely uncertain scheduling algorithm can still be excluded if the software containing it was developed for the dominant purpose of the entity's own internal administration.
A Hypothetical Worked Example
Illustrative and hypothetical only. Nothing here states or implies that these activities would be eligible or that a claim would be accepted.
A head contractor coordinating a hospital plantroom on a congested level wants to know whether a constraint solver can generate compliant rerouting sets. Manual coordination on a comparable plantroom took three coordinators nine weeks across roughly 1,400 flagged interferences.
The unknown, stated before the work: Whether any solver configuration can satisfy the full coupled constraint set for a majority of flagged interferences on real federated models within a usable compute budget. Available approaches addressed single-service routing, not simultaneous satisfaction of this constraint set at this model density.
Illustrative evaluation design: 300 mm maintenance clearance to valve assemblies and access panels; minimum 1:100 fall on gravity drainage; no new penetrations through transfer beams; two additional bends maximum per hydraulic run; a duct velocity ceiling; three real federated models frozen as the test set. Varied: solve strategy, whether clearance is a hard bound or a penalty term, and compute budget. Measure fixed in advance: all hard constraints satisfied for at least 80% of flagged interferences within 30 minutes of compute; below 50%, the approach is abandoned.
Trial 1 — per-clash sequential resolution: 34% satisfied, and roughly 60% of the resolutions introduced new interferences downstream. Below the abandonment threshold. Ruled out independent per-clash resolution and established that coupling between runs, not per-run geometry, was the binding difficulty.
Trial 2 — joint solve, all constraints hard: No feasible solution on any of the three models within six hours. A different failure from Trial 1: the constraint set as posed was over-constrained rather than merely expensive to solve, which is why the next trial changed the formulation, not the compute budget.
Trial 3 — staged solve: Gravity drainage fixed first as a skeleton, pressurised services and ducts solved jointly against it, clearance relaxed from a hard bound to a weighted penalty. 71% satisfied in 22 minutes.
Result: The 80% target was not met; the achievable rate was established at roughly 70%, with the reasons for the ceiling identified. On these illustrative facts, that result provides a reasonable point at which the experimental investigation is treated as having reached its recorded conclusion.
Where the boundary falls: The three trial cycles, the design of the measure and the evaluation of each result sit on one side; cleaning models beyond what the trials required, building the interface, rolling out and retraining coordinators sit on the other. On these hypothetical facts, only a narrow subset warrants further eligibility analysis; expenditure treatment and claim preparation remain matters for the company and its tax adviser. Our what does not qualify page applies the same logic across activity types.
Supporting Activities, and Where the Line Runs
Under s 355-30, activities that are not core may qualify as supporting R&D activities where they are directly related to core R&D activities — and where they are of a kind excluded from being core, produce goods or services, or are directly related to producing goods or services, only where they are conducted for the dominant purpose of supporting a core activity (business.gov.au).
The operational distinction is between preparation uniquely required to construct experimental inputs — freezing the test set, generating deliberately degraded model variants to test solver robustness, encoding the constraint matrix in machine-readable form — and the model cleaning, naming enforcement, coordination and deliverable production that would have happened anyway. Where the activity would have been undertaken for ordinary client delivery irrespective of the experimental work, that fact may indicate that its dominant purpose was commercial delivery rather than supporting the core R&D activity.
Hours are rarely clean either, because the same BIM engineers move between experiment and project weekly. That is an allocation to be recorded contemporaneously, not a mixed cost centre included wholesale.
Records That May Support the Assessment
Construction generates enormous documentation and very little of it is R&D evidence, because it is written for delivery and contract administration. AusIndustry sets out the contemporaneous baseline in records to show eligibility.
• Dated federated-model snapshots with revision identifiers, retained versions of experimental inputs rather than relying only on the live model;
• Clash rule sets and tolerance settings exported or otherwise recorded for each trial;
• Versioned constraint matrices;
• Solver configurations, parameter sets and seeds sufficient to reproduce computational runs;
• Rejected routing outputs or other unsuccessful approaches, where retained, to demonstrate the experimental progression and conclusions reached;
• Convergence and runtime logs; baseline comparisons;
• Time records or other project records that help distinguish experimental activities from routine coordination or delivery work.
A practical record-keeping risk arises where the federated model is continually overwritten as part of normal delivery, making it difficult to reconstruct the inputs used in earlier experimental trials. When the federated model is a rolling delivery artefact, the inputs to Trial 1 no longer exist by the time anyone looks.
Where an RSP Fits
A Research Service Provider is a scientific or technical service provider, registered in specific fields, that you can engage to conduct R&D activities on your behalf (business.gov.au). AusIndustry's software development sector guide and AI sub-guide are the starting points for the technical framing.
For a builder or developer, 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 document the technical question, hypothesis and evaluation approach as the work progresses.
There is also a threshold point for smaller entities. R&D expenditure for the income year must generally be at least $20,000, 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 (ATO) — where notional deductions fall below that figure, s 355-100(2) of the ITAA 1997 substitutes a base generally limited to qualifying expenditure incurred to a non-associate RSP for services in a registered field, together with eligible CRC Program contributions. 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.
Offset rates, the refundable and non-refundable tiers and the intensity premium are covered separately in refundable vs non-refundable offset.
Frequently Asked Questions
Q: Is BIM coordination eligible for the R&D Tax Incentive?
A: BIM coordination is not automatically a core R&D activity. Routine federation, clash checking and coordination workflows using established commercial functionality are unlikely to qualify where their technical outcomes can be determined in advance. Distinct technical activities within a BIM programme may still potentially qualify where they independently satisfy all of the core R&D requirements and exclusions.
Q: Is automated clash detection an eligible R&D activity?
A: Clash detection is geometric interference checking against configured tolerances — a solved, commercially available function, so running it is implementation. Automated clash resolution, where solutions must satisfy coupled clearance, access, structural and buildability constraints and the achievable solution quality was unknown, is the part more likely to contain a core activity.
Q: Is 4D scheduling or schedule optimisation R&D?
A: Linking model objects to programme activities and animating the sequence is data and configuration work. Schedule optimisation may qualify where no reliable predictive basis existed for the constraint set and the achievable trade-off had to be established by systematic experiment against a measure fixed in advance — subject to the s 355-25(2) exclusions. You self-assess.
Q: Does the internal-administration exclusion apply to construction project-controls software?
A: It may. Section 355-25(2) excludes certain software development activities from being core R&D activities where the dominant purpose is use by the developer, a connected entity or an affiliate for internal administration. Project-controls, forecasting and reporting software developed predominantly to administer the entity’s own business functions may therefore raise this exclusion. The outcome depends on the facts, including whether the software is being developed as an internal management tool or as part of an experimental effort to create new or improved commercial capabilities.
Sources & Further Reading
legislation.gov.au — Income Tax Assessment Act 1997 — Div 355, incl. ss 355-25, 355-30 and 355-100
Related: R&D for property and construction · what does not qualify · what an RSP is · claiming R&D under $20,000 · refundable vs non-refundable offset · more Insights
Talk to Ignition Research if you are planning BIM, project-controls or construction-digitisation work and need technical R&D support. As a Registered Research Service Provider at Lot Fourteen in Adelaide, we assist builders and developers 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 registered tax agent. 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.