Cancelling a GL Entry / Payment Entry creates a reverse entry in the "original" date, not on the actual cancellation date.

[jorgeastiazaran]

Information about bug

https://github.com/frappe/erpnext/issues/28678#issue-1068821368 @hasnain2808

I would appreciate greatly any feedback, this issue makes accounting very inefficient because it makes impossible not to modify previous and/closed accounting periods.

Hi

We are using V13.15.2

According to V13 documentation, regarding the "immutable ledger" functionality, when cancelling a GL Entry such as a Payment Entry, reverse entries should be created on the date of the cancellation.

The following is an extract of this information found in https://docs.erpnext.com/docs/v13/user/manual/en/accounts/articles/immutable-ledger-in-erpnext

""

Reverse Entries on cancellation of transactions General Ledger

On cancellation of any transaction instead of deleting the GL Entries for that transactions reverse entries will be passed to cancel the effect of that transaction on the date of cancellation.

""

In our case, when cancelling a GL Entry:

A reverse entry is created, as expected (no problem with this). The date of the reverse entry is not the date of cancellation, it is posted in the same date as the original entry. Here's an example: This is the history of the payment entry (PE-19845): It was submitted on the 27/10/21 and cancelled on the 16/11/21

Both GL entries are posted on the 27/10/21

As I understand from the documentation, the Cancellation entry should've been posted on the 16/11/21.

Is there any feature that should be enabled through "accounting setting"? Or is this actually a bug?

Gracias por ERPNext! Saludos!

Module

accounts

Version

ERPNext: v13.10.0 (version-13)

Erpnext Support: v0.0.1 (master)

Frappe Framework: v13.10.0 (version-13)

Installation method

No response

Relevant log output / Stack trace / Full Error Message.

No response

[dj12djdjs]

@ankush I hope you don't mind the tag.

I just tested this on latest version-13, this is a valid bug. I'd hate to see that bot push this away.

According to https://docs.erpnext.com/docs/v13/user/manual/en/accounts/articles/immutable-ledger-in-erpnext

Introduced in Version 13

On cancellation of any transaction instead of deleting the GL Entries for that transactions reverse entries will be passed to cancel the effect of that transaction on the date of cancellation.

According to the documentation, the expected behavior would be to create a transaction using the current date as posting date when the voucher is cancelled. The actual behavior is the voucher being cancelled posted date is being used for the reverse entry.

[jorgeastiazaran]

Thanks for commenting.

I hope this issue is given some priority.

Thanks!

[c0db1nar10]

Thanks for bringing this up Jorge…This behavior contradicts the aforementioned expectation from the documentation. We’ve been puzzled by this and some of our customers also.

Please fix as ERPNEXTs reputation is being damaged by this…Regards!

[jorgeastiazaran]

@deepeshgarg007 Thanks!!!!!

[hadeeld7]

Is there any update to this issue ?

[Olawale1]

Hmmm... actually I think a lot of people would prefer it to work the way it currently does. Cancelling a doc usually means you are trying to reverse it's effect from the point of inception. If you want the effect only reversed from the date of cancellation then you might be better off using a Journal Entry for that purpose

Kind regards,

[jorgeastiazaran]

Hi @Olawale1

As an inexperienced entrepreneur it might seem just right to cancel a document as you point out. Believe me: been there, done that and suffered the consequences.

The problem comes when you use ERPNEXT for an actual business which is subject to legal and financial laws, since manipulating an accounting ledger after a period is closed is a very delicate matter (accounting ledgers must be inmutable in most countries)

The International Financial Reporting Standards (IFRS) are a set of rules which several countries use as standard to create accounting and tax laws. These standards require accounting cancellations to be carried just the way we're we are pointing out. Not complying with those standards could have profound/severe tax penalties as it could be interpreted as accounting manipulation after an accounting period has been closed and reported to the taxing agency of your country.

[danjeremynavarro]

Just want to add my two cents on this issue as well. Currently the way the cancellation is posted is not good for legal and financial laws on some countries (for example us in Canada had a problem with this issue before and I had to stop cancellation on most documents) where some cancellation changed the accounts we reported to the government.

And @jorgeastiazaran is correct in that this is defined in IFRS and what most audit companies will check for. I also personally think that this is also preventing ERPNext be taken seriously by the finance world.

[Libermentix]

Same here. A reverse entry should only be possible on the "Cancellation Date". This makes auditors cringe and tell us that ERPNext is not a valid auditable system (requiring us to mirror into an SAP System).

By the way, this bug can be generalized into anything that touches the General Ledger. So the issue exists for Sales Invoice, Purchase Invoices, Payment Entries, Journal Entries, etc.

We are using most recent ERPNext 14 version. So this affects the most recent version.

[jorgeastiazaran]

What we are doing to manage this situation in the meantime is to cancel any GL entry through a Journal Entry.

It is not as easy, but it has all traceability and compliance requirements.

El mar., 7 de marzo de 2023 8:42 a. m., Felix Plitzko < @.***> escribió:

Same here. A reverse entry should only be possible on the "Cancellation Date". This makes auditors cringe and tell us that ERPNext is not a valid auditable system (requiring us to mirror into an SAP System).

We are using most recent ERPNext 14 version. So this affects the most recent version.

— Reply to this email directly, view it on GitHub https://github.com/frappe/erpnext/issues/30547#issuecomment-1458293487, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP6I77DATH5X3DIUXKRGA3DW25CL7ANCNFSM5SJ3GMBQ . You are receiving this because you were mentioned.Message ID: @.***>

[bosue]

I do think this is critical, even though there may be a workaround using a journal entry.

