[Breaking Change v13] Introducing Immutable Ledgers in ERPNext

This PR changes the way Accounting Ledger(General Ledger) and Stock Ledger works in ERPNext.

As mentioned by @rmehta in his earlier post posting backdated entries has the following disadvantages:

  • Posting back dated stock entries is computationally expensive since all the future entries needs to be reposted which takes a lot of time

  • If the stock valuation is based on FIFO(First In First Out), on posting back dated stock transactions the entire fifo queue gets regenerated which upsets the valuation in the subsequent transactions

  • Currently on cancellation of any transaction we delete the GLE/SLE which shouldn’t be done as per International Financial Reporting Standards

On cancellation of any transaction instead of deleting the General Ledger Entry(GLE) or Stock Ledger Entry(SLE) a new GLE or SLE will be posted on the date of cancellation that will reverse the impact of that transaction.

Also you won’t be able to delete the cancelled transaction anymore since it will be linked to the corresponding GLE or SLE

Back dated entries that affect the Stock Ledger will be allowed only after the last stock transaction’s posting time which means there will be no need of any reposting of future transactions.


We have looked at several alternatives and this is a huge pain area based on our experience of supporting hundreds of ERPNext instances. Stopping back dated stock transactions will result in much fewer downstream “investigations” who why certain reports are inconsistent over time.

This change will be pushed in Version 13. Maybe its time :wink:


Make this optional on Company level…

1 Like

Do not understand the impact of this fully…

There are many instances when data entry was missed for earlier month or period and discovered during year-end or period-end audit. Many small companies cannot afford or do not have procedures to audit inventory or other transactions prior to closure of the accounting period and so transactions occur in parallel for new period while back dated journal entries are made to reconcile stock, payments, bank balance etc.

Will this still be permitted? For example if we setup quarterly accounting periods - can we make entries for prior quarter while new transactions occur in the current quarter? Say until a PCV is made for that period? Since we already have mechanism to update subsequent reports - why disable / delete that completely? Can it be offered as a choice? Perhaps requiring very high level user permission and warning of impact before submitting a back dated entry?

Seems that completely taking away this option / flexibility may actually cause headaches and force small companies to conform to only one way of operation??.. It will raise the cost of doing business if we are to use ERPNext as we have to audit / promptly close out the prior period before any transactions are posted for new period?


Yepp, fully agree…just finished the “end of the year check” Based on the bank transaction file I identified several purchases that I forgot to enter…So just updated and corrected all info for the full 2019…

If this were no longer possible indeed it would be a problem for small companies not having a professional accounting team keeping everything upto date


Even the most popular accounting systems in India like tally, busy are much more flexible than this, yet have robust report generation.
Agree with @becht_robert in that small firms (major share of erpnext users) might not be working in an ecosystem where everything is punched correctly in one go and on time.
The lack of this flexibility will be a deal-breaker for many. May be a survey of end users could bring more insights before merging this?

1 Like

Hi all,

there was already a long discussion on this and I believe it was made clear that back-dated entries are allowed but will only be posted in chronological order to avoid re-calculations and re-posting while reports will be made available to show your ledgers in the actual order they’re supposed to be


1 Like

The more I think about it the more worried I am about the change this approach is going it make. I am sure others also have a lot of questions. The proposed change can make auditing very difficult for companies. I suggest that there should be a demo setup where the people can try changes. This will build up use cases which can be reviewed and if anyone sees anything inconsistent then they can report. In my opinion this will make people more comfortable with the change and help test the system.

Secondly I have few use cases for which I wanted to understand the impact the changes will have:

  1. Suppose items were supplied with Delivery Note and Invoice to customer. Before they make payment which may days after the delivery, customers accounts team comes back with small changes that they want in the invoice and delivery note. The user amends the invoice and delivery note.
  • After this change how will be the transactions ledger be like?

  • How will it impact the reconciliation with GST and in future with ewaybill?

  • What will be transaction date. What date does the system show the item left the store? If we cancel it delivery note will the item show up in the store on the date we cancelled it? After amendment what day will it be shown to leave the store?

  1. If there is a fixed asset item that was bought in July and was not entered in the system by mistake. During audit the say in December missing entry was found and entered, how will impact the depreciation?



