Accounting /Decisioning live field guide · 8 min

Bank-Feed Coding Assistant

Drafts the account and GST code for each bank-feed line from your chart of accounts, coding rules and payee history — so the bookkeeper confirms and handles the genuine exceptions, not the 80% that repeat.

Open the live demo

theater/demos/accounting_bank-feed-coder.html · sandbox · read-only

Open

FIG. 1

The live demo, running on fabricated data. Open it to step through the full flow — every output is shown for a person to approve before anything happens.

How it would work

Reads each bank-feed line against the chart of accounts, the firm's coding rules and how that payee was coded before, splits the routine lines from the exceptions, and hands both to the bookkeeper to confirm and sign off.

Input 01

The feed + the rules

The unreconciled bank-feed listing — date, payee, amount — plus the firm's chart of accounts, the documented coding rules, and the coding history for recurring payees.

Agent 02

Proposes a code per line

For each line it proposes an account and GST treatment, attaches the rule or precedent it used and a confidence, and routes anything novel or odd — new payee, unusual amount, likely capital or drawings — to a review stack.

Output 03

Two stacks to work

A confirm stack of rule-matched, high-confidence lines and a review stack of flagged exceptions, each with its reason. The bookkeeper confirms the routine in one action and decides the rest. Nothing posts and the reconciliation sign-off stays human.

Where it works well

It codes the same payees the same way, every period, and never gets bored doing it.

Best for a bookkeeper or BAS agent on steady books with recurring suppliers, where the same payees recur quarter to quarter.
It proposes from your own rules and how each payee was coded before — so the routine 80% arrives pre-coded with its basis shown, ready to confirm.
Across a book of clients, the recaptured hours go back into the exceptions and the reconciliation judgement, not line-by-line ticking.

The grind in bookkeeping isn't the hard calls — it is coding Telstra to Telephone & Internet and the coffee roaster to Stock, line after line, period after period. That repetition is exactly what gets rushed at month-end.

Where it works badly

It is weakest on the tail it has never seen — and a confident proposal can hide a wrong call.

Weak on capital-vs-expense, drawings-vs-expense, and private-use calls — it should flag these, not guess a code.
GST is only as good as the supplier's known registration status; an unconfirmed ABN means the GST treatment is a flag, not a fact.
A messy book with no coding history gets little benefit until the rules and precedents exist — there is nothing yet to repeat.

The honest test

If your coding time goes on novel transactions and chasing what a payment actually was rather than repeating codes you already hold, this saves you less than you'd hope until the coding discipline is in place.

A brand-new payee, a one-off, an inter-entity transfer, or a payment that reads as drawings rather than an expense is a judgement the precedent can't make. Point it at books with no rules and constant novel lines and it has nothing to learn from.

What it doesn't do — and shouldn't

It proposes. The bookkeeper confirms and owns the rec. That boundary is deliberate.

WHAT IT DOES

Surfaces the account and GST code it proposed, with the rule or precedent behind each

Flags new payees, unusual amounts, likely capital, drawings and unconfirmed-GST lines as review items

Splits the feed into a confirm stack and a review stack so attention goes where it's needed

WHAT IT WON’T

Post the coding to the ledger or commit a journal

Decide the novel or ambiguous coding call

Sign off the reconciliation or certify the books complete

The reconciliation is a professional judgement under the APES 110 Code of Ethics duties of competence and confidentiality, and where a BAS follows, the reasonable-care duty under the Tax Agent Services Act 2009 sits with the TPB-registered agent — not with software. The accountable person stays on the decision because the consequence lands on them.

What your data has to look like

A real chart of accounts, coding rules the tool can read, and enough payee history to learn the pattern.

Typical readiness

across orgs we see, before the first job

A current chart of accounts

Usually ready

Coding rules written down somewhere

Needs shaping

Coding history for recurring payees

Usual weak point

Supplier GST registration status

Needs shaping

A clean, complete bank feed

Usually ready

The real first job

The weak point is usually the rules and the history: rules that live only in a bookkeeper's head, and clients new enough that there's no precedent to learn from. Making the coding rules explicit and consistent is usually the real first job — a bookkeeping-discipline exercise more than a software one, larger and more valuable than the coding layer on top. Fix that, and every period after is faster and right by default.

Right fit if…

You run steady books with recurring suppliers coded the same way each period

The volume is real but most lines are routine, not novel

Your chart of accounts and coding rules exist somewhere the tool can read

Recurring payees have enough history for the pattern to be learnable

Walk away if…

The books are a mess with no rules and constant one-off transactions

Brand-new clients with no coding history to learn from

Most lines are capital, drawings or private-use judgement calls

You want a tool that codes and reconciles for you without a person confirming

Open questions

The worried-buyer questions, answered straight

No — it proposes codes, it doesn’t commit them. Every line carries a confidence and the coding rule or payee precedent behind it, and anything novel, unusual, or likely personal-versus-business is routed to a review stack rather than coded silently. The bookkeeper confirms the routine and decides the exceptions before anything posts, and the reconciliation sign-off — a judgement under the APES 110 Code of Ethics — stays human.

It flags the novel tail rather than guessing it. New payees, one-off transactions and inter-entity transfers are exactly the lines it routes to a person; the repetition it automates is the recurring, rules-matched 80%, not the unknown. On a messy book with no rules or history, building the coding discipline is the real work — and the assistant on top saves less until that’s in place.

No. It takes the repetitive coding off the desk so the bookkeeper handles exceptions — capital versus expense, drawings, unconfirmed GST status — and owns the reconciliation. On books you can’t fully staff, the gain is reclaimed capacity and faster turnaround, not fewer people. The judgement and the rec stay with your bookkeeper.

It codes against whatever’s in force when you run it, so it’s only as right as the current chart of accounts, your latest coding rules, and recent payee history. A renamed account or a new recurring supplier needs the rule or a few coded examples before the tool can repeat it. Run it on a connected, complete feed for the period — a line added after you run it isn’t coded until you re-run.

Yes, when it’s scoped that way from the start. It operates inside your own ledger and tenancy via API — Xero, MYOB or QBO — not a public chatbot, and client financials are not used to train third-party models. Access is role-based and the coding basis is auditable line by line. The demo here runs on fabricated data; Harbourview Cafe is not a real client.

Your bookkeeper owns the rec, exactly as now. The tool drafts coding and surfaces exceptions; confirming the books are complete and correct is a professional judgement under the APES 110 duties of competence and confidentiality. Where a BAS follows, only a TPB-registered agent can lodge it for a fee and the reasonable-care duty under the Tax Agent Services Act 2009 sits with that agent.

What it takes to build

3–5 weeks · 4 phases

Reused from template~60%

Bespoke to this skin~40%

stack · Claude · ledger API (Xero/MYOB/QBO) · classifier · rules engine · review UI

What it would cost

Fixed scope, fixed price, fixed dates.

Bite-sized first piece

One contained change, low risk

Pilot build

Most builds land here

Embedded support

Scale on proof

Considering this for your practice?

The honest place to start is a bite-sized first piece — one client book, one period, low risk. Tell us where coding time actually goes; we'll play it back, scope it, and show you what's possible.

Book a call How we work