By Manvinder Sidhu, Co-founder, Ezyiah
Short answer: A reconciliation that balanced yesterday and is out today means something underneath it changed after you closed the file. The usual causes, in order, are: a bank feed that caught up overnight with earlier-dated transactions, duplicates created when the feed overlapped a CSV import, and a backdated edit or journal by someone else in the team. Check them in that order. Related errors, such as wrong GST codes, never move the reconciliation at all. They only show up when the BAS is prepared.
Why can a reconciled balance change overnight?
Reconciliation reflects the current state of the ledger, not the state it was in when you finished. If the number moved, something entered the ledger or something already in it was changed.
- Late feed transactions. A feed reconnects or updates and brings in transactions dated earlier in the period. Xero explains feed timing in About bank feeds.
- Duplicates. If you imported a CSV during a feed gap and the feed later backfills the same days, the same payment can appear twice. See duplicate bank transactions after a CSV import.
- Backdated edits. Someone unreconciles and redoes a line, changes an account, or posts a journal dated in the period. See unreconcile and redo in Xero: what actually happens.
- Rounding and splits. Foreign currency rounding and edited split allocations can shift totals by small amounts.
How do you find what moved?
- Look at recent feed activity for transactions with earlier dates.
- Compare anything imported by CSV against the recovered feed for duplicates.
- Check for unreconcile-and-redo actions and backdated journals in the period.
- Sort or filter account transactions by the date they were edited, not the transaction date, to surface what changed after you closed the file.
Assume something was added, duplicated or edited before you assume you made a mistake.
Why do some reconciliation errors only show up at BAS time?
Reconciliation answers one question: does the ledger match the bank? The BAS asks another: what GST was collected and paid in the period? It pulls from GST codes by reporting period, the same way the ATO looks at it. So these errors pass reconciliation and only appear at the BAS:
- a correctly matched transaction with the wrong GST code
- a duplicate that has been matched
- a director loan coded as an expense
- a transaction dated into the wrong period
This is why the BAS is often the first real check of a quarter's coding. Running a GST report for the period early, rather than on the due date, closes that gap. Many GST errors can be fixed in a later BAS if they're within the ATO's limits. See correcting GST errors.
How Ezyiah helps
Ezyiah is an AI bookkeeper with its own double-entry ledger. It reconciles live bank feeds daily with AI, and the Ezyiah Assistant panel and activity logs show what changed and when. Because the BAS, General Ledger and Trial Balance build from the same books as you go, coding problems show up during the quarter instead of on the due date. Your accountant reviews and approves the BAS before lodgement.
Compare it with Xero, or see how it works for accounting firms.
Frequently asked questions
Why did my Xero reconciliation change when I didn't edit anything?
Usually because the bank feed brought in earlier-dated transactions, or someone else edited or posted something into the period. Check feed activity and recent edits first.
Can a file be fully reconciled and the BAS still be wrong?
Yes. Reconciliation checks amounts against the bank, not GST treatment or period.
How do I stop this happening every quarter?
Review GST coding during the quarter, not only at the end, and agree a cut-off after which nobody edits the period without telling the reviewer.
