A Correction Is An Entry, Never An Edit

Mostafa Dhouib·10 min read

A Correction Is An Entry, Never An Edit

The short answer. When an administrator fixes a wrong figure by editing it, two things are destroyed at once. The path by which the figure reached its previous value is gone, because an update in place does not keep what it replaced. And the fact that a correction occurred is gone too, because the result looks identical to a figure that was always right. Recorded instead as its own entry, with an amount, an author and a reason, the correction leaves the balance deriving from entries as before, and anyone who later asks why the number moved gets an answer rather than a theory.

A membership platform holds a balance for each member. Contributions go in, charges come out, the balance is what someone sees when they log in.

An administrator notices that a member's balance is wrong. Perhaps a payment was recorded twice, or an amount was keyed with a transposed digit, or a charge was applied to the wrong person.

The fix that presents itself is to correct the balance. Open the record, type the right number, save. One minute of work and the member sees the correct figure.

That minute costs you the integrity of the whole record.

Overwriting removes two different things

It is worth separating what gets lost, because they are distinct losses with distinct consequences.

The derivation is lost. If the balance is stored and editable, it is no longer the sum of the entries beneath it. Someone adding up the contributions and charges will reach a different total from the one displayed, and both numbers now exist with equal authority. There is no way to tell from the data which is right. The usual next step is for somebody to adjust the entries to match the balance, which propagates the problem downwards.

The event is hidden. A corrected figure and a figure that was always correct are indistinguishable afterwards. So the question "has this account been adjusted" has no answer, which matters more than it first appears. Corrections cluster. The same import bug, the same misconfigured charge, the same confusing form produces dozens of them. If each one is invisible, the pattern is invisible, and you fix individual symptoms indefinitely without ever seeing the cause.

There is a third consequence. When a member disputes their balance, the conversation needs a history, and a history with a silent edit in it is worse than none, because it looks complete and is wrong. Somebody will walk a member through a list of transactions that does not add up to the balance on screen, and will have no explanation.

Correcting means adding, not changing

The rule is short. Entries are immutable. A balance is derived by summing entries. Therefore the only way to change a balance is to add an entry.

A correction entry carries the same fields as any other entry plus a few that only corrections need: the amount and direction of the adjustment, the entry or entries it relates to, a reason code, a free-text note, the author, and the time it was recorded. It is written append-only like everything else.

What this gives you:

The balance still derives. Sum the entries including the correction and you get what is displayed. The arithmetic is checkable by anyone, which means the number can be defended.

The correction is visible. It appears in the history with its own line. A member looking at their account sees that an adjustment was made, when, and why. That is nearly always better than a figure silently changing between two visits, which looks to the member like the platform is unreliable.

Attribution survives. The entry names who made it. Not as a punitive measure, but because the question "who authorised this" is asked routinely and should not require searching application logs.

Past balances stay recoverable. Excluding entries after a given point reproduces the account as it stood on any past date. Under the overwrite model the historic balance is gone, which quietly makes every past statement unverifiable.

One practical point. Record what was wrong, not only what the new number is. An entry saying "adjustment of fifty" with no linkage is only slightly better than the edit. The correction should reference the entry or period it relates to, so the two can be read together.

Reversing, rather than patching the difference

There are two shapes a correction can take and they are not interchangeable.

A reversing entry cancels a specific earlier entry by recording its exact opposite, referencing it directly. The original stays, the reversal sits beside it, and the pair nets to nothing. If a replacement is needed, a fresh correct entry is recorded after the reversal.

An adjusting entry records only the difference needed to reach the correct figure.

Reverse and re-enter is the better default, for a reason that is not obvious. A reversal plus a correct entry is readable as a story: this was wrong, it was cancelled, here is what should have been recorded. A net adjustment is not readable at all. A single line of minus thirty tells you the balance moved and nothing about what was wrong, so the next person has to reverse-engineer the intent from the amount.

Reversals also compose correctly. Reversing a duplicate payment leaves the original intact and the history shows one payment plus a cancelled one. An adjustment of the difference leaves two payments on record with an unexplained deduction, so anyone counting payments gets the wrong answer even though the balance is right.

Adjusting entries do have a place, mainly where no single original entry is at fault. Rounding residue, a tolerance write-off, a goodwill credit. In those cases there is nothing to reverse, and the entry stands on its own with its reason.

What you should not build is a delete. The moment entries can be removed, the derivation is only as good as whatever was not deleted, and you are back to a balance you cannot defend.

The reason code is the hard part

