Why Two Screens Show Different Numbers

The commonest question customers ask us is not how to do something. It is “this number is wrong — where did it come from?”, and its close cousins: “balance not tally”, “the report and the ledger differ”, “the aging shows an invoice I already paid”. Almost every time, nothing is broken. Two screens are showing you two honest answers to two slightly different questions, and nothing on either screen tells you which is which.

This page tells you which. Read it once and most of that family of questions answers itself; keep it open the next time two figures will not tally and you have the check in front of you. About fifteen minutes.

The short answer: some figures are worked out now, others were written down earlier

Every number BigLedger shows you is one of two things.

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, and why the obvious alternative is worse

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 backdated 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 a stored figure and a live one can disagree

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

“The report and the ledger don’t agree” — your statements are built on a monthly summary

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 Trial Balance, Profit and Loss and Balance Sheet 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 separate rebuild buttons behind it — PROCESS the month, then REGENERATE the snapshot.

The live side is everything you drill into. The Sub Ledger listing, the journal-line listing and the ad-hoc Profit Loss Report all query journal lines directly and know nothing about the summary. That is why the ledger can show a transaction that the Balance Sheet does not.

Three things about this surprise people, and all three are worth knowing before they happen to you.

An account can be missing from the Trial Balance entirely, 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 absent. Re-processing the month puts it back.

Nothing runs month-end for you. There is no scheduled job and no job processor for it anywhere in the platform; it is a button somebody presses. It shows in the fleet: of the 90 live tenants, 25 hold any month-end summary at all, and only 16 hold one for 2026. If your Trial Balance is empty, the overwhelmingly likely reason is that the months in the range were never closed — not that the journals are missing.

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.

“The aging shows an invoice I already paid” — the aging history is taken at 01:00 on the 1st

Every document that owes or is owed money carries its own running balance: what it was raised for, what has been knocked off against it, and the remainder. That balance is live — it is rewritten in the same instant you create or void a settlement, before the screen comes back. The “as of today” reports — Outstanding Document, Aging, Statement of Account — read it. They are never stale.

The historical aging is a different animal. A scheduled job runs at 01:00 on the first of each month, takes every document that still has a balance, and writes one row per document stamped with the last day of the month that just ended. That is the row the historical aging reports read. Two details decide almost every complaint about them:

• A document already settled when the job runs gets no row at all for that month — the job only photographs documents with a balance left.
• A row, once written, is never corrected by the monthly job. It will not overwrite what is already there for that document and that month-end.

Put those together and the commonest symptom explains itself. You received a customer’s payment in March, but you keyed it on the 4th of April and backdated it. At 01:00 on 1 April the invoice was still open, so the March row says outstanding — and it will say outstanding for ever unless somebody rebuilds that month. Meanwhile the document itself, and every “as of today” report, correctly shows it settled. Neither screen is wrong. They were asked different questions.

The same screen will even switch engines under you without saying so: ask the aging summary for the current month and it computes live from the documents; ask it for any earlier month and it reads the snapshot.

Rebuilding a past month is not a self-service button. Some correction paths mend the history and some do not: creating settlements in bulk triggers a rebuild of the affected months, while correcting or voiding a single settlement updates the document and leaves the history alone. If a past month still reads wrong after you have fixed the underlying document, that is the case to raise — see When they genuinely do not tally, below.

“The reconciliation tallied last month and now it doesn’t” — one side re-derives itself, the other never moves

A reconciliation session stores four balances, and they behave in opposite ways. Knowing which is which ends most bank-reconciliation questions on the spot.

Your cashbook’s opening and closing balances are worked out by BigLedger, and they re-derive themselves. They are computed when you create the session — opening is everything before the start date, closing is opening plus the period’s active, non-voided cashbook lines — and there is a Refresh calculated balance button that recomputes them on demand. They also recompute without being asked: database triggers on the cashbook line, on the document header and on the cash document header fire whenever a cashbook line is inserted, changed or deleted, or its document is voided, and rewrite the cashbook balances of every active reconciliation for that cashbook. Not just the current one — a March session you finished weeks ago too.

The bank statement’s opening and closing balances are what you typed off the bank’s paper, and nothing in the platform ever writes them. No job, no trigger, no recalculation. They are the one figure on the screen that is purely yours.

So the symptom the desk hears as “it was tallied and now it isn’t”, or “it reverts back”, is the design working. Somebody keyed a receipt in April and dated it 24 March. The trigger fired, your March cashbook closing balance moved, the bank’s did not — because the bank’s statement did not change — and a variance you had cleared is open again. The reconciliation is now telling you the truth: your books and the bank no longer agree for March, and they did not agree before either; you just could not see it. The fix is to account for the new line, not to hunt the difference among lines you already matched.

