Every save rewrites the line, and the one edit the books refuse — transcript
Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.
This presentation is for whoever corrects finalised documents at GadgetSphere — a wrong reference, a wrong payee, a payment taken on the wrong card. In about ten minutes you will know what each of those saves does to the cash book behind the document, which one will be refused, and which screen performs the refused change anyway.
Step 1 — Know that saving a finalised document is also a posting
After this step you will stop thinking of finalise as the only moment that writes anything. A finalised document can still be edited, and every save of one that has already posted to the cash book re-runs the cash book side. The payment lines are read again, every column on the cash book line is rewritten from the document as it now stands — payee, references, branch, profit centre, description, cheque details — and a payment line that did not exist before gets a brand new cash book line. This is not a queued job you can watch. It happens inside the save.
Reference: Cashbook — Where a cashbook transaction line comes from, column by column
Step 2 — Know why there is never a second set of lines
After this step you will stop worrying about duplicates. The re-synchronisation pairs each payment line with the cash book line it wrote the first time, by identity rather than by amount or by position. An existing pair is updated in place and keeps the same cash book line, which means it also keeps any reconciliation match already sitting on it. Only a genuinely new payment line produces a new cash book line. So editing a finalised receipt five times leaves one cash book line per payment, not six, and your matched work survives every one of those saves.
Reference: Cashbook — Where a cashbook transaction line comes from, column by column
Step 3 — Meet the one edit that is refused
After this step you will recognise the message instead of fighting it. If a save would change the amount on a cash book line, the platform first asks whether that line is still matched in an active bank reconciliation. If it is, the save is rejected outright, and the message names the cash book, the reconciliation and its month so you know exactly which session to open. Nothing is half-written; the whole save fails. That refusal is the platform protecting a reconciliation somebody has already signed off, and it is the correct behaviour even though it arrives as an error.
Reference: Bank Reconciliation — Effect on other documents
Step 4 — Know why an unchanged amount is deliberately left alone
After this step you will edit reconciled documents with confidence. The check only fires when the money actually changes. If the amount is the same as it was, the amount and open-amount columns on the cash book line are not touched at all — not rewritten with the same value, not reset. That is on purpose, because rewriting the open amount would wipe out a partial match. It is what lets you fix a misspelt payee, add a cheque number or correct a remark on a receipt that is fully reconciled, and have the reconciliation stay exactly as you left it.
Reference: Cashbook — Lifecycle and effects
Step 5 — Meet the screen that makes the same change without asking
After this step you will know the gap that matters most on this subject. Correcting a payment method on a finalised bill is done on the Settlement Adjustment screen, and that is the right tool: it keeps the document number, the stock movement and the e-invoice intact. But it reaches the cash book by a different route. It deletes the old cash book lines and writes new ones for the new method, and it never asks the reconciliation question. So the amount change refused by an ordinary save goes through here without a word, and the match on the old line is gone.
Reference: Payment Aggregators and Branch Settlement Methods — Changing the method after the sale
Step 6 — Do it in the right order
After this step you will have a rule that costs nothing. Before changing the settlement on any document that falls in a month you have already reconciled, open that reconciliation session, find the line on the Unreconcile tab and undo the match. Then make the adjustment. Then match the new cash book line against the same bank statement line. Three extra clicks, and the alternative is a month that quietly stops balancing with nothing on the screen to say why. If the period has not been reconciled yet, none of this applies and you can adjust freely.
How the steps fit together
flowchart TD
s1["Step 1 — Know that saving a finalised document is also a posting"]
s2["Step 2 — Know why there is never a second set of lines"]
s3["Step 3 — Meet the one edit that is refused"]
s4["Step 4 — Know why an unchanged amount is deliberately left alone"]
s5["Step 5 — Meet the screen that makes the same change without asking"]
s6["Step 6 — Do it in the right order"]
s1 --> s2
s2 --> s3
s3 --> s4
s4 --> s5
s5 --> s6
Check yourself
Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.
Answer key
- Nothing — the amount did not change, so the amount and open-amount columns are untouched — Cashbook — Where a cashbook transaction line comes from, column by column
- The save is rejected, with a message naming the cash book, the reconciliation and its month — Bank Reconciliation — Effect on other documents
- Each payment line is paired with the cash book line it already wrote, and that line is updated in place — Cashbook — Where a cashbook transaction line comes from, column by column
- Unreconcile that line first, adjust, then match the replacement line — Payment Aggregators and Branch Settlement Methods — Changing the method after the sale
Next: Five ways a cash book line leaves, and only one of them is a void · Back to the series · Play this as a presentation