Where AI can and cannot sit in a bookkeeping workflow

This is a working boundary for bookkeepers and BAS agents. Take it, change it, use it. There’s nothing to sign up for and nothing to reply to.

I’m not a BAS agent and this isn’t tax advice. It’s about where an automated drafting tool can safely sit in a workflow, which is a different question and the one I actually work on.

Why the line matters more here than almost anywhere

A badly written sentence announces itself. You read it and something feels off.

A wrong number does not. It sits in a column looking exactly like a right number. It reconciles to nothing, contradicts nothing on the page, and the first person to notice is either your client or someone your client answers to.

That asymmetry is the whole reason the boundary below is drawn where it is. It isn’t caution for its own sake. It’s that the two kinds of error have completely different detection costs, so they deserve completely different rules.

The one rule

Nothing that produces a figure a client will act on.

Everything around that figure is fair game.

If you keep only one line from this page, keep that one. The rest is working out what falls on each side.

Fair game

These are repetitive, high-volume, and a mistake is visible immediately:

• Chasing missing paperwork. Drafting the “we still don’t have these six receipts” email, per client, every month. This is often the single largest time sink in the practice and almost none of it is judgement.
• Explaining a figure you have already computed. Turning a variance you’ve identified into a paragraph a non-accountant can follow.
• First-pass coding suggestions on transactions — as suggestions you review, never as postings.
• Summarising a long email or a messy client message into what was actually asked.
• Drafting your own internal process notes, checklists and handover documents.
• Preparing the questions you need to ask a client, from a list of unresolved items.

Not fair game

• Any figure that reaches a client or a lodgement. Totals, GST amounts, allocations, apportionments, conversions, payroll figures. These come from your system and your work, never from something that generated them.
• Deciding a treatment. Whether something is deductible, which code applies in an ambiguous case, how to handle a mixed-use expense.
• Reconciliation sign-off. A tool can flag a mismatch. It cannot decide the mismatch is acceptable.
• Anything sent to the ATO or to a client without a person reading it first.
• A client who is upset or in trouble. Those don’t get a drafted reply.

The check to put in front of a suggestion

If you do let something suggest transaction codes, don’t accept the suggestion on its own terms. Require it to show:

1. What it matched on — the supplier name, the description, a prior transaction
2. Whether it has seen this supplier before for this client, and what was done last time
3. Its own uncertainty — and a rule that anything uncertain goes to you rather than through

Then keep a rule you don’t bend: a suggestion that can’t show its basis gets treated as no suggestion at all.

How to tell whether it’s helping

Not “how much faster is month-end”. Measure:

Out of the last month’s client work, how many items had to be corrected after they’d gone out?

If that number rises at all, the arrangement is losing you money regardless of the time saved. Corrections cost more than the drafting ever saved, and they cost trust as well as hours.

What this doesn’t do

It won’t tell you which software to use, and it won’t help with anything requiring an actual view on tax treatment — that’s your expertise and your registration, not mine. It’s a boundary, not a system.

---

Written by Hirotoshi Yamaguchi, a sole trader on the Gold Coast (ABN 64 998 187 645) who works with small businesses on AI operations. If it’s useful, it’s yours to keep.

---

Guardrail Ops — Hirotoshi Yamaguchi, Gold Coast QLD. Get in touch