Two related stored figures on the same screen. Each cashbook line carries an open amount — how much of it is still unmatched — and that is a stored remainder that each match decrements, not something recomputed from the links. And while a line is matched, the source voucher’s amount cannot be edited; but it can be voided, and a voided line drops out of the balance afterwards, which is why a matched line can simply vanish.

“The order says 18 still to come and I invoiced them all” — an order’s balance is a row, not a sum

When a sales order reaches FINAL, a job processor writes one row per order line per downstream document type, holding the quantity still to come. The invoice’s KO For tab reads that row. So does the delivery note — a different row, for its own document type, which is why the delivery note offers you the full 40 after the invoice has already taken 22.

The row is rewritten synchronously the moment a knock-off link is saved, and when it reaches zero it is deleted outright rather than left showing zero. Void the invoice or delete the link and the quantity goes back — the row is re-created if it had been deleted. Across the fleet this is the largest of the five: 44 of 90 tenants hold open-queue rows, about 11 million of them, a median of 62,000 per tenant.

This number is not merely informational. Available stock reads it: available is stock on hand, minus the un-invoiced balance of open orders, minus reservations. An order line whose stored balance is stale is holding stock back from other customers, which is what the desk hears as “item not found even though got stock”.

Two ways it goes wrong, both mechanical:

• No row was ever created. The processor writes nothing unless your company holds an enabled Knock Off Configuration row for that source-to-target pair. Without it the order finalises normally, the invoice simply cannot find it, and the outstanding quantity never decrements because there is nothing to decrement. Across the fleet, 50 of 90 tenants hold any knock-off configuration at all.
• The row has not been written yet. It is a secondary job, not part of the Finalise you just pressed, so a balance missing in the seconds after FINAL is usually a balance that has not arrived. Wait and look again. But if it still has not arrived, nothing re-drives it: a watchdog for exactly this case exists in the code and is not registered as a runnable job, so it has never run on any tenant. At that point it is a manual repair, and a support matter.

Several reports do it the other way, computing the balance by subtracting the knock-off links from the ordered quantity. That is why an order report and the stock availability figure can disagree while both are doing arithmetic correctly.

“Last quarter’s margin changed by itself” — the cost on a line is written back, and can be rewritten

This is the subtlest of the five, and the one with the longest reach.

When you finalise a document that moves stock, the chain posts the stock movement first, then works out what that stock cost, then writes the cost back onto the document line. Moving average and FIFO both land there, side by side, so a report can read a column instead of replaying a history. The item’s current cost lives somewhere else entirely — on the ledger chain and the stock balance rows — and it keeps moving with every receipt you take in.

That much is an ordinary snapshot. Here is the part nobody expects: the cost stored on a finalised document line is not final. Post a purchase invoice dated back into a month you have closed, and a replay walks forward through every later movement of that item and rewrites the stored cost on each one’s document line — with no filter for posting status and none for a locked period. Two queues keep that affordable. One replays the moving-average chain forward from the backdated line — fourteen of the 90 live tenants are carrying rows in it, about 470,000 of them. The other is a FIFO dirty list keyed on company and item that keeps only the earliest dirty point, so an item edited fifty times is replayed once rather than fifty times.

So last quarter’s gross margin genuinely can move after the fact, and correctly so — you have just learned what that stock really cost. What does not move is the ledger: no journal is reposted by either replay path. In fact no sales document ever posts a cost-of-sales journal at all. Cost of sales is a month-end computation — opening stock plus purchases minus closing stock — and the closing stock is valued from whichever cost column your company’s Inventory Closing Base On names, defaulting to moving average.

Follow that through and you have the sequence that produces the question:

1. A backdated purchase lands.
2. The stored cost on last quarter’s sales lines is rewritten by the replay. Your sales and margin reports, which read those columns, change.
3. The general ledger does not move, because no journal was posted.
4. The two only come back together when somebody re-runs month-end for the affected months, which deletes the old cost-of-sales journal and posts a new one.

“The margin report and the P&L don’t agree” is, nine times in ten, exactly this, with step 4 not yet done.

How to tell in under a minute which one you are looking at

You do not need to know the plumbing. 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: ask for the current month and you get a live calculation, ask for any earlier month and you get the stored one.

3. Drill in, and add it up. The decisive test, and it takes about thirty seconds. Open the detail behind the figure — the journal lines behind the account, the documents behind the customer’s balance, the cashbook lines behind the reconciliation — and total them. 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. That tells you which one is stale without knowing anything about how it works.

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 — it is what that sale actually cost you, and it is 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 cashbook 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.

When they genuinely do not tally — the check, in order

Work through these in sequence. Most cases stop at step 3.

