Before You Begin 🧰
Before you troubleshoot a changing ledger balance, get your prerequisites clear:
Information: the exact account(s) in question, the date range, and whether you’re looking at GL, AR/AP sub-ledgers, or bank feeds.
Access: permissions to view transaction detail, posting status, audit logs, and period-close controls (if enabled).
Tools: the system’s general ledger report, trial balance report, and the relevant sub-ledger reports (AR ageing, AP ageing).
Data: the list of transactions affecting the account (invoices, bills, payments, journals), including timestamps and any reversals.
Decisions: whether your workflow is cash vs accrual and whether your team allows back-dated entries or late adjustments.
Assumptions: a shared understanding of the difference between a book balance and a bank-cleared balance.
You’ll know you’re ready when you can explain why a bank screen and GL screen might show different numbers without panic-this is the same logic behind “ledger vs bank”comparisons. With that clarity, you can diagnose changes quickly instead of re-running reports repeatedly.
Confirm what “ledger balance” the system is showing (posted vs pending vs adjusted)
Start by identifying the balance type and its rules. Many systems display balances that include items not fully posted, or they show a “report view” balance that differs from the underlying GL. Ask: is this ledger balance strictly posted entries, or does it include drafts, imported bank feed suggestions, or pending approvals? Next, check whether the period is open or closed, because post-close adjustments can move balances retroactively.
Then validate the debit/credit logic so you interpret movement correctly. If someone asks “what does it mean to credit an account?” your answer should match the account type-credits can increase liabilities and equity while decreasing assets. This matters because misinterpretation leads teams to “fix” the wrong thing. If debit/credit logic is a recurring pain, anchor the team on the debit/credit explainer before changing workflows.
Trace the balance back to the transaction list (not the summary number)
Next, open the account’s transaction detail report and reconcile the balance to the line-by-line list. The goal is to move from “the number looks wrong” to “these three transactions explain the difference.” Common culprits: duplicate imports, late-dated entries, unapplied payments, or reversals posted in the wrong period.
If the account is a control account like AR, confirm whether you’re looking at the GL control account or the sub-ledger. This is where “accounts receivable debit or credit?” becomes practical: AR should behave like an asset, but credit notes, write-offs, and unapplied cash can create confusing signs if the underlying logic isn’t consistent.
For teams used to “balancing a checkbook” manually, this step is the modern version: reconcile the list, not just the total. If the list ties, the balance is explainable-even if it’s inconvenient.
Understand how posting rules and normal balances drive what “looks right”
Now evaluate whether posting behaviour is changing the number. Some systems post in batches, some post instantly, and some let users create transactions that sit in draft or approval states. That means the ledger balance can move even when no one “edited the report”-the posting status changed.
This is also where “normal balance” knowledge saves time. Knowing accounts with normal debit balances (like cash, AR, prepaid expenses) helps you spot sign anomalies quickly. If an asset account shows a persistent credit balance, it’s often a classification or posting error, not a business outcome.
Finally, watch for clearing behaviour. A zero balance account used for suspense or clearing should trend back to zero; if it accumulates, it’s a process problem (mis-applied transactions, missing allocations, or incomplete workflows). If your team frequently misreads normal balances, use the account-type reading guide to standardise interpretation.
Reconcile to external reality (bank, AR/AP ageing) before you “correct” anything
Before making changes, reconcile the ledger to an external reference. For cash, reconcile the book number to bank activity (and be explicit about timing). For AR and AP, reconcile the GL control account to sub-ledger ageing. This step prevents “fixes” that create new errors.
Most reconciliation problems come from three sources: timing (transactions exist but haven’t cleared), misclassification (posted to the wrong account), or duplication (imported twice). When you diagnose, make the correction at the transaction level, not as a late “plug” journal entry. That’s how you protect auditability and keep the trial balance sheet example you generate later trustworthy.
If you’re supporting multiple clients or entities, this step should be procedural: a short checklist repeated each close, not a bespoke investigation every time. For a full reconciliation workflow that matches ledger balances to sources,the reconciliation guide is the best next stop.
Finalise the close view and generate a clean trial balance snapshot
Once the transaction list reconciles and you understand posting status, finalise your period view: confirm the period is locked (if your system supports it), confirm adjustments are documented, and then produce a trial balance snapshot. This is where double-entry bookkeeping becomes operational: your debits and credits tie, and your balances are explainable.
If your team builds forecasts, investor packs, or scenario views off accounting actuals, you can now export a stable baseline without chasing moving numbers. Many teams keep the accounting system as the source of truth for actuals, then use a modeling layer for planning and analysis. Model Reef can complement this by turning exported trial balances into structured models with consistent mappings and scenario toggles-without relying on fragile spreadsheet versions.
If you’re working in QuickBooks and want a cleaner path from system data to modelling outputs,the QuickBooks integration workflow can simplify the handoff.
🧠 Tips, Edge Cases & Gotchas
Back-dated entries: If users can post into closed periods, your ledger balance history can “rewrite itself.” Either lock periods or enforce approvals.
AR/AP control account drift: If the GL control account doesn’t match ageing, don’t adjust the control account directly-find the unapplied cash, write-offs, or duplicated transactions.
Draft vs posted confusion: Some screens show draft activity, others don’t. Always confirm the report basis before escalating.
Clearing accounts that never clear: A persistent balance in a zero balance account usually signals an incomplete workflow (missing allocation, missing receipt match).
Bank feed timing: “Book cash” and “bank cleared cash” diverge when transactions are pending. This is normal-don’t force them to match daily.
Small teams and handoffs: In small business accounting, the same person often posts, reconciles, and reports-so process discipline matters more than tool sophistication.
A practical shortcut: standardise a monthly export and review pack (trial balance + AR/AP ageing + bank reconciliation) so investigations become faster. If you need that pack to feed models and scenario analysis, keep the mapping stable and use tooling to reduce repeated manual cleanup.
🧪 Example / Quick Illustration
Input → action → output:
Input: The cash account ledger balance shows $82,000, but the bank portal shows $76,500. AR control account looks high, and month-end is tomorrow.
Action: The finance manager pulls the transaction detail report and finds (1) a large customer payment marked as “received” but not matched to the invoice, (2) a bank charge pending in the feed but not posted, and (3) a back-dated journal entry that posted after yesterday’s report run. They reconcile the cash timing differences, apply the customer payment properly (reducing AR), and re-run the trial balance snapshot.
Output: A clean trial balance that ties, an explainable cash difference (pending items), and updated AR that matches the ageing-ready to move into reporting and forecasting without confusion.
Back