Most BAS errors do not begin with a big mistake. They begin with a small GST code change that felt harmless at the time. A transaction gets re-coded, a default tax rate gets adjusted, a bank rule gets updated. Nothing looks broken, reconciliation still balances, the BAS still runs. Then at quarter end the GST payable does not feel right, and you cannot point to a single error to explain it. This is what accountants are describing when they search "why does my BAS keep changing." It is not one wrong entry. It is drift, where the tax treatment of similar transactions slowly shifts across the period, so the same kind of purchase is coded GST on purchases in July, GST-free in August, and split in September. Each entry made sense on its own. Together they pull the BAS out of shape.
Why the same transaction gets coded three ways in one quarter
The important word here is changing, because this is not about a code being wrong, it is about a code being inconsistent across time. The most common cause is a default that moves mid-quarter. Xero applies tax rates from account codes and bank rules, so if someone edits a default rate or updates a rule in August, every transaction after that point behaves differently from the identical ones before it, with no warning that the goalposts shifted. Unreconcile-and-redo activity does the same thing at the single-transaction level: adjusting an entry after reconciliation can quietly change its GST treatment, so two transactions that were once coded the same no longer are. Backdated journals and CSV imports that default their own tax rates add more inconsistency into the same period. The result is a file where similar things stopped being treated similarly, which is a very different problem from a file where one thing was wrong from the start.
Why reconciliation cannot see drift
Reconciliation will never flag this, and it is worth understanding why, because it explains how the drift survives all the way to lodgement. Reconciliation confirms that bank movements match ledger entries. It checks amounts, not treatment, and it checks each entry against the bank in isolation, never against the other entries in the period. So it has no concept of consistency. It cannot notice that this month's software subscription was coded differently from last month's identical subscription, because both reconcile perfectly against the bank on their own. The one check that would catch drift, comparing how similar transactions were treated across the quarter, is exactly the check reconciliation does not perform. That is why a file can feel unstable, with GST figures that shift from period to period, while every reconciliation report comes back clean.
How to keep GST treatment consistent across the period
If your BAS figures feel inconsistent from one quarter to the next, the thing to review is not any single number, it is whether the coding stayed consistent over time. Check whether bank rules or default tax rates were changed during the quarter, since a mid-period edit is the usual culprit. Review unreconciled-and-recoded transactions and any backdated journals, because those change treatment after the fact. Look at CSV imports for lines that defaulted to a different rate than the feed would have used. The goal is not just to find one wrong code, it is to make sure the same transaction type is treated the same way across the whole period. GST errors rarely start at lodgement. They start earlier, when small coding changes accumulate without anyone comparing the start of the quarter to the end. Keep the treatment consistent at the transaction level and the BAS becomes predictable instead of a quarterly surprise.
