Quick answer: Automating a workflow, wiring systems together, or building integrations is generally standard software engineering, not R&D — you are applying known methods to reach a known outcome. Automation may only cross into eligible experimental development where it involves a genuine technical unknown that a competent professional could not resolve from existing knowledge, tested through systematic experimentation. "It was hard" or "it took months" is not uncertainty.
A very common message reaches us in some version of this: "We're automating our operations — connecting our systems, removing manual steps, building a workflow engine. It's serious engineering. Can we claim the R&D Tax Incentive?" It's a reasonable question, and the honest starting point is that most software automation, on its own, is not core R&D. That isn't a comment on how valuable or difficult the work was — it's a comment on what the law actually tests.
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 funds core R&D activities: 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 to observation, evaluation and logical conclusions — for the purpose of generating new knowledge (Income Tax Assessment Act 1997, s 355‑25).
The load-bearing words are could not be known 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)
Most of what teams describe as "automating the business" is standard engineering applied to a known outcome. Typically not core R&D:
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: Software developed for the dominant purpose of the company's own internal business administration is specifically excluded from being a core R&D activity under s 355‑25(2). That does not automatically answer every supporting-activity question: an excluded activity would need to satisfy the separate and stricter supporting R&D activity requirements, including the relevant dominant-purpose test. Internal automation should therefore be assessed carefully rather than treated as automatically eligible—or automatically irrelevant. Supporting-activity rules are among the areas flagged in R&DTI changes proposed to commence from 1 July 2028; those are proposals only and not yet law, and this article describes the current rules.
Where Automation May Cross the Line
Automation can shade into experimental development — but only where the build forces a genuine technical unknown that established methods demonstrably can't resolve, and you have to experiment to find out whether a solution is even possible. The signal isn't the automation; it's the unknown sitting inside it.
Ask: was there a point where a competent professional in the field genuinely could not say whether this would work, or how, from existing knowledge? If yes, that specific experimental slice — not the whole project — may be core R&D, and you'd need contemporaneous records of the uncertainty, hypothesis, experiments 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 never difficulty — it's whether the technical outcome was knowable 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 a constraint no established method covers: carrier and channel events arrive out of order and with conflicting timestamps, and existing reconciliation techniques are known to produce inconsistent state under that combination. 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
The recurring pattern we see is good engineering described as R&D because it was hard, or a genuinely experimental slice buried inside a large automation project and never framed as an experiment. Both cost you at review time. Our distinct value on automation work is drawing the line cleanly — separating the routine engineering from any genuinely experimental activity, so the routine build isn't overclaimed and the real unknown isn't lost. As a Registered Research Service Provider, we help frame the research — the unknown, hypothesis and experiment — before the work runs, while the uncertainty is still visible. Being an RSP is a registration and listing, not a government endorsement or a guarantee that any activity is eligible. A good place to start is our two-minute self-assessment and the software and AI page.
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 cross into core R&D only where a genuine technical unknown sits inside the work that existing methods can't resolve, tested systematically. Eligibility is self-assessed against your facts.
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: Usually not. Connecting systems through documented APIs is applying known methods to a known outcome, even when intricate. It may only shade into eligible work where integration forces a genuine technical unknown that established approaches demonstrably can't solve — which you'd need records to support.
Q: Could internal operations automation ever be claimed?
A: Be careful here. Software developed for the dominant purpose of the company's own internal business administration is specifically excluded from being a core R&D activity under s 355‑25(2). That doesn't automatically answer every supporting-activity question: an excluded activity would need to satisfy the separate and stricter supporting R&D activity requirements, including the relevant dominant-purpose test. Assess internal automation carefully rather than treating it 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: this article describes the current rules. Changes to the R&D Tax Incentive proposed to commence from 1 July 2028 are, at the time of writing, proposals only and not yet law.
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.
