Flux & Variance
General ledger doesn't match the trial balance? Check the export first
In most accounting systems the general ledger and the trial balance are built from the same postings. When they disagree, the books are rarely the problem. The export usually is — and one check, run account by account, tells you which account and by how much.
You pull the general ledger detail for the month, total it up against the trial balance, and it doesn't tie. The instinct is to go hunting through entries. Before you do, it's worth knowing that a trial balance is, mechanically, the ledger summed by account. If both came out of the same system, same entity, same dates, a real disagreement between them is unusual. What's far more common is that the two reports weren't asking the same question.
Why the GL and the TB can differ
In files I've reviewed, nearly every "the GL doesn't match the TB" problem lands in one of three places. The first two are about the report, not the books.
1. What the export pulled
| Cause | What it looks like |
|---|---|
| Date range | The ledger range has to start the day after the opening trial balance date and end on the closing date. A range that starts on the 2nd, or a trial balance run as of the wrong day, leaves a gap no entry can explain |
| Accounting basis | One report run on cash, the other on accrual. Every account touched by an unpaid invoice or bill moves |
| Filters | An account, class, location, or customer filter left on from the last time the report was run. A filtered ledger can't tie — half of each entry is missing |
| Posting status | On platforms with approval workflows or non-posting documents, the ledger export may include pending or non-posting items that the trial balance, correctly, leaves out — or the reverse |
| Period vs. date | Where a platform has accounting periods, an entry dated in one month can be posted to another. A ledger pulled by date and a trial balance pulled by period disagree by exactly those entries |
2. How the export writes amounts and accounts
| Cause | What it looks like |
|---|---|
| Sign convention | Some ledger reports show a single amount signed by the account's normal balance, not by debit and credit. A credit to a payable shows as positive. Summed as if positive meant debit, liabilities, equity and income all go the wrong way |
| Account names | Where there are no account numbers, sub-accounts often print under their short name. Two sub-accounts with the same short name under different parents collapse into one when you total by name |
| Report lines that aren't entries | Beginning-balance rows, account subtotals, and "total with sub-accounts" rows sit in the same columns as real lines. Include one and the account is double-counted |
| Lines with no amount | Some transaction types write a line with a quantity and no dollars. Harmless, but it has to be excluded on purpose, not by accident |
3. A real difference in the books
Less common, and usually specific: a trial balance that isn't straight from the ledger (a consolidation, a top-side adjustment, a file maintained outside the system), or the fiscal year boundary covered below. If both reports come from the same system and you've ruled out the first two groups, this is where to look. But rule them out first. It's the cheaper search by a wide margin.
Tie it out account by account
Comparing totals tells you there's a problem. It doesn't tell you where, and it can miss the problem entirely. Take a ledger export that's missing one complete entry — a bill, both sides of it. The export still balances. The trial balance still balances. Total debits minus total credits is zero in both. Nothing at the total level moves.
Per account, it's obvious. You need three things, all on the same basis and for the same entity:
- The trial balance as of the day before the period starts — the opening balances.
- The general ledger detail for the period, every account, no filters.
- The trial balance as of the last day of the period — the closing balances.
For every account, add the opening balance to the sum of that account's lines in the export and compare it to the closing balance. Every account where they differ is listed with the difference. That list is the answer.
Here's what it looked like on a real export: QuickBooks Online's public sample company, June 30 opening, July and August activity, August 31 closing — with one $2,000 bill deliberately removed from the export. Debits are positive, credits in parentheses.
| Account | Opening | Activity | Closing TB | Difference |
|---|---|---|---|---|
| Checking | 4,625.00 | (2,500.50) | 2,124.50 | — |
| Accounts receivable | 543.00 | 4,738.52 | 5,281.52 | — |
| Design income | — | (2,250.00) | (2,250.00) | — |
| Accounts payable | — | 397.33 | (1,602.67) | 2,000.00 |
| Miscellaneous expense | — | 916.00 | 2,916.00 | (2,000.00) |
Every other account in the file tied. Two accounts off by the same amount in opposite directions is the signature of one complete entry missing from the export. Here, a $2,000 bill: a debit to the expense, a credit to payables.
Reading the pattern
The shape of the differences usually points at the cause before you open a single entry:
| Pattern | Usually means |
|---|---|
| Two accounts, same amount, opposite signs | One entry missing from, or extra in, the export |
| One account off by twice an amount | A line read with the wrong sign |
| Every liability, equity and income account off | A sign convention problem, not a data problem |
| Every income statement account off, first month of the fiscal year | Year-end reset (below) |
| Many accounts off, by amounts tied to unpaid invoices and bills | Cash basis on one report, accrual on the other |
| One account doesn't exist on the other report | A name mismatch or a sub-account collapsed into its parent |
The fiscal year boundary
Many platforms close income statement accounts into retained earnings by calculation, not by a posted entry. So in the first month of a fiscal year, the opening balance for every income statement account is zero, not last month's closing balance — and retained earnings opens with last year's result added, with no ledger line behind it. Run the check without allowing for that and it flags every income statement account plus retained earnings, every year, in the same month. That's a false alarm, and a check that cries wolf every January teaches people to ignore it the one month it's right.
Control totals, when the report prints them
Where the ledger report prints a grand total or a line count, write it down from the report itself and compare the export to it. It catches rows lost between the screen and the file. Where the report doesn't print one, say so and rely on the per-account check. Don't manufacture a "control total" by summing the export you're trying to verify — that only proves the export agrees with itself.
What one QuickBooks Online export taught me
I ran the check above against QuickBooks Online's public sample company, a fictional business anyone can open in a browser. Everything tied in the end, but only after dealing with the export itself. In the export I tested:
- The default ledger's amount column is signed by account type. Credits to payables and income show as positive. Read as debit-positive, dozens of entries stop netting to zero.
- There are no account numbers, and short names repeat. "Plants and Soil" is both an income account and an expense account, under different parents. The trial balance uses full names; the default ledger uses short ones. Match by short name and two accounts become one.
- The customized ledger has look-alike columns. With every optional column switched on, one column holds the line's own account. Two others, with nearly the same name, hold the transaction's main account instead. Pick the wrong one and every line lands on the wrong account.
- Inventory adjustments write a line with no amount next to each real one.
- The ledger prints no report-wide totals, only account subtotals, so there's no independent control total to check against. The per-account check is the only completeness test available.
None of those are errors in the books. Every one of them makes a correct ledger look like it doesn't tie, or can hide a real gap if handled by guesswork. Your platform will have its own list. The per-account check is how you find it.
Why this matters more when software reads the export
A person working from an incomplete export usually notices something feels off. A tool reading it doesn't. Anything that reads a ledger export and summarizes it — a script, a pivot, an agent drafting commentary — can't tell a missing entry from a quiet month. It works with what it's given, and an agent working from an incomplete export gives confident, wrong answers. Run the tie-out before anything downstream reads the file. To watch a review refuse an incomplete export, delete the $2,000 bill in the flux analysis demo. More on that in getting started with agents in month-end close, and on why some accounts can be explained from the detail and others can't.
Most of this surfaces again at flux review. The free flux template flags which balances moved enough to explain. The CloseOps Flux & Variance System ($79) starts from your trial balance instead: confirm each account's classification and it builds the income statement and balance sheet flux statements, then ranks what to investigate.
Related: where this sits in month-end flux, start to finish. Also when the operational report and the GL don't agree, commentary written against a balance that then moved, and what agents can and cannot do in the close.
CloseOps is productivity software and a documented working method. It is not an audit, a review, a compilation, or any other assurance service, and nothing it produces is accounting advice or an opinion on your financial statements. It helps you run a repeatable close and evidence that you ran it. You remain responsible for your accounting, your judgments, and your numbers.
The worked example uses QuickBooks Online's public sample company, a fictional business. No client or employer data appears in this piece.
Found something wrong or missing? Tell me here — anonymous, thirty seconds.