Why the Errors Are Invisible Until They Are Not
Reconciliation problems have a reliable pattern. They happen quietly during the quarter, they do not trigger any warning in the accounting software, and they stay out of sight until BAS preparation forces everything to line up. At that point, the GST figure in the report does not match the transaction record, something is off in the PAYG, or the bank balance is sitting at a number that should not be possible. The error is real, but the quarter is already over and the original transaction is weeks or months in the past.
The reason this keeps happening is that most reconciliation errors are not wrong in an obvious way. A bank rule that codes every transaction from a particular supplier as a GST-free expense is technically reconciled. The transaction has been matched to a ledger entry, the feed has been cleared, and the software shows no outstanding items. The problem is that the coding is wrong and the GST that should have been claimed was not. That error will not surface in the day-to-day bookkeeping view. It will surface when the GST audit report is run before BAS lodgement and the credits do not add up to what they should.
Duplicate transactions work the same way. When a payment is both imported through the bank feed and entered manually, both entries can end up reconciled against different records in the ledger. The bank account appears clean. The BAS figures are inflated. Nothing flags as outstanding, but the GST on the same transaction has effectively been claimed twice, or income has been counted twice, depending on which side of the ledger the duplicate landed on.
The Specific Errors That Accumulate Fastest
Wrong tax codes are the single most consistent source of BAS-time surprises. When a transaction is coded with the wrong GST treatment, whether a taxable supply coded as GST-free or a non-deductible personal expense coded as a business purchase, the error flows directly into the BAS figures. If that same error pattern repeats across a bank rule applied to dozens of transactions per quarter, the cumulative impact on the GST liability or credits can be significant by the time anyone looks.
Unmatched transactions add a different kind of problem. When a payment from a customer is received in the bank but not matched to the corresponding invoice in the accounting software, the invoice stays open in accounts receivable and the income is counted twice once the bank transaction is eventually coded as revenue on its own. The GST collected on the sale appears in two places. Running an aged receivables report alongside the GST reconciliation before BAS time catches this, but firms that skip that step will miss it.
Manual journal entries that touch GST accounts without being tied to an actual transaction are another consistent source of late-quarter confusion. Journals affect the GST balance in the general ledger but do not appear as bank transactions, so they will not be caught during a standard bank reconciliation. They only become visible when the GST audit report is run and the balance does not reconcile to what the ledger shows.
The Takeaway
Reconciliation errors do not announce themselves. They sit in the books looking like completed work until BAS preparation forces a proper comparison between what was coded and what the transaction record actually shows. The practical fix is to run a short pre-BAS review before every lodgement period rather than relying on the software to flag problems that it has no mechanism to detect. That means checking the bank reconciliation report for unreconciled items, running the GST audit report to confirm the tax codes match the expected treatment, reviewing aged receivables for open invoices against payments that have already cleared, and scanning for duplicate transactions from the current period. Firms that build this into the quarterly workflow stop finding errors at lodgement and start finding them early enough to fix without amending a BAS.
