Which figures BigLedger stores, and which it works out fresh

If you came here from a symptom, you already have the fix. This page is the reason behind it — read it once and most of the “not tally” family stops being a mystery.

Two kinds of number

A live figure is worked out at the moment you open the screen, from the rows underneath it. Open a customer’s outstanding documents and the platform adds up what that customer owes right now, from the documents themselves. If somebody keys a receipt while you are looking, refresh and the number moves.

A stored figure was worked out once, at a moment in the past, and written into a row of its own. Your Balance Sheet for March is a stored figure. Nobody adds up ten years of journal lines when you open it — they were added up when somebody closed March, and what you are reading is the result of that.

Neither is more correct than the other. They answer different questions. The live one answers what is true now. The stored one answers what did we say was true then — which is the whole point of a set of accounts, and the reason your accountant is allowed to sign them.

The two disagree whenever something has changed since the photograph was taken. A supplier invoice arrives in the post on the 9th, dated the 24th of last month. A branch keyed a sale to the wrong date and you fixed it. Somebody voided a transfer from the middle of the month. All perfectly ordinary, and all of them move the live side while the stored side stays exactly where it was — until it is rebuilt.

You already rely on this, and you would object if it stopped

You are SST-registered at 6%. Next year the rate changes. Every invoice you raised this year must keep showing 6%, and it does: a document line copies the tax code’s rate when the line is saved, so changing the rate tomorrow never rewrites yesterday. Same with the exchange rate on a purchase from a regional distributor — the document keeps the rate it was raised at, not today’s.

Nobody files a support ticket about that, because the behaviour is obviously right. The five cases below are the same idea applied to bigger numbers, and they only feel wrong because nothing on the screen says this was taken on 1 April at one in the morning.

Why it is built this way

Across the 90 live tenants measured on 2026-09-16, the ones that post journals hold a median of 120,000 journal lines each, and the largest holds 4.2 million. A Trial Balance worked out live would sum every one of them, every time anybody opened it, on the last day of the month when everyone opens it at once. That is not a report, it is an outage.

The alternative — recompute everything on every write — is worse in the other direction. A supplier invoice back-dated into a closed month would have to recompute every period after it, synchronously, while you watch a spinner, locking the ledger for everyone else in the group.

So the platform chose a third thing: reports read cheap stored figures, rebuilds are a deliberate act, and the queue absorbs the expensive replays. It is the same decision you can see everywhere else in the product — the counter never pays for the reporting. Finalise a cash bill and the till is free again immediately, while a primary job processor fans out to the secondaries that post the journal, move the stock, work out the cost and file the e-Invoice. The price of that design is exactly the thing this page exists to explain: for a while, two screens can disagree, and both are right.

    flowchart LR
  DOCS["Your documents and journals<br/>the rows underneath everything"]
  DOCS -->|"worked out when you open the screen"| LIVE["LIVE<br/>Sub Ledger listing · ad-hoc Profit Loss Report<br/>a customer's outstanding documents<br/>this month's aging · stock on hand"]
  DOCS -->|"worked out once, when someone<br/>closed a month, ran a job,<br/>created a session or finalised a document"| SNAP["STORED<br/>month-end summary → Trial Balance, Profit and Loss, Balance Sheet<br/>historical aging · a reconciliation's balances<br/>an order's outstanding quantity · the cost on a line"]
  SNAP -.->|"only a rebuild moves it"| SNAP

The five places it happens

Each is a different subsystem, in a different module, built by different people at different times. What they share is the trade-off: store the answer, rebuild it on purpose.

Where	What is stored	When it was taken	What is live instead
Your financial statements	One summary row per account per month, holding that month’s opening, closing, debit and credit	Only when somebody runs Month End Processing for that Set of Books and that month. Nothing runs it for you	The Sub Ledger listing, the journal-line listing and the ad-hoc Profit Loss Report, all read straight from journal lines
Debtor and creditor aging, for a past month	One row per document per month-end, holding what was open, what had been knocked off, and the balance	01:00 on the 1st of each month, by a scheduled job, stamped with the last day of the month just ended	“As of today” Outstanding Document, Aging and Statement of Account, read from each document’s own balance
A bank reconciliation	Four balances: your cash book’s opening and closing, and the bank statement’s opening and closing	The cash book pair when the session was created — and again, by itself, every time a cash book line in that window changes. The bank pair when you typed it off the statement	The matched and unmatched sums underneath, recomputed for every report run
A sales order’s outstanding quantity	One row per order line per downstream document type, holding the quantity still to come	When the order reaches FINAL, then rewritten the moment each knock-off is saved	Several reports instead subtract the knock-off links from the ordered quantity
The cost on a document line	Moving-average and FIFO cost and amount, per line	After the document’s stock movement posts — and rewritten again if anything back-dated lands in front of it	The item’s current cost, which moves with every receipt

Each has its own page, with the check and the fix: the aging · the reconciliation · the statements · the order quantity · the cost and the margin.

How to tell which one you are looking at

Three questions settle it, and any one of them is usually enough.

1. Did somebody have to make this appear? If a person pressed Create, PROCESS, REGENERATE or Refresh to bring the figure into existence, it is stored, and it is as old as the last time somebody pressed it. If it appeared simply because you opened a screen, it is live. Month-end summaries, Financial Report snapshots and reconciliation sessions all have a created or updated date on their own record — that date is the closest thing the product gives you to when this photograph was taken.

