Everything is matched to zero and the bank reconciliation still won't tally

Watch this as a presentation — 1 on this page, slides with narration.

Reading a reconciliation that moved under you

11 slides · about 11 min · The money side: what writes a cash book line, and what takes it away, 4 of 4

“Everything is matched to zero and the bank reconciliation still won’t tally” — this is the design working, not failing: one side of the reconciliation header is worked out again from your cashbook, and the other never moves after the statement was created, so matching more lines cannot close that gap.

You matched everything. The unmatched lists are empty. And the header still shows a difference — or worse, a month you reconciled weeks ago and signed off has quietly opened up again. There is a thirty-second check that proves which side moved.

The 30-second check

Open the session and read two figures. Together they tell you which of three situations you are in. For GadgetSphere that is the March 2026 session on GS-KV-01: the primary bank’s statement closes at RM 47,200, the session’s cash book closing reads RM 47,650, and there is RM 450 to find.

On the Details tab, read the greyed line under the cash book closing. Beneath Cash Book Transaction Closing Balance (the stored figure, RM 47,650) sits a greyed Calculated Cash Book Transaction Closing Balance, worked out from your cash book lines every time you open the session. Write both down. The refresh icon beside the greyed line is disabled and does nothing when clicked.
On the Report tab, generate Report 1 and read its Variance / discrepancy line. It is not the gap between your books and the bank. It is the part of that gap the items Report 1 lists do not explain.

Greyed Calculated line	Report 1 variance	What it means	Next
The same as the stored closing, RM 47,650	RM 0	Pass. The RM 450 is fully explained by lines Report 1 lists — something one side has and the other has not got yet. Nothing has drifted: you have items to name, not an error to find	Name each open line from the table below
Different from the stored closing — RM 47,200, say	RM 450	The cash book moved after the stored figure was worked out, by exactly the difference between the two figures: RM 450, to the cent. The reports start from the stored figure, so they are showing you an older position	What actually happened
The same as the stored closing	Not zero, with both unmatched lists empty	Your matching is not the problem. The bank closing you typed is wrong, the statement in the session is missing rows or holds some twice, or the difference came in with the opening balance	The sum below

The sum, for the third row. On Report 3, add the bank’s opening balance, its matched balance and its unmatched balance. The total should be the closing balance you typed off the bank’s paper — in the guide’s March, RM 41,830 + RM 5,820 + (−RM 450) = RM 47,200. If it is not, check the typed closing against the paper first, then look for a statement uploaded twice or one that stops short. If it is, read the row near the foot of Report 3 headed Difference in opening of cashbook opening balance vs bank statement opening balance: a figure there was carried in from February.

One more clue, whichever row you landed in. If the difference appears from one particular month onwards and every month before it is clean, that is the signature of a document dated backwards into that month. It is almost never a matching error.

What actually happened

Balance on the header	Who writes it	Does it move on its own?
Cash book opening and closing	BigLedger, from your cash book lines	Yes, where the refresh job runs — within about half an hour of a change. Where it does not, they stay as they were at Create
Bank statement opening and closing	You, typed off the bank’s paper	Never. Nothing in the platform writes them

The cash book side is not necessarily frozen. It is computed when you create the session — opening is everything before the start date, closing is opening plus the period’s active, non-voided cash book lines — and stored. After that, whenever a cash book line on that cash book is written, voided or re-dated, BigLedger asks for a refresh, and a background job that runs every 30 minutes works out the stored figures of every active reconciliation for that cash book again, without being asked. Not just the one you have open — a March session you finished weeks ago too.

That job runs only where it is scheduled on your tenant; where it is not, the stored figures stay as they were at Create, and only the greyed Calculated line follows your cash book.

The refresh works the figure out from the cash book lines themselves — which are active, how much they are for, and when they are dated. Matching a line changes none of those, which is why working through the Reconcile tab never shifts the header balance under you. Everything that does shift it is a change to the money itself.

The bank statement side has no such machinery. It is the one figure on that screen that is purely yours.

So: somebody keyed a receipt in April and dated it 24 March. Your March cash book closing balance moved — the greyed Calculated line at once, the stored figure at the next run of the refresh job where it is scheduled. The bank’s did not, because the bank’s statement did not change. 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 in fact they did not agree before either — you just could not see it. The fix is to account for the new line, not to hunt for a difference among the lines you already matched.

Two related traps on the same screen

Each cash book line carries an open amount — how much of it is still unmatched. That is a stored remainder that each match decrements, not something worked out fresh from the links. It is why a half-matched line can look odd after a link is removed.

A matched line can simply vanish, or move. While a line is matched, the source voucher’s amount cannot be edited — the save is refused, and the message names the reconciliation and its month. Three things go around that refusal.

The first is a void. Voiding the source document does not write a reversing cash book line: it marks the line deleted, hands the matched amount back to the bank statement line, and marks the reconciliation link deleted. So the cash book line leaves the session, the bank line reappears on the unmatched list at its full amount, and the calculated balance moves — with nothing on the reconciliation screen to say why. (What a Void Undoes covers a void across every document.)