I’d love to see that everything in ERPNext are captured as series of immutable events. i.e. not only accounting, I mean every module, document, et. all.


ps. a good article:

One question… If I want to restart my asset list (changed how my new account firm see the list… :frowning: ), what steps I need to follow now?

Before launching an immutable functionality in EPRNext, I do believe a deeper discussion must be had. Many users do appreciate the possibility of modifying the entries, given that mistakes do occur. I believe that the permissions and roles modules, plus the possibility of keeping track of deleted items and activity per user, is enough not to warrant the forceful imposition of an immutable functionality per se.

If some sort of state tracking is desired this could be tracked by a second server, like in a backup fashion. A diff tool showing the changes clearly should be enabled to allow auditors and third parties understand why such changes were needed.

1 Like

Hi @Tropicalrambler

I think it’s a little bit beyond just the state-tracking… it’s also computationally expensive especially for those who have loads of stock ledger entries like in retail and manufacturing. We’ve experienced it many times when changing a back-dated stock entry causes the system to freeze and sometimes even never completes the entire cycle of reposting!

I’m not sure there are many systems, even among the top-tier like SAP, that repost all ledgers from the point of the back-dated transaction. If there’s a way to get sround this burden, that’d be fantastic

In any case, I also agree that this is a very significant change and it’s impact across all categories of users needs to be carefully and thoroughly assessed

Kind regards,

I agree with you on the problem of back-dated stock transactions. This certainly causes lag. A valid use case of inmmutability.

1 Like

From a user end point, can’t this be done just in the background? As an accounts user one can simply edit any transaction, the reports generated just show the latest transaction values.

SME’s do have corrections to do from time to time. Apart from the hassles with authorities (who as you know look for minutest of issues), even customers are used to the present system of having one invoice number and that itself being modified of corrected. Infact even a “-1” suffix adds to a lot of confusion and debate.

A win-win for end users and system operations would be to have all the processing be immutable in the background, with permission based visibility of the background ledger. This way operators and end users have a “simple” ledger they are used to while background processing is optimised.

1 Like

Cancelling an old transaction will affect balances of subsequent rows, while in immutable ledger if you reverse a transaction, the balance only changes at the very last row.

This is a significant change, cannot be hidden from the anyone’s view.

@Tropicalrambler I agree there needs to be more discussion. I feel partial immutable ledger is a better balance between the two schemes:

  • For a transaction which is only 2 days old, cancellation may not be computationally expensive
  • Therefore I propose a that we have configurable cut-off date for beyond which cancellation is prohibited.
  • So very old records cannot be cancelled

I think this can at least be a good transition towards a complete immutable ledger.

1 Like

Currently in ver13.

I think there needs a feature to reduce chances of ending up with backdated stock entries.


  1. Active Accounting periods with Start Date and End Date. E.g. June 1 2020 - June 30th 2020, where only entries can happen.
  2. No more defaulting posting date to Today’s Date, especially when cancelling a document.

Or a re-think of the approach/solution to the problem, for cases where past transactions maybe necessary.

If ERPNext is still aiming at SMEs users, I think a too rigid system would not be appropriate for them.
Many, if not most, SMEs don’t have all the personnel to do all functions like accounting. So mistakes happened. And many corrects this mistakes, and even posting transactions, by end of period (week, month, fiscal period, etc). Handling it everyday (because the system is not allowing backdated transactions) would be a hassle.


Agreed, a system should have the flexiability to allow backdated transactions as people make mistakes.

May be we can study how QuickBooks do this things.

As most of them know that QB do not have this problem, once we posted on back date, all stock balance adjusted in a sec.

I do not know how they do that, but it works.