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 
Make this optional on Company level…
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?
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
Cheers!
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:
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?
-Amit
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.
/d
ps. a good article:
One question… If I want to restart my asset list (changed how my new account firm see the list… 
), 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.
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.
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.
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:
I think this can at least be a good transition towards a complete immutable ledger.
Currently in ver13.
I think there needs a feature to reduce chances of ending up with backdated stock entries.
E.g.
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.
Maybe a checkbox in setting can toggle this functionality to allow back dated.
Or a role to allow this functionality.
So for example, the business owner can do daily transactions and maybe make mistakes. At the end period, the ‘rented’ accountant can activate this functionality and correct the mistakes.
In my opinion, especially for SMEs, the tracking of the correction made (and who does it) is more important than not allowing to make mistakes.
It’s a nightmare if backdated not allowed for SMEs as they do backdated most of the time…I would suggest this as an system setting option.
This immutable ledger is more fit for enterprises who willing to comply accounting standards