We automated our own GST return with an AI agent. Here is how it actually works.

Bi-monthly GST is the recurring tax-admin tax on every NZ owner-operator. Multiple bank accounts, a pile of invoices in email, learned-but-wrong reconciliation rules, hand-built journals for home-office deductions, then a return to cross-check before filing. It is usually a half-day to a full day of unpaid work, every two months. Eight to twelve days of owner time a year.

We use ours as a real test bed for agentic automation. Below is the pipeline we built and run on our own books: four phases that take the GST cycle end-to-end and hand a draft return to a human for approval. Bank-agnostic, accounting-platform agnostic, works for any NZ owner-operator with the same pattern.

This is not a "just press the button" story. It is a careful pipeline with a verification step after every action that matters. Read it as a reference for what a properly engineered agent looks like.

The four phases

Each phase has a single, narrow job. Each ends in a human checkpoint. Nothing destructive happens without that checkpoint.

Phase 1: Pre-flight + ingestion

The agent confirms what period it is working on, then pulls every transaction across every relevant account:

• Live state from the accounting system (balances, items-to-reconcile, chart of accounts). Never trust yesterday's account IDs, they drift.
• Business accounts via the accounting platform's bank feed.
• Personal accounts via a banking aggregator API.

Every transaction gets classified into one of four buckets with a confidence score:

Bucket	Meaning	Next action
Business income	Revenue into a business account	Code to revenue, attach RCTI if applicable
Business expense	Business spend on either business or personal card	Code to the matching expense GL, attach invoice
Personal	Personal spend on personal accounts	Ignore for GST
Transfer	Inter-account movement	Reconcile both legs without GST treatment

The classifier uses three signals: merchant pattern, the reconciliation rule the accounting system has learned, and the agent's own LLM-based read of the memo. When all three agree it is "confident". When any disagree it is "needs review". The classifier never acts, only proposes.

Phase 2: Invoice retrieval and matching

For every business transaction, the agent goes hunting for the invoice or RCTI:

1. Searches the inbox over the period for messages from suppliers and known contacts.
2. Downloads and OCR-extracts the invoice number, date, amount, GST treatment, description.
3. For invoices that arrive as web links, follows the link, signs in if needed, pulls the PDF.
4. Matches each invoice to a bank transaction (invoice number first, then amount + date, then supplier + amount).

The output is a triple match table the human reviews:

MATCHED:
  Bank line               Amount     Invoice                       Confidence
  3 Mar  CONTRACTOR INC   xxx.xx     RCTI-8994017.pdf (12 Mar)     Ref + amount
  10 Mar SUPPLIER LTD     xxx.xx     inv-2026-2287.pdf (15 Mar)    Ref + amount
  11 Mar FUEL STATION     xx.xx      receipt-20260311.pdf          Date + amount

UNMATCHED:
  9 Mar  SOFTWARE SUB     xx.xx      No receipt email found

EXTRA INVOICES:
  invoice-target-mar.pdf  xx.xx      Possibly matches Target Co.

Only after the human signs off does the agent attach the PDFs to the corresponding bank transactions.

Phase 3: Reconciliation with mechanical verification

This is the phase where most agentic systems quietly break. Reconciliation feels like rubber-stamping, but a sloppy agent does irreversible damage.

We learned this the hard way. The agent built a confident batch of 21 reconciliation suggestions that all looked correct on a quick read. We approved the batch. The 21st was a transfer line where the accounting system's learned rule pointed at the wrong destination account. The agent confirmed it, the books absorbed a wrong transfer, and the cleanup took ninety minutes the next day.

The fix was mechanical, not heuristic. Every transfer line carries a destination-account signal in its bank reference. The agent now asserts the suggested destination matches that signal programmatically, on every single transfer line, before flagging anything as confident. A 21st correct suggestion does not earn trust.

Two more rules baked in from the same incident:

1. "The UI confirmed" is not "the action succeeded". After every reconciliation, the agent queries the API for the created transaction and verifies it landed against the right account. The UI confirmation is a hypothesis; the API read is the proof.
2. Stop on the first failure. Batch loops track a seen set and abort the moment a row would be clicked twice. An earlier version clicked the same OK button 57 times because it verified at end-of-loop. The rule now is verify-after-each-action, abort on first non-effect.

With these in, reconciliation runs reliably. Propose, approve, execute, verify. No silent mistakes.

Phase 4: Journals, GST return, human approval

The agent scans the personal accounts for utility and other business-deductible spend (power, internet, rates, parking, fuel, accommodation, office supplies), applies the deductions per your accountant's rules, and drafts the manual journal as DRAFT, not posted.

It then pulls the GST return from the reporting API, prints the headline figures with a comparison to the previous two periods, and runs sanity checks:

GST RETURN: [Period]
  Total sales and income (incl GST):  $XX,XXX
  GST collected:                      $X,XXX
  Total purchases (incl GST):         $X,XXX
  GST credit on purchases:            $X,XXX
  ────────────────────────────────
  NET GST TO PAY:                     $X,XXX

  Compare to previous periods:
    Last period:   $X,XXX
    Period before: $X,XXX
    Average:       $X,XXX

  Sanity checks:
  ✓ GST collected matches revenue × 3/23
  ✓ Withholding balance covers payable amount
  ✓ P&L for period aligns
  ⚠ Power deduction up 20% vs last period, confirm utility increase

The agent never files. Filing is a single human action on the tax authority's site, with the agent's draft journal and sanity-checked return in front of the human. The agent's job is to make that take two minutes instead of two days.

What makes this agent reliable

Three rules that matter more than the prompt-engineering:

1. Every action that touches money is reversible and approval-gated. The agent reads freely. It only writes after a human says yes, in bounded batches, with a verify step after each action.
2. The agent does not invent. Hardcoded IDs, cached account maps and remembered context all rot. Re-pull live state each session.
3. Verification is mechanical, not LLM. The "did the action succeed" check is an API query, not the agent reading the UI back. UIs lie about success more often than humans assume.

Not specific to GST. These are the rules that let any agentic automation that touches money or records survive contact with reality.

Tool, bank, accounting-platform agnostic

The pipeline is described in generic roles, not specific products. It moves cleanly to any combination of major NZ banks (ANZ, ASB, BNZ, Westpac, Kiwibank, TSB), accounting platforms (Xero, MYOB, QuickBooks), inboxes (Gmail, Microsoft 365, IMAP) and tradie job-management tools (ServiceM8, Tradify, Fergus, simPRO). The plumbing changes; the architecture does not.

What this is worth

For our own books this took GST cycle time from about a day per return to roughly thirty to sixty minutes of human review. Thirty plus hours a year saved on one process. Multiply across the dozen recurring administrative cycles a typical small business runs and the case for agentic automation as a real business decision is straightforward.

If you want it built for you

This is the kind of agentic automation we build for NZ professional-services firms and larger trade firms on retainers. We are tool-agnostic, accounting-platform agnostic and bank-agnostic, the pipeline above runs on whatever you already have. Scope and price are quoted per job after a short discovery. See business automation for the wider picture, or practical AI automation for the architectural side of how we build agents that do not silently break things.