How to automate compliance workflows in an Australian accounting firm

The firms we see stall are not the ones lacking budget or software. They are the ones that ran a promising pilot, never got it into production, and eighteen months later have three half-built things and a partner group that has quietly stopped believing.

This is the method that avoids that.

Step 1: Pick the workflow, and pick only one

The instinct is to start with the workflow that annoys people most. That is usually the wrong choice, because the most annoying workflows are annoying precisely because they are irregular and judgement-heavy, which is what makes them hard to automate.

Score candidate workflows on four dimensions:

Individual tax return workpaper preparation scores well on all four in most practices. So does client onboarding, ATO correspondence handling, and month-end management reporting for a standardised client base.

Complex advisory, Division 7A planning and anything driven by client-specific negotiation score badly. Leave them.

Step 2: Map how the work actually happens

This is the step firms skip, and it is the one that determines whether the build works.

Sit with the person who does the work and watch them do it three times. Not a workshop. Not a process document. Watch.

What you are looking for:

• The undocumented steps. Every firm has a workflow where someone checks something in a second system that appears nowhere in the procedure.
• The decision points. Where does the preparer stop and think? Those are the points a tool either needs to handle or needs to escalate.
• The rework loops. Where does work come back from review, and why? If 40 percent of returns come back for the same reason, that is the thing to fix, and it might not need AI at all.
• The handoffs. Time is usually lost between steps, not within them. A workflow that takes three hours of effort and eleven days of elapsed time has a handoff problem.

Time each step. You will need the baseline in step 6 and you will not be able to reconstruct it later.

Step 3: Decide what the tool does and what the human does

Before anything is built, write one sentence for each.

For a workpaper workflow, that might be: the tool extracts figures from source documents and populates the template; the preparer verifies every figure against source and resolves anything flagged.

This sentence does more work than it looks like. It sets the scope of the build, it defines the review step you need under sections 35 and 40 of the Determination 2024, and it tells staff what is changing about their job. Ambiguity here is the main cause of adoption failure, because people cannot tell whether they are supposed to trust the output or check it.

The default position should be that the tool drafts and a person disposes. Under Code items 9 and 10 you must take reasonable care to ascertain the client's state of affairs and apply the taxation laws correctly, and TPB(GS) 55/2026 is explicit that AI output is not a substitute for your own analysis.

Step 4: Build around your existing stack

The single most common cause of a failed automation project in an accounting firm is a tool that requires the practice to work differently.

If your firm runs Xero, XPM and FYI, the automation should read from and write to Xero, XPM and FYI. If it produces output that then has to be manually re-entered into your document management system, you have moved the work rather than removed it.

Practical constraints worth knowing before you start:

• API coverage varies. Ledger platforms are generally well served. Practice management and document platforms vary considerably in what they expose.
• Document capture is where accuracy is won or lost. Structured PDFs extract reliably. Photographs of receipts and handwritten records do not.
• Australian tax specifics are not in general-purpose tools. Anything touching Div 7A, small business CGT concessions, or trust distributions needs local logic, not a general model's guess.

We compare the platform landscape in AI tools for Australian accounting firms in 2026.

Step 5: Test against real files, then run parallel

Two testing stages, and skipping the second is the classic mistake.

Stage one, real files. Not synthetic examples. Not the three tidiest clients. Take twenty real engagements spanning your actual client mix, including the messy ones. Run them through. Record every failure and categorise it.

Expect the first pass to be worse than the demo. That is normal and not a reason to stop. What matters is whether failures cluster into fixable categories or scatter randomly. Clustered failures are a build problem you can solve. Scattered failures usually mean the workflow was a poor candidate.

Stage two, parallel running. Run the automated and manual processes side by side for a defined period, usually two to four weeks or one compliance cycle. Compare outputs. This is where you learn what the tool does on the cases nobody thought about.

Parallel running feels wasteful. It is the cheapest insurance available, and the firms that skip it are the firms that quietly roll back three months later.

Step 6: Measure against the baseline

You took timings in step 2. Take them again.

Measure four things:

1. Preparation time per engagement. The headline number.
2. Review time per engagement. Watch this one. Automation that halves preparation and doubles review has achieved nothing.
3. Rework rate. Percentage of engagements coming back from review.
4. Elapsed time. From client documents received to work ready for review.

Report all four to the partner group. Reporting only the first is how firms lose credibility internally when someone points out that review got harder.

How long does this take?

Four to eight weeks from kickoff to first workflow live is realistic for a single, well-chosen workflow in a firm with a modern cloud stack.

The variable is not the build. It is decision latency. Firms where one partner owns the project move at the top of that range. Firms where every step needs consensus at a monthly partners' meeting take a quarter.

Budget the following:

What actually goes wrong

Six failure modes, in rough order of frequency.

• Starting with too many workflows. Three parallel builds means three half-finished things and no proof point.
• No named owner. A project owned by the partnership is owned by nobody.
• Nobody defined the review step. Staff cannot tell whether to trust the output, so they check everything twice and the time saving evaporates.
• The pilot never gets a production decision. This is the most common one. The pilot works, everyone is pleased, and there is no scheduled moment where someone decides to roll it out. It just fades.
• Adoption was assumed. The people doing the work were not consulted, so they route around the new process.
• Compliance was left until after the build. Then the engagement letter turns out not to cover disclosure to a third-party technology provider, and the whole thing pauses. Handle this at step 1. See what TPB(GS) 55/2026 means for your firm.

Where to start if you have nothing running

Pick the workflow your team complains about that also runs a few hundred times a year with roughly the same shape each time. In most Australian practices that is individual return preparation.

Map it properly, define the review step, build against your existing stack, test on real files, run parallel for one cycle, and measure four numbers.

Do that once, successfully, and the second workflow is far easier because you have an internal proof point and a team that has seen it work. Do three at once and you will likely have none.

If you want the mapping done from the outside by someone who has sat in the chair, our automation audit does exactly this and produces the workflow shortlist and the compliance wrapper together.