Two Days a Month, Every Month
Bank reconciliation, expense coding and the reports nobody enjoys building are three quiet jobs hiding inside one accounts administration seat. None of them is difficult. All of them are relentless.
Does the work of
- Accounts Officer
- Accounts Administrator
- Finance Officer
- Assistant Accountant
Ask whoever does your bank reconciliation how long it takes and you will get a number. Ask how much of that was deciding something, and the answer is a few minutes. The rest was matching things that already matched, and chasing four people about what a card payment in March was for.
In short
- The problem
- Bank reconciliation, expense coding and the monthly report pack are three separate jobs sharing one seat. None is difficult and all are relentless.
- Why it persists
- Almost none of the time goes on deciding anything. It goes on matching things that already match, and on chasing four people about what a card payment in March was for.
- What we would automate
- The matching, the coding rules that decide where a transaction lands, the queries that stall a reconciliation, and assembling the pack.
- What stays with a person
- Uncertain GST treatment, the chart of accounts itself, closing the period, the commentary that leaves the building, and anything that looks like a control failure.
Want the whole thing by email?
This paper, plus the rest of the library. One click to stop them.
1. Where the Two Days Go
An accounts administration ad usually lists a dozen duties and does not rank them. Read a few and the same three things account for most of the week: matching transactions that have already happened, deciding which account each one belongs to, and assembling the numbers into something a manager can read.
What these three share is that the answer already exists somewhere. The bank knows what was paid. The receipt says what it was for. The ledger holds the numbers the report wants. The work is not producing information, it is moving information between systems that could talk to each other, and then checking it.
That is why this seat is so often described as busy rather than hard. It also explains the shape of the automation: high volume, low ambiguity, with a small tail of genuinely uncertain cases that deserve a person and currently get the same fifteen seconds as everything else.
The bottom line
The goal is not a smaller team. It is that the uncertain twenty transactions get real attention because the certain four hundred stopped competing for it.
2. The Queries That Stall the Rec
To be clear about what this is not: nobody should be rebuilding bank reconciliation. Xero and MYOB are the reconciliation tool, your bookkeeper reconciles in them, and matching arithmetic is the one thing every incumbent already does well. An automation that re-implements it is work with no customer.
The ledger suggests matches from the bank feed and, for clean transactions, it is good at it. The month is not spent on those. It is spent on the residue the ledger cannot resolve, and on the phone calls and emails needed to explain them. That queue is the target, and it falls into a small number of recognisable shapes.
So the useful framing is clearing the queries that stall the rec, never doing the rec.
One payment, several invoices
A lump sum covering four invoices, sometimes with a deduction. Resolvable by reading the remittance advice and splitting the allocation.
A reference that means nothing
"PAYMENT 4471" or a trading name that is not the ledger name. Resolvable from history: this account, this amount, this day of the month, every month.
Fees, interest and rounding
Small recurring amounts that need coding, not matching. A rule handles these permanently and they should never appear in a queue again.
Timing
A payment banked on the first for an invoice dated the last. A person spends real minutes proving these are the same event.
Genuinely unexplained
The residue, and the only category that deserves attention. Usually a handful a month, and often a real problem worth finding early.
The measure that matters is not how many transactions reconciled. It is how many reached a human, and whether that number is falling as the rules learn the recurring cases.
3. Expense Coding
Coding is a classification problem with a house style. Which account, which tax treatment, which job or cost centre, which of them are claimable and which are not. The right answer depends on rules that live partly in an accountant’s head and partly in what was done last time.
A model reads the receipt or statement line, proposes a code with a confidence score, and cites its reason: this supplier has been coded here nineteen times, or this description matches a rule you wrote. High confidence flows through. Low confidence is queued with the two or three plausible codes offered rather than as a blank field.
The important design choice is that GST treatment should be a rule, not a guess. Whether something carries GST is usually determinable from the supplier and the category, and where it is not, guessing quietly is the wrong behaviour: a mis-coded tax treatment is an error that propagates into a BAS and is expensive to unwind. Uncertainty here should stop and ask.
The rules are the product
Nobody outside your business can write your chart-of-accounts conventions for you, and a model left to infer them will be plausibly wrong in ways that survive until someone reviews the accounts. Writing the coding rules down is the project. The automation is what enforces them.
4. Reporting
Most small-business reporting is a person exporting the same three reports, pasting them into the same spreadsheet, and writing two sentences of commentary. It happens late because it depends on the first two jobs being finished.
Automating the assembly is straightforward and slightly beside the point. The gain is in changing what reporting is for: instead of a pack that arrives a fortnight after the month it describes, you get the same numbers on a schedule with the exceptions called out: the cost code that moved twenty per cent, the customer whose ageing jumped a bracket, the supplier whose average invoice has crept up.
A model is genuinely useful for the commentary, with one condition: it must only describe what the numbers show. Asking it to explain why is asking it to invent a cause, and a confidently wrong explanation in a board pack is worse than no commentary at all.
Worth saying plainly: if the reconciliation and coding are not current, automated reporting produces wrong numbers faster. Sequence it last.
5. Key Benefits
A Queue That Shrinks
Recurring unmatched transactions become rules, so the same fee line never reaches a person twice.
Split Allocations Handled
One payment across several invoices, read from the remittance rather than worked out by hand.
Coding With a Reason Attached
Every proposed code cites its basis: supplier history or a rule you wrote, so a review is quick and a correction teaches it.
GST That Asks Rather Than Guesses
Uncertain tax treatment stops for a person, because a mis-coded BAS is expensive to unwind.
Month End Without the Scramble
The work is current rather than assembled in a fortnight-long push after the period closes.
Exceptions Surfaced, Not Buried
The cost code that moved, the customer whose ageing jumped, the supplier creeping up, called out rather than sitting in a column.
Reports That Arrive On Time
Assembled on a schedule from current data, with commentary limited to what the numbers actually show.
An Audit Trail By Default
Who coded what, on what basis, and what changed, recorded because the system did it, not because someone kept notes.
6. End-to-End Workflow
- 1Bank feed and card transactions arrive in the ledger
- 2Receipts and remittances captured from a monitored inbox or a phone photo
- 3Documents read and matched to transactions, including one payment across several invoices
- 4Recurring lines coded by standing rule, with no human involvement at all
- 5Remaining transactions coded by the model, each with a confidence score and a stated basis
- 6Uncertain codes and all uncertain GST treatments queued for a person, with options offered
- 7Corrections captured as rules so the same case does not return next month
- 8Query queue cleared so the rec can close in the ledger, with genuinely unexplained items raised as a short list
- 9Reports assembled on schedule from current data, with variances called out
- 10Commentary drafted from the numbers only, for a person to approve before it circulates
7. What Stays With a Person
This is bookkeeping, and the output is the basis for a tax position. The boundary is not about capability, it is about where a quiet error is expensive.
Anything with an uncertain GST treatment
A wrong tax code propagates into a BAS and is unwound at cost. Uncertainty should stop and ask, every time.
The chart of accounts itself
Coding conventions are a professional judgement about how this business wants to see itself. A model enforces them; it should not invent them.
Closing the period
A person signs off that the accounts are complete. That is a statement about the world, not a status in a workflow.
The commentary that leaves the building
Drafted from the numbers is fine. Approved by somebody who knows why the numbers moved, before it reaches a board or a bank.
Anything that looks like a control failure
An unexplained transaction may be an error, or it may not be. Either way it goes to a person immediately, not into a queue.
8. Potential Tech Stack
One workable shape. Most businesses already own the first two layers and are not using them fully.
| Layer | Options | Role |
|---|---|---|
| Accounting Ledger | Xero, MYOB, QuickBooks | Chart of accounts, tax codes, and the reconciliation itself |
| Bank Feed | Ledger feeds, open banking | Transactions arriving, which everything else runs against |
| Document Capture | Hubdoc, Dext, a monitored mailbox | Receipts and remittances in, including photographs from a phone |
| Extraction and Coding | Claude, GPT-4o, Azure Document Intelligence | Reads documents, proposes a code with a confidence score and a stated basis |
| Rules Store | A table you can edit, not code | Standing coding rules and recurring matches, editable by whoever owns the accounts |
| Exception Queue | A simple internal dashboard | The short list a person works, with options offered rather than blank fields |
| Reporting | Looker Studio, Power BI, custom dashboard | Scheduled packs, variance callouts, and drafted commentary for approval |
Where to start if the cash is the problem
If what actually hurts is money coming in or going out rather than the month-end tidy-up, start with the ledger that is costing you: receivables or payables. Reconciliation and coding pay back steadily; those two pay back faster and more visibly.
9. ROI Snapshot
Illustrative figures for a business with around 600 bank and card transactions a month and one person handling accounts administration. Your numbers will differ: the point is which levers move.
80%+
Coded without a person
Recurring lines by standing rule, the rest by model at high confidence
Days
Off the month-end close
Because the work is current rather than assembled in a push after the period ends
A falling
Exception queue
Every correction becomes a rule, so the same case does not come back next month
The gain that gets noticed is not the hours. It is that the numbers are current enough to make a decision on in the second week of the month rather than the last.
10. Getting Started
- 1
Count what reaches a human
Not how many transactions you have: how many the ledger could not match or code on its own last month. That number is the whole business case.
- 2
Sort that list by shape
Use the five categories in section two. You will usually find one shape is half the queue, and it is normally the recurring fees, which a rule fixes permanently.
- 3
Write the coding rules down
Supplier by supplier for your top fifty, with the GST treatment stated. Tedious, one-off, and the part no vendor can do for you.
- 4
Automate coding before reporting
Automated reporting on unreconciled data produces wrong numbers faster. Sequence matters more here than scope.
- 5
Keep a correction loop
Every override a person makes should be capturable as a rule in one click. Without that the queue never shrinks and the project stalls at 'quite useful'.
Not ready to talk yet?
Leave your email and we’ll send this paper to your inbox, with a link to the rest of the library. We publish a new one every few weeks and you’ll get those too, one click to stop them.
Your email is used to send you the papers and nothing else. We don’t share it.
How many transactions reached a person last month?
Get in touch with AI Pathway. Bring last month’s unreconciled list and we will tell you which shapes a rule would remove for good, and whether that is worth automating at your volume or not yet.