The second is a settlement adjustment, and it is the one nobody expects, because the document stays FINAL. Correcting the payment method on a finalised bill or voucher — the right way to fix “the customer paid by card and we keyed cash” — deletes the old cash book lines exactly as a void does and writes new ones for the new method. It never asks the question the ordinary edit asks, so a reconciled month can move without anybody being refused anything. If the period is already reconciled, undo the match first, then adjust, then match the replacement line.

The third is an ordinary save of a finalised voucher whose date was corrected, or whose settlement method now names another cash book. Each such save copies the document’s date and the method’s cash book onto the existing cash book line, matched or not; only a change of amount is checked against the match. Correct a deposit’s date from 31 March to 2 April and its line leaves March while its bank line still reads matched — Report 1 then lists the pair among the items matched with another period.

Check the settlement adjustment last, and do not skip it: it is the only cause on this page that leaves the document itself looking untouched. The bill or voucher is still FINAL, still for the same amount, still dated the same day — nothing about the document points at it. The only evidence is the cash book line that is no longer there.

Six other ways a month stays out

The stale stored figure above is the cause when every line is matched. When the check sends you to the open lines instead, each one has a cause, and these are the six that keep a month out after the obvious matches are done.

What you see	Cause	Fix
Everything looks matched, but a bank line still shows a part balance — RM 4,050 open on a RM 4,500 deposit — or a line sits unmatched while its obvious partner is already taken	A match paired a cash book line with the wrong statement line. A match may settle less than the whole of either line, as long as both run the same way and neither holds less than the amount, so a RM 450 receipt matched to a RM 4,500 deposit is accepted and leaves RM 4,050 open	Undo it on the line’s matching screen with Undo Reconcile: the amount goes back onto both lines. The cash book line stays on the Unreconcile tab, now showing a balance — match it again from there
One bank debit on Bank Statement Lines with the bank’s own wording — for GadgetSphere, 31 March, RM 450, quarterly account maintenance — and nothing in the cash book near that date or amount	A charge the bank took and nobody booked. If a shortfall comes back on every card-settlement day instead, the bank pays you net of its fee while your settlement method carries no charge: the cash book line is the payment less the method’s charges, so a method with none records the gross	Post a Payment Voucher with its payment line on GS-KV-01’s settlement method — it writes the cash book line and the journal — then match it. A manual journal moves the ledger and writes no cash book line, so the reconciliation stays exactly where it was. For the card fee, set the charge on the settlement method: documents posted after that arrive net
The reconciliation ties, but GS-KV-01’s closing on Cash Level differs from CASH-PRI-KV01 on the trial balance by one document’s amount — or a bank line matches a document you know is FINAL and the document is not on the Reconcile tab	The cash book line and the journal are written by two separate background jobs after FINAL, and one of them failed. A cash book with no GL code fails the journal and still gets its line; a settlement method with no cash book fails both	Fix the cause first, then run Financial Report > Error Checking > Trace Document on the document. Its Missing Journal and Missing Cashbook checks each show Resolve when they fail, and Resolve writes the missing half. Do not key a second document — you would count it twice. A sales order whose deposit was keyed on its Settlement tab is the exception: its journal is missing today, a known defect BigLedger is tracking, so do not expect Resolve to write it; give the order numbers to BigLedger support
Pairs of identical bank lines — same date, amount and description — one matched and one open, and a Report 1 variance equal to the open copies	The same statement, or two that overlap, went into the session twice. An upload is checked for its own structure, not compared with the files already there, so each copy becomes a statement with lines of its own	Open the second copy from the Upload Statement list and press DELETE on its Details tab, then again to confirm. Its lines leave the session, and any cash book line matched to one of them gets its amount back as open — re-match those against the copy you kept
GS-KV-01 ties, and the account the money went to is out by the same amount — a RM 20,000 move to the secondary bank sits there as a credit nobody can match	The move was keyed as a payment voucher out of one cash book, or as a manual journal, and either writes one side only. Or it was keyed as a Cash Transfer and one half of its posting failed	Record a move between your own accounts as a Cash Transfer: it writes a cash book line in each cash book, and the journal. Void the one-sided voucher, undoing its match first. For a FINAL transfer with a half missing, fix the cause and press FINAL again — it runs only the missing half
A March deposit sits unmatched on your side while the bank shows it on 2 April — or a line you matched in March has left March’s session while its bank line still reads matched	Either ordinary timing, the bank clearing it in another month, or a document dated wrongly and then corrected by an ordinary save (the third trap above)	If the bank simply cleared it later, post nothing: Report 1 carries it as a reconciling item. If the document’s date is wrong, undo the match first, correct the date and save, then match the line in the session its new date falls in

