The Trial Balance doesn't agree with the ledger
You drill into the account, total the journal lines, and get a different number from the one printed on the Trial Balance. Or an account you know has movement is missing from the report entirely. Or the Trial Balance comes back empty.
All three are the same cause. Your statements do not read journals.
The 30-second check
Ask one question: has anybody run Month End Processing for that month?
Everything you drill into reads journal lines directly and is always current — the Sub Ledger listing, the journal-line listing, and the ad-hoc Profit Loss Report. Your Trial Balance, Profit and Loss and Balance Sheet do not. They read a stored monthly summary, and that summary only exists for a month somebody has closed.
So:
- Is the Trial Balance empty? The months in your range were never closed. That is the answer almost every time — not missing journals.
- Is one account missing while the others look right? Also month-end, and see below: a missing account is a different failure from a wrong one.
- Is the report short by an amount? Something was posted into the month after it was closed. Re-process it.
What actually happened
When somebody runs Month End Processing for a Set of Books and a month, BigLedger reads every journal line dated in that month, groups them by sub-ledger and GL code, posts a closing journal on the last day and an opening journal on the first of the next month, and writes one summary row per account for that month — its opening balance, its closing balance, and its debit and credit totals.
Your statements are one step further away again. A Financial Report snapshot does not read journals at all: it reads those summary rows and stores its own lines. So the statement you print is a photograph of a photograph, and there are two rebuild buttons behind it — PROCESS the month, then REGENERATE the snapshot. Pressing only the first leaves the statements showing the old figures, which looks exactly like the rebuild not working.
Three things about this surprise people, and all three are worth knowing before they happen to you.
An account can be absent from the Trial Balance, not merely wrong. Only accounts with a journal line in the month are candidates for a summary row, and a row whose opening plus debits minus credits comes to exactly zero is dropped before it is written. So the account is not short by an amount — it is not there. Re-processing the month puts it back.
Rebuild forward, in date order. Closing March posts a brought-down journal dated into April, and April’s stored opening balance comes from that journal. Re-process March and that journal is deleted and re-created, which leaves April’s stored opening stale until April is processed too. Skip a month and you carry the gap forward into every month after it.
Back-dated documents are the usual trigger. A supplier invoice that arrives in the post on the 9th, dated the 24th of last month, is perfectly ordinary and lands behind the photograph. So does a corrected transaction date, and a void.
A different mismatch with the same name: Balance Sheet against the aging report
If what disagrees is your receivables or payables control account on the Balance Sheet against the total on the aging report, re-running month-end will not fix it, because the two reports read different things and always have. The Balance Sheet is built from journals. The aging is built from documents.
So a manual journal posted straight at the receivables or payables control account — a write-off, an opening balance correction, an inter-company adjustment, a rounding entry — lands in the Balance Sheet and can never appear in the aging, because there is no document for it to age. The classic shape is a difference of a constant amount, every month, from one date onwards.
That is worth checking before you assume staleness: list the journals that hit the control account and have no document behind them.
When it is not staleness at all
If you have rebuilt, forward and in order, and the two still disagree, stop rebuilding and start looking for a document that never posted.
A document can be FINAL and have no journal. Posting is a queued job, not part of the Finalise you pressed, and it can fail after the button succeeded — usually on a missing default GL code. The Financial Report applet’s Error Checking screen exists for exactly this: Trace Document runs six checks on one document and tells you which step did not happen, and the Stock Flow Report compares inventory value against accounting value per module.
A rebuild never invents a journal. It faithfully re-summarises the journals that exist.
What this page cannot tell you
- There is no partial rebuild of a month. You cannot regenerate one account, one branch or one customer. The unit is the month, per Set of Books.
- How long a rebuild takes on your data. It depends on how many months, how many accounts, and how much was back-dated.
- Whether a figure is right — only whether it is current.
Related documentation
- Financial Report applet — Month End Processing, the snapshots, PROCESS and REGENERATE, and the Error Checking screens.
- Financial Reporting guide — the same close, walked through end to end.
- Chart of Account applet — the fiscal year, its periods and the Set of Books, all of which must exist before a month can be closed.
- Which figures BigLedger stores, and which it works out fresh — the same trade-off in the other four places it appears.