Why a real ledger should never be unbalanced.
On a true double-entry system that enforces DR = CR at the database level, a trial balance cannot be unbalanced. Every entry checks balanced before it saves. So if your trial balance is off, you are either on a system that allows unbalanced entries (Excel, some legacy software), or you have a posting that bypassed validation (direct database edit, import error, rollback partial), or you are reading the report wrong.
Step zero: confirm what report you are looking at. Some "trial balance" reports include sub-ledger detail and exclude control accounts, which can look unbalanced even when the underlying data is fine. Run the canonical TB by class with closing balances. If it ties, the original report was misconfigured. If it still does not tie, proceed to the eight causes.
Cause one: transposition error.
Posted $12,300 instead of $13,200. Difference is $900, which is divisible by 9. This is the single most common error in manual systems. The trick: any transposition error produces a difference divisible by 9. If your TB is off by $9, 90, 900, 9,000, etc., suspect transposition first.
Hunt: scan recent entries for amounts where the digits could be swapped. Compare books to source documents (bank statement, invoice). Found it; reverse and repost. In Nonari this almost cannot happen because amounts are typed once and pulled from invoice scans, but on Excel-based systems it is the leading cause of unbalanced TBs.
Cause two: one-sided entry.
Recorded the debit but forgot the credit, or vice versa. Common when manually posting in Excel without a journal-entry template. Difference is the amount of the missed leg. Hunt: filter recent entries where the entry has only one line; legitimate journal entries always have at least two. Also check entries with unusually round numbers ($50,000 exactly) which often turn out to be partial postings.
Fix: identify the missing leg, post it as a correcting entry, never delete the original (audit trail). Most modern systems prevent one-sided entries entirely; if your system allows them, you will see this cause monthly until you upgrade.
Cause three: missed entry entirely.
Some transactions made it to the bank but never to the books, or never to either. Common cases: bank charges on the bank statement not posted, FED on cheque issuance, profit on savings, automatic SMS service fees, customer refunds. Difference is the amount, hidden by the fact that there is nothing in your books to compare against.
Hunt: run bank reconciliation. Every line on the statement should match an entry. The unmatched lines on the statement side are the missed entries. Post them, your TB rebalances. This is why bank reconciliation is the first step in trial balance debug, not the last.
Cause four: posted to wrong account.
The TB still balances on totals but a specific account shows wrong. Customer payment of $85,000 posted to Sales instead of Accounts Receivable: TB still balances but AR is overstated by 85,000 and Sales is overstated by 85,000. The TB itself does not flag this; the diagnostic is sub-ledger reconciliation. AR sub-ledger total should equal AR control account; if it does not, hunt the difference.
Hunt: run aged AR or AP, compare to control balance. Any discrepancy means a posting bypassed the sub-ledger or hit the wrong control. Fix with a reclassification entry: DR correct account / CR wrong account. Document why.
Cause five: missed period close adjustment.
Forgot to amortize prepaid rent. Forgot to recognize deferred revenue. Forgot to accrue payroll for the partial month. Each missed adjustment shows as an out-of-balance somewhere: prepaid rent too high, rent expense too low; deferred revenue too high, revenue too low. The trial balance still balances if everything is two-sided, but reports look wrong.
Hunt: run the prepaid and deferred schedules. Compare expected month-end balance to actual GL balance. Differences are missed adjustments. Post the catch-up entries. Within Nonari, scheduled accruals auto-post; the cause becomes nearly extinct. On manual systems, this is a top-three cause of report-time discrepancies.
Cause six: opening balances wrong.
You migrated from a previous system and the opening balances do not tie. The first month TB is off by the sum of opening balance errors. Hunt: re-run the closing TB from the previous system on the migration date. Compare line by line to the opening TB on the new system. Differences are the migration errors. Common: forgot to migrate one bank account, mistyped a customer balance, missed a fixed asset.
Fix: post correcting opening entries with a memo "Migration adjustment, account X." Reconcile until TB ties. Do this in month one or it haunts every month forward. Migrating to Nonari runs an opening-balance verification step that flags any imbalance before you go live.
Cause seven: rounding and currency conversion.
Foreign currency transactions converted at slightly different rates over time can produce small rounding differences./USD invoice posted at 280, payment received at 281; the gain or loss must be booked. If not, a small balance lingers in AR or AP forever. Across many transactions, this accumulates.
Hunt: filter foreign currency accounts. Compare native currency balance to $balance at the closing exchange rate. Differences are unrealized gain/loss to book: DR Unrealized FX Loss / CR AR (or reverse for gain). Post monthly to keep the books clean. Without this discipline, FX accounts drift indefinitely.
Cause eight: software bug or data corruption.
Rare but real. A failed backup, a half-completed import, an aborted transaction can leave orphaned records. The TB shows an imbalance that has no obvious cause. Hunt: run the database integrity check the system provides. Most accounting software has a "verify" or "rebuild" function. If the imbalance persists after rebuild, escalate to the vendor.
On Excel-based systems, this is more common than admitted: a hidden row, a deleted formula, a circular reference. Always cross-foot column totals against row totals. The discrepancy will be obvious. Modern cloud systems like Nonari run integrity checks continuously and the bug version of this cause is essentially zero.
- Difference divisible by 9: transposition.
- Difference matches single transaction: missed entry.
- Wrong account, totals tie: reclass needed.
- Sub-ledger off: control mismatch.
- Foreign currency drift: revaluation missing.