Bookkeeping lessons · Accounting glossary

Correcting bookkeeping mistakes: reversal versus edit

Editing a draft changes unfinished work. Correcting a posted entry changes accounting history, so the original and the correction must remain traceable.

Key takeaways: distinguish drafts from posted records; identify the exact mistake; choose a permitted correction date; retain the original; and check reports and dependent records after the correction.

Why not simply replace the wrong amount?

A posted amount may already explain a report, a reconciliation or a decision made by someone else.

If a posted expense changes silently from 152.00 to 125.00, an earlier exported report can no longer be reproduced from the apparent history. The new total may be arithmetically correct, but the record no longer explains why it changed. An explicit reversal retains the earlier effect and records the correction as a new event.

This is a traceability principle, not a claim that every accounting framework requires one particular software interface. The appropriate correcting treatment can depend on the error and reporting circumstances. What should not disappear is the evidence of what was recorded, why it was changed and who authorised the change.

When is an ordinary edit appropriate?

A draft can be corrected before posting, provided the changed version is reviewed before it affects the books.

An unposted draft has no ledger effect. Correcting its description or amount is part of preparation. If a reviewer approved an earlier version, the new version needs review again. A saved screen does not establish posting, and a posted screen should not be treated as a draft merely because it still has editable-looking fields.

First establish the document’s status and journal link. This avoids a common mistake: entering another transaction because the original appears absent from a filtered list, or trying to edit a source whose accounting entry has already been recorded.

How does reversal and corrected repost work?

The reversal offsets the original exactly; the corrected posting then records the intended supported amount.

The original and reversal net to zero. The corrected entry leaves a 125.00 expense and a 125.00 cash reduction. All three remain understandable. The visible correction is not an extra expense layered on top of the old one; it is a linked sequence with a defined net effect.

In the broader synthetic exercise, the business received 1,000.00 for a completed service. The incorrect 152.00 payment would have left cash at 848.00. After the reversal and corrected 125.00 posting, cash is 875.00. The correction explains the 27.00 change instead of making the earlier 848.00 balance vanish from history.

Which correction date should be used?

Use a date permitted by the period controls and the applicable reporting decision; discovering a mistake does not automatically authorise backdating.

A cancellation dated today may be appropriate within the software’s normal correction path. An exception using the original date needs the required authority and an open period. If the period has closed or statements have been issued, ask the reviewer what adjustment, reopening or disclosure process is appropriate. A technical permission is not a substitute for that accounting decision.

For PHP Ledger’s foundation, dated reversals default to the cancellation date. The permissioned original-date exception remains constrained by the open period. Reconciliation and open-item activity can impose additional checks. Do not change a date repeatedly until a validation message disappears; understand the protected relationship first.

What should happen to the document identity?

A correction should retain the business identity while distinguishing its posting revisions.

Changing a document number merely to create a corrected copy can make matching and audit work harder. The shared posting foundation supports reversal and corrected repost under the same source-document identity for its supported internal correction path. The original posting and later revision remain linked. This is different from pretending that the original never existed.

The 0.4.0 starter adds invoice and bill correction screens for supported states. Regional e-invoicing amendments remain outside the product, and existing payment, credit, stock and matching dependencies must be respected. Those modules still need their own business rules and evidence. A stable identity is the foundation they will use; it is not proof that every future external numbering or amendment rule has been implemented.

What dependent records need checking?

A correction can affect more than the account you noticed first, so inspect settlements, reconciliations and subsequent activity.

• An allocated open item may need its active allocation explicitly reversed first.
• A bank-reconciled period may reject a backdated accounting change.
• A closed period may require a different permitted correction date.
• An identical retry should return the recorded result rather than repeat the effect.
• A changed payload under the same request identity should be rejected.

These checks prevent a correction from silently breaking another completed task. Reversing a recognised unpaid amount while leaving a payment allocated to it would produce an incoherent history. Explicitly handling the dependency is safer than an automatic hidden unlink that changes balances elsewhere.

How do you verify the result?

Review both the corrected net balance and the retained chain of evidence.

1. Open the original source and its posted journal.
2. Identify the exact wrong field or accounting effect.
3. Record the reason and permitted correction date.
4. Inspect the linked reversal and corrected posting.
5. Compare the account ledger and trial balance before and after.
6. Check any related reconciliation or allocation state.

In the synthetic expense case, look for the original 152.00 cash credit, the reversing 152.00 cash debit and the corrected 125.00 cash credit. The total matters, but so does the ability to explain it. Keep the reason specific enough that another person can follow the correction without relying on a conversation that was never recorded.

What if the original entry was duplicated?

Reverse the identified duplicate while retaining the legitimate entry and both source references.

Do not select a transaction solely because it has the same amount. Two legitimate expenses can each be 125.00. Compare dates and evidence, identify which posting duplicates the event, and document that conclusion. A duplicate-prevention key helps the application with retries; it cannot know that two differently identified source documents describe the same real-world event.