2. Does it say “historical”, “as at”, or name a past month? Anything reporting a position at a past month-end is reading a snapshot. Anything reporting “as of today”, or any listing you can drill into, is live. On the aging screens this is the exact dividing line.

3. Drill in, and add it up. The decisive test. Open the detail behind the figure and total it. If the detail agrees with the headline, you are looking at a live figure or a freshly rebuilt one. If the detail is larger than the headline, the headline is a snapshot taken before the extra rows existed.

Which number is right for what

The temptation, once you know one of the two is older, is to call it broken. It is not. Each is authoritative for something, and the something is different.

The cost stored on a document line is the right cost for that document — what that sale actually cost you, and what your margin on that sale should be measured against. It is the wrong number for what does this item cost me today; for that, read the item’s current cost from stock balance.
A document’s own balance is authoritative for what does this customer owe me now. The historical aging is authoritative for what did the position look like at the end of March — and only if a photograph was actually taken that month.
The journals are authoritative for what is this account’s balance. The month-end summary is authoritative for what did we report for March, which is a different and equally legitimate question, and the one an auditor is asking.
Your bank’s statement is authoritative for the bank side of a reconciliation. BigLedger is authoritative for the cash book side. The variance between them is not an error to be made to disappear; it is the output of the exercise.
The open-queue row is authoritative for availability, because that is what availability actually reads. The knock-off links are authoritative for what was really shipped and billed.

A stored figure being older than a live one is not a defect. A stored figure that will not move after you rebuild it is.

The rebuild, in order

Rebuild forward, earliest month first. A later month takes its opening balance from the earlier month’s close. Regenerating a later month before an earlier one carries the error forward and makes the total worse.
Two buttons, not one. PROCESS the month, then REGENERATE any Financial Report snapshot covering it.
Press Refresh calculated balance on an affected reconciliation.
Then lock the period, so nothing can land behind the photograph you have just taken. That is what makes it safe to hand an external accountant a Trial Balance that will still say the same thing next week.

What a stale figure breaks elsewhere

This is not confined to reporting.

A stale open-queue row affects sales and inventory together: available stock is on hand minus the un-invoiced order balance, so a balance that never decremented quietly refuses other customers goods that are on the shelf.
An unrun month-end breaks the cost-of-sales journal, because the only thing that posts it is the close. Skip a month and gross profit in the ledger is overstated by the whole month’s cost of sales.
A back-dated purchase affects inventory, sales reporting and the general ledger on three different timetables: the stored costs are rewritten by a queued replay, the margin reports follow immediately, and the ledger follows only when the month is re-run.

What has to exist before any of it works

A month cannot be closed until the company has a fiscal year with periods and a Set of Books naming the ledgers to close — both created in Chart of Account, and both prerequisites nothing will prompt you for. An order’s outstanding quantity does not exist until the company holds an enabled Knock Off Configuration row for that pair of document types, in Organization. An aging history does not exist until the monthly job is scheduled on your tenant.

In all three cases the figure is not wrong when the prerequisite is missing — it is simply absent, which looks identical on screen and is a different problem.

What we cannot tell you

Stating a limit is as useful as stating a capability, so here are the ones that bite.

No screen stamps a figure with the moment it was taken. There is no “as at 06:35 this morning” line on any report. The created and updated dates on the month-end record, the snapshot and the reconciliation session are the nearest thing, and they are on the record, not on the report you printed from it.
We cannot tell you which background jobs run on your tenant. Which processors are subscribed is a per-tenant subscription rather than a property of the product, and there is no screen that lists it. That is why this page gives you fleet counts — 21 of 90 tenants schedule the monthly aging job — instead of telling you what yours does. Ask your BigLedger contact for your own tenant’s answer.
We cannot tell you how long a rebuild takes on your data. A month-end run happens while you wait; the costing replay is queued and finishes when it finishes.
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.
Rebuilding a past month’s aging is not a self-service action. No screen in the reporting applets offers it.
Nothing re-drives a knock-off that never ran. The watchdog written for that case is not registered as a runnable job and has never run on any tenant.
A rebuild never invents a journal. If a document never posted, re-processing the month will not create the entry — it will faithfully re-summarise the journals that exist. Find the document first.
This page cannot tell you that a number is wrong. It can only tell you which of the two you are looking at and when it was taken. Whether the underlying figure is right is a question for the documents.

Common mistakes

Treating the difference as an error and hunting for the missing transaction. It is usually not missing. It is present on one side and not yet on the other.
Rebuilding months out of order. Earliest first, then forward.
Re-processing month-end and not regenerating the snapshots. Two buttons, two steps.
Reading a past month’s aging as though it were live. It is a photograph, and on a tenant with no monthly job scheduled it may be a photograph nobody has taken.
Assuming the cost on an old document is fixed. A back-dated purchase rewrites it, and the ledger does not follow until month-end is re-run.
Voiding a document to “reset” a number. A void ripples wider than a rebuild: it removes cash book lines from reconciliations you have already completed, restores order quantities, and moves the item’s average cost if the document moved stock. Correct the document or rebuild the figure; reach for a void last.

What success looks like

Take any figure in front of you and answer three questions in under a minute: is it stored or live, if stored, when was it taken, and what would move it. Then drill into it and total the detail. If the detail matches, the figure is current. If the detail is bigger, you now know exactly why — and, from the symptom page, exactly what to press.