Quick answer: Automating a workflow, wiring systems together or building integrations is generally standard software engineering rather than core R&D where known methods are being applied to achieve a reasonably predictable outcome. Automation may warrant assessment as a potential core R&D activity where a competent professional, with access to relevant knowledge and resources, could not know or determine the technical outcome in advance and the outcome can only be determined through a systematic progression of experimental work. “It was hard” or “it took months” does not, by itself, establish technical uncertainty.
A common question reaches us in some version of this: “We're automating our operations — connecting our systems, removing manual steps and building a workflow engine. It's serious engineering. Can we claim the R&D Tax Incentive?” It's a reasonable question, and the appropriate starting point is that routine software automation, on its own, is generally unlikely to qualify as core R&D. That isn't a comment on how valuable or difficult the work was — it's a comment on the requirements the law applies.
This article is a problem-led walk through where the line may sit for automation, integration and workflow work specifically, with concrete examples on both sides. It's general information from a Registered Research Service Provider (RSP000047), not tax advice — eligibility is self-assessed, so check your own circumstances and seek your own advice. For eligibility depth across software products, our R&D Tax Incentive for software and AI page goes further.
The Test Isn't "Was It Hard" — It's "Was the Outcome Knowable"
The R&D Tax Incentive provides a tax offset for eligible R&D activities. Core R&D activities are experimental activities whose outcome could not be known or determined in advance on the basis of current knowledge, information or experience, and which are conducted through a systematic progression of work — from hypothesis to experiment, observation, evaluation and logical conclusions — for the purpose of generating new knowledge (Income Tax Assessment Act 1997, s 355-25).
A key requirement is that the outcome could not be known or determined in advance. Much routine automation will not satisfy that test not because it's trivial, but because the outcome was knowable — a competent professional, given the same tools, could confidently say "yes, this can be built, and here is broadly how" based on reasonably accessible worldwide knowledge, information and experience. The task may still be large, fiddly, and weeks of careful work. Difficulty, scale, and effort are not technical uncertainty. The question is whether the technical outcome was genuinely in doubt, not whether the project was demanding.
That's the trap with automation in particular: it usually feels like engineering precisely because it is engineering — applying established patterns (event triggers, queues, API calls, retries, data mapping) to a defined goal. Applying a known method well is not experimenting to discover an unknown.
Where Routine Automation Sits (Usually Not R&D)
Work described as “automating the business” will often involve standard engineering applied to a known outcome. The following activities are generally unlikely to qualify as core R&D when they involve established tools and predictable outcomes:
Workflow automation — replacing manual steps with triggers, rules and scheduled jobs using established tools or platforms.
System integration — connecting a CRM, ERP, accounting and logistics systems via documented APIs so data flows between them.
Data pipelines and ETL — moving, transforming and syncing data using established methods, even at large volume.
Robotic process automation (RPA) — scripting repetitive tasks across existing applications.
Internal tooling and dashboards — building configuration, reporting or admin interfaces on top of known frameworks.
A note on the labels: "ETL", "RPA" and "API integration" are descriptions of technique, not eligibility categories — these labels do not determine eligibility; the actual activities and evidence do.
A further, specific point for automation work: developing, modifying or customising computer software for the dominant purpose of use by the developer, a connected entity or an affiliate for internal administration — including the internal administration of business functions — is specifically excluded from being a core R&D activity under section 355-25(2).
That does not automatically answer every supporting-activity question. An excluded activity would need to satisfy the additional supporting R&D activity requirements, including being directly related to an eligible core R&D activity and being conducted for the dominant purpose of supporting that activity.
This article describes the current rules. The Australian Government has announced R&DTI reforms intended to apply to income years starting on or after 1 July 2028.
Where Automation May Cross the Line
Automation may include a potential core R&D activity where the outcome of a specific technical activity could not be known or determined in advance from existing knowledge, information or experience, and can only be determined through a systematic progression of experimental work. The relevant signal is not the automation itself, but the technical unknown within it.
Ask: was there a point where a competent professional in the field, with access to relevant knowledge and resources, could not know or determine whether the technical outcome would be achieved? If yes, that specific experimental portion — not the whole project — may warrant assessment against the remaining requirements for a core R&D activity. Contemporaneous records should document the uncertainty, hypothesis, experiments, observations and results.
Routine vs Experimental: The Same Work, Two Readings
The matrix below pairs common automation work with an experimental version of the same task. The difference is not difficulty alone — it is whether the technical outcome could be known or determined in advance.
Routine automation
(usually not R&D)
Why it's routine
Experimental version
(may warrant assessment)
Why it may warrant assessment
Wiring three sales channels into the warehouse and accounting systems via documented APIs
Known pattern, known outcome — intricate, but not in doubt
Reconciling out-of-order, conflicting-timestamp events where existing methods are known to produce inconsistent state
It is genuinely unknown whether any method can hold to the required threshold
Scheduling and retrying jobs with an established queue/workflow engine
Established tooling applied to a defined goal
Devising a scheduling approach where no known technique meets a hard, competing latency-and-consistency constraint
Outcome cannot be determined from current knowledge without experiment
ETL that moves and transforms data at large volume
Volume is scale, not uncertainty
A transformation where the correctness of any known algorithm is genuinely in doubt for the data's properties
Requires hypothesis and systematic testing to resolve
Read the matrix as: routine work is applying known engineering to a known outcome; the experimental version contains a real technical unknown that could only be resolved by systematic experimentation.
Two Automations, Side by Side
Standard engineering (generally not R&D)
A distributor automates order processing: incoming orders from three sales channels are normalised, matched to inventory, and pushed to the warehouse and accounting systems via each vendor's documented API. The integration is intricate and takes four months of careful work, with plenty of edge cases. But at no point is the outcome in doubt — the team knows this can be built and broadly how. It was hard; it wasn't uncertain.
Possibly experimental (may be core R&D — self-assess)
The same distributor needs the pipeline to reconcile these feeds in real time under specified consistency and latency constraints. A review of publicly available or reasonably accessible technical knowledge does not identify an established approach capable of determining the outcome under the combination of out-of-order events and conflicting timestamps. It is genuinely unknown whether any method can meet a defined consistency and latency threshold under specified conditions. The team forms a hypothesis, designs experiments varying event-ordering strategies against a ground-truth dataset, measures consistency and latency, and concludes which approach holds — or that the first one fails.
Same domain, same team. The first is applying known engineering to a known outcome. The second contains a real technical unknown that could only be resolved by systematic experimentation. The difference isn't difficulty — it's knowability.
How Ignition Helps
A recurring pattern we see is good engineering described as R&D because it was hard, or a genuinely experimental activity buried inside a large automation project and never clearly framed as an experiment. Both situations can create difficulties at review time.
Our role in automation work is to help draw that line more clearly — separating routine engineering from activities that may warrant assessment as experimental, so the routine build is not overclaimed and a potentially relevant technical unknown is not overlooked.
As a Registered Research Service Provider, we help frame the research — the unknown, hypothesis and experiment — before the work begins, while the technical uncertainty and original reasoning are still visible. RSP registration confirms that a provider has met the applicable registration requirements for its registered research fields. It is not a government endorsement or a guarantee that any activity will be eligible.
A good place to start is our two-minute self-assessment and the software and AI page. The self-assessment provides an initial indication of whether particular activities may warrant further review; it does not determine eligibility.
Review whether your automation contains an experimental activity. We help work out whether your automation contains a genuine technical unknown, or is standard engineering done well.
Frequently Asked Questions
Q: Is workflow automation eligible for the R&D Tax Incentive?
A: Generally not on its own. Automating steps with triggers, rules and established tools to reach a known outcome is standard engineering, not experimentation. It may warrant assessment as a potential core R&D activity where the work involves a technical outcome that could not be known or determined in advance and can only be determined through a systematic progression of experimental work. The activity must still satisfy the remaining legislative requirements.
Q: Does automation count as R&D if it was really hard to build?
A: Difficulty isn't the test. "It was complex" or "it took months" describes effort, not technical uncertainty. The question is whether the technical outcome could be known in advance by a competent professional. Hard, knowable work is generally not core R&D; a genuinely unknown technical outcome may be.
Q: Is system integration eligible R&D?
A: System integration using documented APIs and established methods is generally unlikely to qualify as a core R&D activity, even where the work is intricate. A specific integration activity may warrant assessment where its technical outcome could not be known or determined in advance from existing knowledge and must be determined through systematic experimentation.
Q: Could internal operations automation ever be claimed?
A: Care is required. Developing, modifying or customising computer software for the dominant purpose of use by the developer, a connected entity or an affiliate for internal administration — including the internal administration of business functions — is specifically excluded from being a core R&D activity under section 355-25(2).
That does not automatically answer every supporting-activity question. An excluded activity would need to be directly related to an eligible core R&D activity and conducted for the dominant purpose of supporting that activity. Internal automation should therefore be assessed against the facts and purpose of the specific activities rather than treated as automatically eligible or automatically irrelevant.
Sources & Further Reading
Check if you are eligible for the R&DTI (business.gov.au) — core and supporting activities, hypothesis and systematic progression
Software development sector guide (business.gov.au) — how the eligibility test applies to software work
Income Tax Assessment Act 1997 s 355‑25 — core R&D activities and the internal-administration exclusion (Federal Register of Legislation)
Research and development tax incentive (ato.gov.au)
Related: R&D Tax Incentive for software and AI · Self-assessment · Registered Research Service Provider
Note: The Australian Government announced reforms to the R&D Tax Incentive in the 2026–27 Budget, intended to apply to income years starting on or after 1 July 2028. Until those changes take effect, the program continues to operate under the current legislation. Readers should check the latest official guidance before relying on the future measures.
This article provides general information only and does not constitute tax, legal or financial advice. Eligibility for the R&D Tax Incentive depends on the specific entity, activities, expenditure and circumstances involved. Businesses should assess their circumstances against the legislation and current official guidance and obtain independent professional advice where appropriate.
Working on a project like this?
Tell us what you're building and the part you're not sure will work. A researcher from our Adelaide team (registered Research Service Provider RSP000047) reads every enquiry and replies within two business days. No documents needed.
