The bank reconciliation is done. The difference is zero. You saved the report, closed the period, and moved on to the next client file.
Then someone pulls up the balance sheet and the GST/HST receivable looks inflated. Or expenses are running 40% higher than last quarter with no obvious reason. Or A/R has climbed even though the client swears collections are on track.
The reconciliation is clean. The books are not.
I spent three hours once tracing a persistent balance sheet discrepancy on a retail client file before realizing the problem had nothing to do with the current period. A prior-period opening balance had been contaminated when someone edited a reconciled transaction after close. The bank rec still showed zero difference. Every report downstream was wrong.
That experience changed how I think about what reconciliation actually proves. By the end of this article, you’ll understand exactly why a clean bank reconciliation can coexist with material bookkeeping errors, and which accounts and records to investigate when the numbers still don’t add up.
What a bank reconciliation actually confirms
A bank reconciliation checks one specific relationship: whether the accounting record for a given bank account can be tied back to the bank’s own statement after accounting for timing differences and necessary adjustments.
Cheques that haven’t cleared yet, deposits in transit, bank fees not yet recorded. Those are the kinds of items that create legitimate, temporary differences. When you resolve them and the ending balance matches, the reconciliation is complete.
That’s useful. It confirms that cash activity in that one account has been accounted for.
It does not confirm that every transaction was posted to the right account. It doesn’t verify that GST/HST was coded correctly, that A/R reflects reality, that journal entries make sense, or that any other balance sheet account is accurate. The reconciliation’s scope is narrow by design. If you’ve worked through common bank reconciliation errors that delay tax filing, you already know the bank-side and book-side distinction matters. This article picks up where that one stops.
7 problems to check when the books still don’t look right
This is the one that burns time. Current-period bank activity can reconcile perfectly while an incorrect opening balance sits quietly on the balance sheet, throwing off retained earnings, owner’s equity, or specific asset and liability accounts.
It happens during file migrations, software conversions, new client onboarding, or when someone posts an opening balance entry during setup and never revisits it. It also happens when a reconciled transaction from a prior period gets edited or deleted after close. The audit log will show the change, but the reconciliation report from the prior month won’t update itself to warn you.
If the beginning balance doesn’t match last month’s ending balance, stop. Check the audit log for post-close edits before doing anything else. Recreate the prior reconciliation if you need to, and inspect what changed.
The bank account reconciles because the dollar amount is correct. The problem is where it landed in the general ledger.
A capital equipment purchase coded as an office expense. Loan principal payments lumped together with interest. A personal withdrawal recorded as a business expense. A vendor refund coded to the wrong revenue account. These errors don’t affect the bank balance at all. They distort the income statement, the balance sheet, or both.
This is why transaction categorization for accurate bookkeeping exists as its own discipline. The bank rec won’t catch a $12,000 asset recorded as an expense. Your chart of accounts has to be structured well enough that the error becomes visible during review, and someone has to actually review it.
A bank-feed import pulls in a transaction that was already entered manually. Now both exist in the ledger. The bank reconciliation might still work if only one copy was marked as cleared, but the duplicate inflates expense totals, distorts vendor balances, or creates phantom payables.
The reverse happens too. A transaction gets deleted or reversed without anyone noticing. Or a bank charge, interest payment, or refund simply never gets recorded.
The weird fix that practitioners actually use: search by amount first. If the same dollar figure appears as both a manual entry and a feed import, remove one source and rerun the reconciliation. If a round-number discrepancy shows up, check for a missing deposit, fee, or transfer before assuming a data entry problem.
A transaction can be categorized to the right expense account and still carry the wrong tax code. That means the expense is correct on the income statement, the bank reconciliation works, and the GST/HST balance is wrong.
Incorrect tax treatment shows up in several ways: a zero-rated supply coded as taxable, an exempt purchase with an ITC claimed, a meal expense with the full GST/HST recovered instead of the allowable portion, or a transaction with no tax code applied at all.
CRA’s guidance is clear that GST/HST registrants need records sufficient to calculate tax payable or collectible and to support ITC claims. Invoices and receipts are the primary supporting documents. If the tax code on a transaction doesn’t match the underlying documentation, the ITC may not be supportable. For a deeper look at what Canadian businesses need to know about ITCs, we’ve covered that separately.
This problem is invisible to the bank reconciliation. It only surfaces when someone reviews the GST/HST accounts or prepares the return.
Here’s the conceptual distinction that matters most in this article: the bank tells you what happened to cash. It doesn’t tell you whether your subledgers accurately reflect who owes the business money or whom the business owes.
Unapplied customer payments inflate A/R. Duplicate supplier bills inflate A/P. Credit notes that were never applied sit as open items indefinitely. Stale receivables that should have been written off months ago make the balance sheet look healthier than it is.
None of these problems will show up during a bank reconciliation. The cash moved. The subledger just doesn’t reflect it correctly.
Accruals, prepaid expense amortization, depreciation, loan adjustments, year-end entries, reversing entries. These don’t flow through the bank account at all, so the reconciliation has no opinion about them.
A depreciation entry posted to the wrong asset class. An accrual that was set up but never reversed. A loan adjustment that double-counted interest. A year-end entry from the prior accountant that nobody reviewed.
These entries can materially change the financial statements without touching cash. If you’re pulling a trial balance and the numbers look strange even though debits equal credits, manual journals are one of the first places to look. A trial balance can balance while containing errors, because equal-and-opposite mistakes, compensating entries, or misclassifications don’t break the debit-credit relationship.
The bank account is one line on the balance sheet. Depending on the client, you might also need to review credit cards, loans, payroll liabilities, GST/HST accounts, fixed assets, prepaid expenses, and shareholder or director loan accounts.
Each of these can carry errors that a bank reconciliation will never surface. The appropriate review depends on the client’s books, transaction volume, reporting requirements, and accounting policies. But the principle holds: if the only account you’ve reconciled is the bank account, you’ve verified one piece of a much larger picture.
Diagnostic table
| If you notice this | Check first |
|---|---|
| Bank reconciles but cash looks unusual | Opening balance, transfers, duplicate or missing entries |
| Profit looks unusually high or low | Expense categorization, accruals, missing expenses |
| GST/HST balance looks wrong | Tax codes, transaction treatment, supporting records |
| A/R doesn’t match expectations | Customer invoices, payments, credits, unapplied receipts |
| A/P looks inflated | Supplier bills, duplicate bills, payments, credits |
| Balance sheet contains unexplained balances | Opening balances, journal entries, unreconciled accounts |
| Trial balance agrees but numbers still look wrong | Account classification, compensating errors, period-end entries |
Bank reconciliation vs. broader bookkeeping review
| Bank reconciliation | Broader bookkeeping review |
|---|---|
| Focuses on bank and cash activity | Looks across the accounting records |
| Identifies differences between bank and books | Looks for classification, omission, duplication, and adjustment issues |
| Addresses timing differences | Reviews whether balances make sense in context |
| Helps verify cash records | Helps assess broader financial record accuracy |
Don’t fix a difference by making the numbers match
⚠️
This deserves its own callout. When a balance doesn’t look right, the temptation is to post an adjusting entry that forces the number into line. That makes the report look clean. It also buries the actual problem.
Six months later, when CRA requests supporting documentation or the year-end accountant can’t trace the entry, nobody remembers why the adjustment was made. CRA’s recordkeeping guidance emphasizes maintaining organized records and supporting documents, including working papers that explain transactions. An unexplained adjustment with no supporting documentation is the opposite of that.
Identify the source. Document the issue. Determine the right correction. Record it properly. Keep the backup. If a month-end close checklist is part of your workflow, this review step belongs on it.
A practical example
An accounting firm completes the monthly bank reconciliation for a retail client. Zero difference. Clean report.
But the balance sheet shows GST/HST receivable has grown by $4,200 over three months despite consistent sales. A/R has also increased even though the client reports no change in collection patterns.
The investigation reveals three separate issues. First, several expense transactions were imported with the correct dollar amount but an incorrect tax code, claiming ITCs on exempt purchases. Second, two customer payments were received and deposited but never applied to the corresponding invoices in A/R, so the invoices remained open. Third, a bank feed import duplicated three manual entries from the prior month; one copy was cleared during reconciliation, and the duplicates sat uncategorized.
The bank reconciliation caught none of this. Each problem required a different review: the GST/HST accounts, the A/R subledger, and a duplicate transaction scan.
When the reconciliation is clean but the books aren’t
LedgerNext helps accounting firms standardize transaction processing and surface categorization exceptions across client files, so problems like misapplied tax codes and duplicate imports get flagged before they compound.
Where practitioners disagree
There’s an active debate about whether prior-period lock dates should be enforced rigidly or left flexible for corrections. One side argues that hard lock dates prevent the contaminated-opening-balance problem entirely: if nobody can edit a reconciled transaction after close, the beginning balance stays intact. The other side points out that legitimate corrections sometimes require reopening a prior period, and a rigid lock creates workarounds that are worse than the problem. I land on enforcing lock dates with a documented override process, because the beginning-balance drift I’ve seen from uncontrolled edits causes more damage than the inconvenience of a formal correction workflow.
Frequently asked questions
Does bank reconciliation guarantee accurate bookkeeping?
No. A bank reconciliation confirms that the accounting record for a specific bank account can be tied to the bank statement after accounting for timing differences. It does not verify transaction categorization, GST/HST treatment, subledger accuracy, journal entries, or the accuracy of other balance sheet accounts.
Why can my books be wrong if the bank reconciles?
The reconciliation only checks cash activity against the bank’s records. Errors in account coding, duplicate entries in other accounts, incorrect tax treatment, wrong opening balances, and unreconciled subledgers all survive a clean bank reconciliation because they don’t affect the bank-to-book cash comparison.
What accounts should be reviewed after bank reconciliation?
That depends on the client. Common candidates include credit cards, loans, GST/HST liability and receivable accounts, A/R, A/P, payroll liabilities, fixed assets, and shareholder accounts. The review scope should match the client’s transaction complexity and reporting needs.
Can a trial balance balance even when there are errors?
Yes. A trial balance confirms that total debits equal total credits. Errors that affect both sides equally (compensating errors, misclassifications between accounts of the same type, or transactions posted to the wrong account at the correct amount) won’t break the debit-credit balance.
How do I find bookkeeping errors that reconciliation missed?
Start by reviewing unusual balances: unexpected negatives, dormant accounts with activity, or large unexplained movements. Then check subledgers against supporting documentation. Run duplicate transaction reports. Review manual journal entries. Compare account balances to prior periods and investigate significant variances.
Why doesn’t my GST/HST balance look right after reconciliation?
GST/HST errors typically come from incorrect tax codes on transactions, not from missing or extra cash. A transaction can hit the right expense account at the right dollar amount and still carry the wrong tax treatment. Review the tax codes applied to recent transactions and compare them against the GST/HST record-keeping requirements for supporting documentation.
What should an accounting firm check before finalizing monthly books?
Confirm the bank reconciliation is genuinely complete. Review balance sheet accounts for unusual balances. Check that subledgers (A/R, A/P, payroll, GST/HST) agree with the general ledger. Scan for duplicate transactions and review any manual journal entries posted during the period. Compare key balances to prior months and investigate anything that doesn’t track.
The next problem you’ll hit after cleaning up a file like this is preventing the same errors from recurring next month. That’s a workflow and controls question, not a diagnostic one, and it starts with deciding which review steps belong in your month-end close process versus which ones only need to happen quarterly or at year-end.
Catch the errors reconciliation can’t
LedgerNext standardizes transaction processing and surfaces categorization exceptions across every client file — so tax-code slips, duplicate imports, and subledger drift get flagged before they reach the balance sheet.
