Correct a posted entry with a traceable reversal
Keep the original posting, record the reversal and prove the corrected net effect without hiding the history.
PHP Ledger guidance: use this page with the matching release notes and evaluate the workflow using synthetic records.
Is the record still a draft?
Correct a draft before posting; a posted error needs a traceable reversing entry.
First confirm the source status. A saved draft has not changed the posted ledger, so reviewing its amount, account, date and narrative before posting avoids unnecessary correction entries. If the event is already posted, its journal lines are immutable. Do not edit them in the database or create a renamed copy intended to replace the history. The correction should explain both what was originally recorded and what changed.
This guide uses a fictional expense that was posted as 125.00 but should have been 100.00. It assumes an otherwise eligible open period and bank history. No actual payment is made. The goal is to understand the accounting effects and the current interface boundary, not to prescribe a tax treatment or an adjustment for a real business without reviewing its evidence.
What does reversal preserve?
A reversal adds equal and opposite movements while keeping the original posting visible.
| Entry | Expense account | Bank account |
|---|---|---|
| Original mistaken expense | Debit 125.00 | Credit 125.00 |
| Reversing entry | Credit 125.00 | Debit 125.00 |
| Correct replacement expense | Debit 100.00 | Credit 100.00 |
Across all three entries, the expense has a net debit of 100 and bank has a net credit of 100. If bank began at 1,000, the original mistake reduced it to 875, the reversal returned it to 1,000 and the correct replacement left 900. The original entry is still part of the audit history. The reversal neutralizes its effect rather than pretending it never existed.
Do not assume the correct action is always to reverse an entire source. Determine whether the mistake is an amount, classification, date or a duplicate event and use the supported path for that source. Opening balances and POS-related sources have their own boundaries. A generic example is not permission to bypass those workflows.
What can you do in the current browser interface?
The existing interface provides its ordinary reversal action; the new same-identity correction service has no new public screen.
For an eligible posted source, review the existing reversal action and provide a meaningful reason. Confirm the resulting journal and source link. If a replacement is needed in the current browser workflow, create and review the appropriate replacement source using the normal posting flow, with an explanatory reference to the correction. Do not describe that separate browser action as the new internal same-document correction workflow.
The retained posting foundation supports reversal and reposting under the same durable document identity for supported receipt, expense and general sources through its backend service. Posting revisions have their own immutable journal identities while source reads can distinguish original and current effective values. This avoids a rename-and-recreate suffix pattern. This section describes the existing cash/general posting foundation. The 0.4.0 starter also supplies same-identity invoice and bill corrections with explicit dependency checks.
- Document identity
- The durable identity of the source being corrected.
- Posting identity
- The identity of one immutable journal associated with that source or its correction.
- Reversal link
- The recorded relationship between a reversing journal and the posting it neutralizes.
Which date belongs on the reversal?
The default is the current cancellation date in UTC; an original-date exception is permissioned and constrained.
A later cancellation is a dated event of its own. If the original expense was posted in an earlier reporting period and the reversal is dated today, a report ending before today will still include the original expense. That is expected date-sensitive reporting, not evidence that the reversal failed. Review both journal dates and the selected report range when explaining the result.
The owner may use the original posting date only through the permitted exception, with a reason and while the period remains open. Arbitrary alternative backdates are not a general capability. Closed-period checks and completed bank-reconciliation boundaries still apply. Do not promise that an owner permission bypasses every safeguard or that reopening a period makes a reconciled bank history editable.
What should you check before confirming?
Identify the original event, its current status and every boundary that could make the correction ineligible.
- Confirm company, book and the exact original source reference.
- Read the posted lines and compare them with the supporting evidence.
- Check whether a reversal or correction already exists.
- Review the proposed reason and permitted reversal date.
- Check period and bank-reconciliation restrictions.
- After posting, inspect the linked journals and resulting reports.
If a response is interrupted, inspect the original source and its linked journals before trying another action. A new source record is not the same thing as retrying an existing durable operation. Avoid creating several compensating entries because the screen did not refresh immediately. Preserve a concise explanation that another reviewer can understand without reconstructing browser activity.
For the fictional example, the explanation could state that the supporting evidence was 100.00 and the source was entered as 125.00, followed by the original and replacement references. Do not use vague reasons such as fix balance when the actual error can be named. The purpose is to make the correction understandable months later.
How do you review the result?
Check the original, reversal and replacement together, then confirm the net effect in the intended report period.
Use a range that includes all relevant dates to prove the example’s net expense of 100. Then inspect narrower periods if the correction crosses a reporting boundary. A report that includes only the original entry answers a different question from one that includes the later reversal. Keep both explanations if prior-period reporting is affected, and obtain the appropriate accounting review before treating the result as final business reporting.
Verify that the bank account’s net movement matches the corrected source and that the original history remains readable. Equal debits and credits alone cannot prove the selected account is right. A balanced replacement to the wrong expense category is still a classification error. Check the evidence, classification and chronology as well as arithmetic.
When is this procedure the wrong choice?
Stop when the requested change would hide history or bypass a protected accounting boundary.
What should you do next?
Do not use direct database edits, renamed duplicate documents or unexplained offsetting entries to make a report look different. If the period is closed, the bank statement completed or the source has dependent allocations, use the reviewed supported correction path for that condition. Starter invoice and bill corrections are available for supported states; payments, credits, stock and purchasing dependencies can block a standalone reversal. Finish by retaining the reason and linked references, so the corrected result remains traceable.
Questions before you continue
Check these boundaries before applying the procedure to a business installation.
Does a reversal delete the original journal?
No. It records equal and opposite movements and retains a link to the immutable original.
Can I choose any earlier reversal date?
No. The default is today in UTC. The permissioned exception is the original date while eligible and open; other safeguards remain.
Sources and next steps
Technical references and project behavior were checked on 16 September 2026; hosting access remains plan-specific.
The linked project files describe the current preview. Follow the instructions inside your exact downloaded package if a later release changes a command. Technical testing does not establish statutory compliance or independent accounting acceptance. See the project and preview limits.