Two of these can clear themselves. Since October 2026 the backend carries a cash book watchdog clock. Where it is scheduled on your tenant in the Scheduler, it re-runs a cash transfer’s missing half, and a voucher’s or bill’s missing cash book line, once they have been waiting more than 20 minutes. A voucher’s missing journal is not one of the things it looks for. Where the clock is not scheduled, every fix in the table is yours to make.

What to do about it

Compare the stored closing with the greyed Calculated line and read the difference again. Where the two differ, wait about half an hour and look again: if the stored figure catches up, the refresh job runs on your tenant; if it never moves, it does not, and the reports keep starting from the figure worked out at Create — If the stored closing is older than your fix (Step 8, second half) gives the ways to carry that difference.
Find what landed in the window. The session listing shows the date each session was created. On the session’s Reconcile tab, search with Created Date from the day after that: every line that comes back was posted after you started, whatever date it carries. Run the same search on the Unreconcile tab for anything already matched.
Account for it — match it to a statement line, or recognise it as a genuine timing difference that belongs in the variance.
Do not re-hunt the matched lines. They were right when you matched them and they are still right.

The variance between your books and the bank is not an error to be made to disappear. It is the output of the exercise.

What the reconciliation leans on, and what leans on it

A reconciliation reads what three other jobs wrote, and what you do with it decides how the next month starts.

What it depends on. The cash book lines come from a background job that runs after a voucher, bill or transfer goes FINAL, into the cash book named on the payment’s settlement method — set up in the Cashbook applet. The statement lines come from the file you upload; the statement balances from what you type. The journal comes from a second, separate job, which is why the reconciliation can tie while the ledger does not (The balances, and the record each one is kept in).
What a finished month lets you do. Once every cash book ties to its bank and to its GL code, lock the month for transactions (LOCK_TXN; LOCK_ALL waits for the year’s audit) in Chart of Account (what each lock refuses). Finalising a document dated into a locked month is then refused with The selected date falls within a locked fiscal period — which stops the back-dated receipt at the heart of this page. April’s session starts from March: its create form offers March’s stored closing, and at Create the opening is worked out again from the lines, so a receipt dated into March after you finished shows up as April’s opening differing from the figure the form offered.
Its siblings, and when to use which. Work a month from statement to audit pack with the Bank Reconciliation guide rather than this page, which starts where that walk-through ended with a difference. The Bank Reconciliation applet page is the reference for every field and report. The second tie — cash book to ledger — is a different check: Cash Level’s closing for GS-KV-01 against CASH-PRI-KV01 on the trial balance (Reviewing a Set of Books, Step 2). A manual journal to the bank’s GL code breaks that tie and leaves this one clean; a Cash Adjustment does the opposite.
What breaks when it is wrong. A month forced to tie with an Unmatched Adjustment posts nothing, so the ledger keeps the difference the reconciliation stops showing; a manual journal posted to make the ledger agree writes no cash book line, so it moves the difference into the cash-book-to-ledger tie. Either way April inherits it — Report 3’s difference in opening balances is no longer zero — and because the refresh works out every active session of the cash book again, a document dated into a signed-off month reopens that month’s figures as well as the current one.
What it pairs with. The reconciliation is worked alongside two other screens: Query Cashbook Transaction in the Cashbook applet, which lists each line with a running balance (it has no total row — the period’s movement is the last row’s balance less the opening row’s), and the journal listing in Ledger And Journal. Trace Document in the Financial Report applet is the bridge when one of them has a document the other has not.

What success looks like

Run this when you think the month is done — or better, hand it to whoever signs it off, so the person who posted the fixes is not the one who checks them. All four, for GadgetSphere’s March on GS-KV-01:

Details: the stored Cash Book Transaction Closing Balance equals the greyed Calculated line — RM 47,200 and RM 47,200 once the charge voucher is in and the refresh has run. Where the refresh is not scheduled, the pack says which of the guide’s three ways your team chose.
Report 1: Variance / discrepancy reads RM 0.
Report 3: every line left in either unmatched section has a name — a cheque not yet presented, a deposit the bank cleared on 2 April — and a month in which it should clear.
The second tie: Cash Level for GS-KV-01, 1 to 31 March, closes at the same figure as CASH-PRI-KV01 on the trial balance at 31 March.

If all four hold, lock March. If the first fails and never moves, nothing is wrong with your matching; if the fourth fails, the reconciliation was never the place to look — go to the cash-book-to-ledger row of the table above.

When it is a support matter

The stored closing agrees with the greyed Calculated line, every visible line is matched to zero, and no line was created after the session. At that point you have exhausted the ordinary explanation, and the residual is worth reporting with the cash book, the period, and the two closing balances written down.

What this page cannot tell you

When the cash book balances were last recomputed. The record carries created and updated dates; the report you printed does not.
Whether every path that lands a line in the window asks for a refresh. BigLedger’s own writes to a cash book line, a void and a change of document date do; a bulk import or a direct correction may reach the data another way.
How to rebuild a bank statement side. There is nothing to rebuild — it is what you typed, and only you can change it.