Skip to content

Feature Request: Proper Reversal Entries for Journal, Payment, and Invoice Transactions #47652

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tekticianIT opened this issue May 21, 2025 · 0 comments

Comments

@tekticianIT
Copy link

tekticianIT commented May 21, 2025

📌 Summary

ERPNext currently lacks a true reversal mechanism for financial entries. While it supports cancellation and amendment, this approach does not comply with accounting practices for closed periods and audited financials, especially in public-listed or regulated environments.

This feature request proposes the addition of a dedicated Reversal functionality for Journal Entries, Payment Entries, and Sales/Purchase Invoices — without cancelling the original transaction.


💼 Why This Is Important

  • Cancellation = Change to Prior Period: The existing “Cancel and Amend” mechanism alters the original GL entries, which is not acceptable once books are closed or when financial statements are audited and submitted.

  • Immutable Ledger Limitation: While ERPNext offers an immutable ledger option, it still doesn't address the need for posting a reversal in a future open period while maintaining audit trail integrity.

  • Compliance Risk: For companies under audit, such as public-listed companies, changing prior-period transactions violates generally accepted accounting principles (GAAP) and statutory compliance.


🎯 Proposed Features

The reversal functionality should:

  1. Allow reversal of Journal Entries, Payment Entries, and Invoices (Sales & Purchase).

  2. Post reversed entries in a user-selected open fiscal period, with references to the original transaction.

  3. Preserve the original document and GL entry untouched — no cancellation, no amendment.

  4. Allow each transaction to be reversed only once.

  5. Mark reversed documents clearly, e.g., with a “Reversed” tag or status field.

  6. Prevent reversed entries from being reconciled, e.g., in bank reconciliation, or matched against any other open item.


🔄 Workflow Example

  • User selects a posted Journal Entry dated 31-Dec-2023 in a closed year.

  • Clicks “Reverse Entry” → New Journal Entry auto-generated with all debit/credit lines swapped, dated 01-Jan-2024.

  • System flags the original as “Reversed”.

  • Reversal is read-only, and cannot be deleted or matched.

  • Audit trail is intact, and prior period remains unchanged.


📊 ERP Systems That Support This

Other ERP solutions have well-established reversal mechanisms:

ERP System | Reversal Mechanism -- | -- SAP | FB08 — Reverses a document in a selected future period Odoo | Reverse button for journal entries + reconciliation lock Oracle NetSuite | Reversing journal entries with lock on prior periods Microsoft Dynamics | Void/Reversal with GL and reconciliation handling

🚫 What Doesn't Work Today

ERPNext offers:

  • Cancel + Amend — modifies original GL entries, unsuitable for closed periods.

  • Immutable Ledger — prevents changes, but does not offer an alternative for correcting entries via reversals.

  • Manual Journal Entry — requires manual creation and tracking, error-prone and lacks systemic enforcement of audit rules.


✅ Why This Belongs in Core

  • Broad Applicability: Affects all ERPNext users who generate accounting transactions.

  • Enhances Compliance: Crucial for any company with statutory reporting, audits, or year-end close processes.

  • Reduces Risk: Prevents accidental re-use or reconciliation of reversed entries.

📎 References
SAP Reversal Doc – FB08

Odoo Journal Entry Reversal

Microsoft Dynamics - Reverse Transactions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant