Bank rec and coding, two days a 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.
Used by
- Accounts Officer
- Accounts Administrator
- Finance Officer
- Assistant Accountant
How to get this live in your business
Free. The Two Records Build Standard: the objects, the checks in order, and the pass test.
Ready for
Now a build standard
This paper is the argument. The specification, with the checks in order, the objects, a pass test and a conformance checklist, is the Two Records Build Standard and the Recurring Report Build Standard. Build to that; read this for why.
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.
Take the spec to Claude, ChatGPT or Copilot. The sentence to paste is one click away.
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. ROI Snapshot
Illustrative directions, not measured results. Your numbers will differ: the point is which levers move.
Most
Recurring lines coded without a person
By standing rule, the rest by model at high confidence. Your share depends on how many rules you write
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.
9. 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. Often one shape dominates the queue, and if it is the recurring fees, a rule fixes it 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'.
How many transactions reached a person last month?
Nothing ready-made clears a rec queue for you: it is a build, and the Two Records standard below is its spec. If what actually hurts is money owed rather than the month-end tidy-up, that part is ready-made. Get Paid on Office Voice rings debtors off live Xero and writes the promised date back to the invoice. Get Paid $199 a month, per client business for a practice.
Technical? The build standard is open. Take it.