The problem
A professional-services firm — roughly 25 staff across a single Victorian office, about A$5M turnover — was running its accounts payable by hand. Supplier invoices arrived by email and post; staff expense receipts arrived as phone photos, printed dockets and the occasional PDF. One part-time bookkeeper, with help from an office administrator during busy weeks, keyed each one into the accounting system: supplier, date, amounts, GST, and the account code the item should sit against.
The volume was not huge — a few hundred documents a month — but the work was slow and unforgiving. A transposed figure, a receipt coded to the wrong expense account, or GST claimed on a GST-free item all meant rework later, and some of it only surfaced at BAS time. The bookkeeper was spending an estimated eight to ten hours a week on data entry that added no judgement beyond the moments where judgement actually mattered: is this the right supplier, the right code, the right GST treatment.
The firm did not want to change accounting systems, and it did not want a black box posting transactions on its own. The brief was narrow and sensible: take the typing out, keep a person in the loop, and do not lose the audit trail.
What we built
A capture flow that sits in front of the existing accounting system and does the reading, not the deciding.
A document — emailed invoice, uploaded PDF, or a photographed receipt — lands in an inbox the flow watches. The document is extracted into structured fields: supplier, invoice or receipt number, date, line items, subtotal, GST, and total. The flow then suggests a supplier match against the existing contact list and an account code based on the firm's own coding history for that supplier and item type. GST is calculated per line and checked against the document, so GST-free and GST-inclusive items are handled correctly rather than assumed.
Nothing posts automatically. Every document arrives in a review screen with the extracted fields, the suggested coding, and the original document side by side. The bookkeeper confirms or corrects, then approves. Only on approval does the entry post to the accounting system. Every document, every suggestion, every correction and every approval — with who approved it and when — is written to an audit log.
How it works
The orchestration runs in the firm's own environment. Extraction uses a commodity model with a fixed output schema, so the flow always returns the same set of fields in the same shape. Supplier matching and coding suggestions draw on the firm's coding history exported from the accounting system, not a generic ruleset, so the suggestions reflect how this firm actually codes.
Three controls keep it honest. First, a confidence check: where extraction is uncertain — a faded receipt, an unfamiliar supplier, totals that do not reconcile — the document is flagged for closer attention rather than presented as ready to approve. Second, GST is validated against the document total, so a mis-read GST amount is caught before a person ever sees a wrong number. Third, the human approval step is not optional and cannot be skipped; the flow drafts, a person posts.
The audit log captures the input document, the extracted values, the model's suggestions, any human correction, and the approving user and timestamp. That record is what makes the entry defensible at BAS time or in a review.
The results
Measured over the pilot, against the firm's own prior baseline:
| Before | Pilot | |
|---|---|---|
| Bookkeeper time on data entry | ~9 hrs/week | ~1 hr/week review |
| Time saved | — | ~36 hrs/month |
| Entry errors (mis-key, mis-code) | baseline | down ~60% |
| Cost per document (model + infra) | — | ~A$0.04 |
| Month-end close | dragged | noticeably shorter |
At roughly A$45–70 an hour loaded, the recovered time is worth on the order of A$1,600–2,500 a month. The larger win the firm reported was fewer surprises at BAS time: because GST is checked per line at capture and the coding is suggested from history, the corrections that used to accumulate quietly through the quarter mostly stopped.
The error reduction is a relative figure from a low base — the team was careful to begin with — and it holds because the machine does the reading and a person still does the deciding.
How the team owns it
The bookkeeper runs the flow day to day and is the named approver. We wrote a short runbook covering the review screen, the flagged-document cases, and how to correct a suggestion so the flow learns the firm's preference over time. The office administrator was trained as a backup approver for busy weeks.
The firm owns the environment, the audit log and the coding history the suggestions are built from. Nothing posts without a person, and the record of who approved what is theirs to keep. If the firm later wants to widen the flow to purchase orders or staff expense claims, the same review-and-approve pattern extends without a rebuild.
If this sounds like a fit, our AI automation work starts from a scoped readiness audit. Talk to us.