Everything above is mechanical. The part that decides whether the record is actually useful in a year is the reason, and it is usually treated as an afterthought.

A short, closed list beats free text alone. Duplicate payment, incorrect amount, applied to wrong account, refund, goodwill, write-off, import error. Short enough that the right option is obvious, specific enough that counting them tells you something. Free text should sit alongside the code, not replace it, because free text cannot be aggregated and nobody reads a thousand notes.

Make the list analysable, then analyse it. The point of codes is to answer the question "what are we correcting most often". If nobody ever runs that query, the codes are decoration. In my experience the top reason is almost always a defect in the system or a confusing interface, not member error, and the correction volume is the only place that shows up.

Watch for the default swallowing everything. Whichever option sits first, or whichever is vaguest, attracts a large share of use because it is never wrong. Require a note on the least specific option and review periodically what people are actually selecting. A reason list that has collapsed to one value is telling you it needs different values.

Do not make the code do policy. It is tempting to attach behaviour to reason codes, so that a refund triggers a payment and a goodwill credit does not. Keep classification separate from effect. Entangle them and the reason gets chosen for the behaviour it causes rather than for being true.

Who can correct, and what they see

Two controls make the difference between a correction mechanism and a back door.

The ability to record a correction should be a specific permission, separate from ordinary administration, and the interface should present the result as an entry. If the screen looks like editing a number, people will think of it as editing a number, and they will be surprised when it appears in the member's history. Above a threshold amount, a second person approving is worth the friction, and that approval belongs in the record so the entry shows both author and approver.

Corrections should also be visible on the member's side by default. The instinct is to hide them as internal noise. The effect of hiding them is that the member's history does not reconcile to their balance, which is the exact failure the design was supposed to prevent.

The honest limit

Append-only corrections make history reconstructable. They do not make it legible on their own. An account with forty entries, several reversals and a couple of adjustments is correct and genuinely hard to read, which is why the view layer matters: group reversed pairs, show the net effect, let someone expand into the detail. Teams that get the ledger right and the presentation wrong end up with support staff who cannot explain a balance they are looking at.

The approach also does nothing about a wrong figure that nobody notices. Corrections fix what is detected. Detection is a separate mechanism, usually reconciliation against an external source such as a payment provider's settlement record, and without it the ledger is internally consistent and externally wrong.

There is a real tension with data deletion obligations as well. A member exercising a right to erasure sits awkwardly against an immutable financial record. Most frameworks allow retention of transaction records for legal and accounting purposes, and the workable pattern is to separate personal identifiers from financial entries so identifiers can be removed while the entries survive. That needs to be designed in, because retrofitting it into a ledger keyed directly on member details is unpleasant.

Finally, the mechanism records corrections. It does not make them rare. If correction volume is high, the ledger is doing its job by telling you so, and the fix is upstream.

FAQ

Why can't an administrator just edit a wrong figure? Because editing destroys two things. The derivation goes, since the stored balance no longer equals the sum of the entries beneath it and both numbers then carry equal authority. And the fact of the correction goes, because an edited figure is indistinguishable from one that was always right. The member's history then fails to reconcile to the balance they are shown.

What should a correction entry contain? The amount and direction, a reference to the entry or period it relates to, a reason code, a free-text note, the author and the time. Append-only, like every other entry. Without the reference it is only marginally better than an edit, because it records that the balance moved without recording what was wrong.

Should I reverse the original entry or just post the difference? Reverse and re-enter by default. A reversal referencing the original, followed by a correct entry, reads as a story: this was wrong, it was cancelled, this is right. A net difference records that the balance moved and nothing about why, so the next person has to infer intent from an amount. Adjustments suit cases with no single faulty original, such as rounding residue or a write-off.

Why do reason codes matter so much? Because correction volume by reason is the only place certain defects become visible. Corrections cluster around a bad import, a misconfigured charge or a confusing form, and if the reason is unrecorded or always the same vague default, you keep fixing symptoms without seeing the cause. Keep the list short and closed, require a note on the vaguest option, and actually query it.

Should corrections be visible to the member? Yes, by default. Hiding them produces exactly the problem the design prevents, a history that does not add up to the displayed balance. A visible adjustment with a date and a reason is easier to explain than a figure that silently changed between two visits, which reads to the member as an unreliable platform.

How does an immutable ledger cope with a request to delete personal data? By separating identity from entries. Retention of transaction records is generally permitted for legal and accounting purposes, so the practical pattern is to keep personal identifiers in a separate store that can be erased while the financial entries survive under a stable internal key. This needs designing up front, because a ledger keyed directly on member details is painful to unpick later.