Bank reconciliation mistakes are the quiet cost centre inside most Australian accounting practices. Individually, each error looks minor — a transaction left uncoded, a GST flag set to the wrong tax type, a review step skipped. Collectively, they compound into BAS errors, ATO scrutiny, and recovery work that eats into every practice's most constrained resource: review time.
This article covers ten specific mistakes, drawn from patterns we see across Australian bookkeeping and accounting practices. For each one: what it is, why it happens, and how to eliminate it.
1. Reconciling at quarter-end instead of monthly
What it is: The team defers reconciliation until BAS time arrives, processing three months of transactions in a sprint rather than maintaining a live ledger throughout the period.
Why it happens: When reconciliation is fully manual, the perceived cost of running it weekly or fortnightly is high. Deferral feels rational in the moment.
How to fix it: Set a fortnightly reconciliation cadence as a firm practice standard — not a guideline. With auto-coded transactions removing the majority of per-line decisions, the time cost of a fortnightly run drops to a fraction of a quarterly sprint. The backlog problem disappears when there is no backlog. BAS prep becomes a confirmation rather than a discovery exercise.
2. Accepting the bank balance without verifying the imported data is complete
What it is: Starting reconciliation against imported statement data that has gaps — missing months, a skipped statement, or a forwarded file that only covers part of the period — without confirming the import covers the full period.
Why it happens: Incomplete imports fail quietly. A statement that stops short of the period-close date looks identical to a complete one until you check the last transaction date.
How to fix it: Before opening any reconciliation period, verify that the last imported transaction date matches today (or the period-close date) and that every statement for the period has been uploaded (CSV, Excel or PDF) or forwarded to the per-client email inbox. Check transaction count against the prior period as a second signal — a sudden drop in transaction volume usually indicates a missing statement, not a quieter month. Phantom reconciliation — books that balance against incomplete data — is harder to unwind than a clean gap.
3. Coding bank fees as N-T instead of INP
What it is: Bank charges — account-keeping fees, transaction fees, dishonour fees — coded with the N-T (not reportable) GST type instead of INP (input-taxed financial supplies).
Why it happens: N-T is the catch-all for "no GST here," and bank fees do not have GST on them. The distinction between a supply that is outside the GST system (N-T) and a supply that is within the system but input-taxed (INP) is one of the most commonly misapplied in Australian bookkeeping.
How to fix it: Create a bank fee coding rule that applies INP to all transactions from known bank fee descriptors (e.g., ACCOUNT FEE, MONTHLY FEE, DISHONOUR FEE, BPAY FEE, TRANSACTION FEE from your client's bank). Review the rule quarterly when you add new banking institutions to a client's chart of accounts. This single rule prevents one of the most common GST errors in practice.
4. Reviewing only the exceptions and not the auto-coded transactions
What it is: Treating the auto-code layer as a black box — approving exceptions manually while assuming the automatically coded transactions are correct.
Why it happens: The auto-code rate looks like a confidence measure. If 92% of transactions were coded automatically, it feels reasonable to focus effort on the 8% that were not. It is not reasonable. Auto-code rate and coding accuracy are different metrics.
How to fix it: Run a monthly spot-check across the auto-coded population: pull 20 random transactions per client and verify the coding and GST treatment are correct. If errors appear in the sample, expand the review scope for that client. See how the three-layer coding system works for detail on where auto-code errors tend to concentrate. Track accuracy separately from auto-code rate — they will diverge in ways that matter.
5. Using a single shared login for multiple team members
What it is: Multiple bookkeepers or accountants authenticate to a reconciliation or accounting system under one shared username and password.
Why it happens: Licensing cost, convenience during onboarding, or inherited practice setup from an earlier era of the business.
How to fix it: Issue individual user accounts for every team member who touches client data. The cost of per-user licensing is negligible compared to the cost of a compliance investigation where the audit trail cannot establish who made a specific coding decision. Per-user accounts are also a prerequisite for meaningful role-based access control — the ability to separate who can code transactions from who can approve and lodge.
6. Not converting recurring ML codings to rules
What it is: A machine-learning model correctly codes the same vendor — say, a client's regular freight supplier or stationery provider — month after month, but the practice never promotes that pattern to a standing rule.
Why it happens: Rule creation feels like extra work. If the ML is handling it, why intervene?
How to fix it: Run a quarterly rule-promotion review. Query the top vendors by transaction volume where the ML model has applied the same coding with high confidence for three or more consecutive months. Promote those patterns to hard rules. This does two things: it removes per-transaction ML cost for known patterns, and it makes the coding deterministic for those vendors — the same code will apply regardless of model confidence fluctuations.
7. Skipping the W1/STP cross-check before BAS lodgement
What it is: Lodging a BAS with a W1 (Total salary, wages, and other payments) figure that has not been reconciled against the STP data already reported to the ATO.
Why it happens: W1 is often populated from payroll software data or a payroll summary, without verifying it against the STP phase 2 submissions already sitting with the ATO.
How to fix it: Include a W1/STP cross-check as a mandatory step in your pre-lodgement checklist. The ATO's data matching systems automatically compare W1 figures against STP-reported payroll totals. A mismatch is an automatic review trigger. The reconciliation takes five minutes and prevents the correspondence that follows. The BAS preparation checklist for Australian accounting practices covers this step in the pre-lodgement stage.
8. Treating the auto-code rate as a proxy for accuracy
What it is: Using "our auto-code rate is 91%" as evidence that 91% of transactions are coded correctly.
Why it happens: Auto-code rate is the metric most reconciliation platforms surface prominently. It is easy to measure and it trends upward as the ML model learns. It creates a plausible story about practice efficiency.
How to fix it: Track coding accuracy separately. Accuracy is the percentage of auto-coded transactions that are confirmed correct on review — not the percentage that were coded automatically. A practice with a 91% auto-code rate and a 94% accuracy rate on that 91% has roughly 6% of its total transaction population incorrectly coded. Measure both. Report both. The gap between the two numbers is where BAS errors live.
9. Not setting a conservative confidence threshold for new clients
What it is: Applying the same auto-code confidence threshold to a new client as to an established one, resulting in incorrect codings being committed automatically before the ML model has learned that client's transaction patterns.
Why it happens: Platform defaults are often set for average accuracy across all clients. A new client with unusual vendor patterns, industry-specific suppliers, or irregular transaction cadences sits far from that average.
How to fix it: Set a conservative threshold — 0.88 or higher — for the first 90 days on any new client. This means the model only commits codings automatically when it is highly confident, routing more transactions to manual review during the learning period. Lower the threshold gradually as the model's accuracy on that client's specific transaction population is confirmed. Starting at a permissive threshold on month one means committing incorrect codings at scale, which is far more expensive to unwind than a heavier review queue in the first quarter.
10. Leaving unresolved exceptions in the queue indefinitely
What it is: Transactions that cannot be auto-coded, matched, or resolved sitting in the exceptions queue for weeks or months without action.
Why it happens: Exceptions are the hard cases. Deferred work accumulates when there is no escalation rule and no deadline attached to queue items.
How to fix it: Institute a weekly exceptions review discipline and an escalation rule: any transaction that has been in the queue for more than 14 days without action is escalated to a senior reviewer or the client for clarification. Unresolved exceptions are not a neutral state — they create phantom reconciliation (books that appear balanced but are not), and they accumulate directly into BAS errors at quarter-end. A short weekly review is orders of magnitude cheaper than cleaning up a populated exceptions backlog at BAS time.
FAQ
What is the most common GST coding error in Australian bank reconciliation?
Coding bank fees as N-T (not reportable) instead of INP (input-taxed) is among the most frequent. Bank charges sit within the GST system as input-taxed financial supplies, which makes them different from transactions that are simply outside the system. The distinction matters for BAS accuracy and ATO audit resilience.
How often should Australian bookkeepers run bank reconciliation?
Monthly is the minimum standard for most clients. Fortnightly is better practice, particularly for clients with high transaction volumes or complex GST positions. Quarterly reconciliation — timed to coincide with BAS lodgement — is the pattern most likely to produce BAS errors, because the backlog of unreviewed transactions is too large to catch subtle issues in a time-pressured sprint.
What does phantom reconciliation mean?
Phantom reconciliation describes books that appear to balance but are reconciled against incomplete data — an imported statement with gaps, unresolved exceptions excluded from the calculation, or a closing balance that does not match the actual bank statement. The accounts show zero difference, but the underlying data is not complete. It is difficult to detect unless you verify the imported data is complete before starting.
Can automation eliminate bank reconciliation mistakes?
Automation eliminates the most common manual errors — inconsistent coding, missed transactions, incorrect GST types on known vendors — but it introduces a different failure mode: trusting auto-coded transactions without verifying the underlying model's accuracy. The practices that get the most out of automation are the ones that pair auto-coding with systematic review: spot-checks on auto-coded populations, accuracy tracking separate from auto-code rate, and conservative thresholds for new clients.
Why does the ATO cross-check W1 against STP data?
Under STP Phase 2, employers report salary, wages, and tax withholding to the ATO each payroll cycle. The W1 field on the BAS reports the same figure for the quarter. The ATO's data systems compare them automatically. A mismatch between what was reported via STP and what appears on the BAS is flagged for review. This is not a new compliance risk — it is a predictable one that a W1/STP cross-check in your pre-lodgement process eliminates entirely.
These mistakes are common not because practices are careless, but because bank reconciliation at scale creates hundreds of small decision points each month and most practices lack the systematic checks to catch errors before they compound.
See how Reconlink prevents these errors — from import completeness checks and INP coding rules through to per-client confidence thresholds and exceptions escalation — or book a demo to walk through your current workflow.