However, there are a couple of different constellations in need of different solutions:

• If the original voucher was filed but for whatever reason never reached the customer (in case of documents like a sales invoice it may not have been sent or not received for various reasons) or never executed, or
• if the original voucher was incorrect / unlawful / unfounded from the very beginning then, depending on circumstances and legislation, it may be or even may have to be cancelled or amended per the original date (ex tunc).

In the meantime, a financial year may have been closed, with the financial report being published, often 3 to 12 months later, which may constitute a minor or major problem. Depending on the scope of errors made, the financial year may have to be selectively reopened and even an already published financial statement may have to be amended. If the financial year is and remains closed, the erroneous vouchers may be amended or cancelled per the first day of the following financial year that remains open.

For added complexity, the fiscal year (note the difference; this is the tax year) may only be closed at a later point, often only 15 months later, so fiscal corrections may still be made or may even still have to be made, even if the financial year remains closed.

There is a different situation, if the original voucher was alright then but things changed later, so the voucher needs to be or is opted to be reversed or amended now. In this case the voucher needs to be cancelled today (ex nunc).

Things may be different from legislation to legislation. All we can do is to make sure:

• vouchers may technically be cancelled either ex tunc (original date) or at the earliest date still open for transactions, or ex nunc (now).
• These options may be preselected per voucher type (or restricted to only one option).
• per-company settings allow restricting backwards (ex tunc) transactions for the latest already closed financial year to certain user roles, and allow prohibiting them altogether for earlier years.

Once this is in place, we should have a reasonable baseline in place, although we will almost certainly have to refine things further at a later point. This is one of the most tricky aspects in real life accounting, so it should be no surprise the same holds for us here.

[anandbaburajan]

I'm thinking of giving a system-level checkbox to use either current or original date, but I would like to know if anyone has any thoughts on whether per-entry flexibility would be needed.

@jorgeastiazaran @dj12djdjs @c0db1nar10 @Olawale1 @danjeremynavarro @Libermentix @bosue

[vorasmit]

I am against the requirements of this feature for the following reasons:

• The posting date is a date when accounting effect is required
• This is editable from when the transaction is initiated itself, and there should be complete control over the posting date that is used for the reversed transaction.
• By design, cancelled transactions should have zero or nil effect at all places.
• What legally is required (IMO) is an audit trail which is very well already available with correct time stamps.

What could be the reasons for cancellation?

• Temporary: Want to make changes to entries (as this is the only way it's possible). These changes could or could not affect accounting GL Entries. eg: Would like to change vehicle number or GST Category in Sales Invoice.
• Permanent: Would like to cancel the transaction in its entirety. No plans to amend this.

The problem we are currently looking for is only for permanent cancellations or cancellations after the period is closed or cancellations after the document is reported to authorities.

Solution

Reversal

Where a reversal effect is required at a different date, it should be intentional every time, and hence reversal entries should be created manually. E.g.: Credit Note for Sales Invoice or Reverse Journal Entry for Journal Entry.

Freeze transactions after period closure

(From Accounts Settings)

Custom Workflows

Custom workflows can be set where transactions cannot be cancelled after x days after the posting date.

Possible Enhancements

• (UX) Can reversal entries be further simplified?
• Reversal of Payment Entry or Stock Entry.
• Link Reversal entry with Original Entry (like credit note is linked with Sales Invoice)

Other Softwares

I looked at QuickBooks, Xero and SAP (Youtube Videos + Documentation)

Quickbooks and Xero have a feature of Void, which will make the transaction with NIL effect, and give an appropriate audit log of when was it made void.

I am not sure any software actually posts a cancelled transaction on a different date. If others have references for the same, It could be useful in having a correct and better design.

---

Even in India, we have strict reporting guidelines with e-invoice and GST, where it should not be tampered with or cancelled after it's submitted to the GST Portal or after the period closing. And then it's the responsibility of the accountant or user to ensure correct accounting effect.

[bosue]

Thank you @anandbaburajan for picking this up and bringing it back into sight.

I will have to re-read and think about everything said here, maybe look a few things up, as it’s quite a bit complex. From the first read, I however think I fully agree with @vorasmit’s assessment, if I got it right:

1. Don’t add a checkbox / both options / subtleties that are hard to tell apart
2. Strictly distinguish cancellations from reversals
3. Reversals (aka changes in mind or situation) are always supposed to be ex nunc = per now.
4. Cancellations and possibly amendments (either way basically corrections of accounting errors) are always supposed to be ex tunc = per the original entry’s date.
5. Make sure one and the other are more or less equally available = improve UX.

The only aspect missing there: what if the original entry‘s date isn‘t available (to the user) anymore? I can see two routes of resolving:

• If a senior officer / other user role may still make amendments to the original entry‘s date: assign the cancellation to them
• Otherwise, if the date (e.g. 5 October 2022) is irrevocably frozen, because that year’s report has been submitted to authorities, the cancellation should take effect to the first date still available (e.g. 1 January 2023).

But basically, our current logic is correct.

[Olawale1]

Hi @anandbaburajan

Thanks for looking into this. As I mentioned previously, and some of the other contributors have also alluded to, a 'Cancellation' should take effect from the original date. The current design is very correct on this

If your country's financial laws do not permit cancellations under any circumstances then you should simply disable that permission from all roles and use a 'Reversal' entry instead

A 'Reversal' can be at a later date and can be done using a Journal Entry. An improvement to the current system could be to add a 'Reversal' option to the Payment Entry' document so that reversals are properly linked to the original transactions

Thanks

Kind regards,