1. Write down both numbers, both screen names, and the date you are asking about. Half of all “not tally” cases are two screens filtered differently — a different company, a different branch, a different Set of Books, a date range that is inclusive on one side and exclusive on the other. Check the filters match before you check anything else.
2. Decide which of the pair is stored and which is live, using the three questions above. Name them out loud. You cannot fix a difference until you know which side is meant to move.
3. Ask whether anything changed after the stored one was taken. A document dated into a closed period, a void, a settlement keyed late, a corrected transaction date, a backdated purchase. If yes, that is your answer and the difference is expected.
4. Rebuild the stored one, forward in date order. Re-run Month End Processing for the earliest affected month and then every month after it, then REGENERATE any Financial Report snapshot covering them. Press Refresh calculated balance on an affected reconciliation. Never rebuild a later month before an earlier one — the later month takes its opening balance from the earlier one’s close.
5. Read both numbers again. If they now agree, you are done, and the lesson is that the rebuild is part of the correction, not an optional extra.
6. If they still disagree, it is not staleness — stop rebuilding and start looking for a document that did not post. A document can be FINAL and have no journal: the 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 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.

When it is a support matter. Three signatures, and each is worth reporting with the same words used here: a stored figure that does not move after a rebuild; a past aging month that still reads wrong after the underlying document was corrected; or a figure whose detail and headline disagree with no backdated change to explain it. Raise it on the issue tracker with the two screens, the two numbers, the company and the month. If the answer is a rebuild that only BigLedger can run, that is the “data fix” customers ask for by name, and naming the month makes it a great deal faster.

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. Establish which side is stored before spending an afternoon on it.
• Rebuilding months out of order. Regenerating a later month before an earlier one carries the earlier error forward and makes the total worse, not better. Earliest first, then forward.
• Re-processing month-end and not regenerating the snapshots. Two rebuild buttons, two steps. The statements will keep showing the old figures until the second one is pressed.
• 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. Check the historical months exist at all before trusting the trend.
• Assuming the cost on an old document is fixed. A backdated purchase rewrites it, and the ledger does not follow until month-end is re-run. If a margin report has moved and the P&L has not, this is why.
• Voiding a document to “reset” a number. A void ripples wider than a rebuild: it removes cashbook 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.

Where this sits in the rest of BigLedger

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 knowing this lets you do. Once you can name which figures are stored, the period close stops being a chore and becomes the act that makes the reports true — which is what makes it safe to lock a period at all. A group that closes in order and locks behind itself can hand an external accountant a Trial Balance that will still say the same thing next week. A group that does not is re-explaining the same difference every month.

When to use the live report rather than the stored one. They are siblings, and picking wrongly is the commonest source of a wasted afternoon. Use the Financial Report snapshot when you need the statutory statements for a closed period, something an auditor will read, or a figure that must not move afterwards. Use the ad-hoc Profit Loss Report — which reads journals directly, with no month-end needed — when you want to see how GS-KV-01 is doing against GS-KV-03 this week, or any question about a month that is not closed yet. The same split runs through the aging screens: “as of today” for collections, the historical months for a trend.

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. And a backdated 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 it pairs with in practice. In practice this page is used alongside two things. The first is the fiscal period lock: rebuild the month, check it, then lock it, so that nothing can land behind the photograph you have just taken. The second is the Financial Report applet’s Error Checking pair — Trace Document and the Stock Flow Report — which answer the question this page cannot, namely whether the underlying document posted at all. Rebuild first, then trace; in that order, because a rebuild is cheap and a document hunt is not.

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. It depends on how many months, how many accounts and how much was backdated. 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; it is an endpoint, which in practice means asking.
• 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, so an order balance that never appeared is a manual repair, not something that heals itself overnight.
• 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.

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 check above, exactly what to press.

The moment that becomes automatic, the whole family of “not tally” questions turns into a two-minute diagnosis instead of an afternoon.

Related documentation

• Financial Report applet — Month End Processing, the snapshots, and the Error Checking screens (Trace Document, Stock Flow Report) that find a document which did not post.
• Financial Accounting module — month-end in the order the system expects, and where each balance in the module comes from.
• Financial Reporting guide — the same close, walked through end to end for the running example.
• Bank Reconciliation applet and the Bank Reconciliation guide — the four balances, matching, and the reports that show the variance.
• Debtor Report applet and Creditor Report applet — which of their reports read live document balances and which read the aging history.
• Costing internals — the moving-average formula as coded, the FIFO register, and why no document posts cost of goods sold.
• Partial delivery workflow — the order balance in use, and the Knock Off Configuration row it depends on.
• Setting up a group — why the controls that actually stop bad data sit at the period close rather than at the counter.