[discussion] Immutable Ledger

[tundebabzy]

This shouldn’t be an issue of what users find flexible but about what accounting standards and accounting rules (US) say. We should use this as the contract which the implementation should satisfy.

Traditionally, the general ledger is mostly a no-delete, append-only document. That is why accountants have terms like reversal, contra entry, etc. That is why I also support that General Ledger should not allow deletion of entries. Let’s also not forget about accounting periods which brings about the concepts of Prior Period Errors, Change in Accounting Policies, Change in Accounting Estimates (IAS 8) and then Errors After the Reporting Period (IAS 10).

Under IAS 8 and IAS 10, there are circumstances where you have to make corrections retrospectively. An example is when you forget to input say a Purchase Invoice that was received in say January and then remembered in February or you made a wrong depreciation entry. That means it should be possible to back date entries in the GL including when it’s in a closed period. Obviously, after making a retrospective change, closing balance for the said period and the next opening balance would change.

@rmehta

Here are some problems related to this:

Forward posting is computationally expensive.

• In stock, where valuation is based on First-in-first-out (FIFO), the entire sequence gets regenerated, - upsetting valuations and profits for all subsequent transactions.
• Taxes calculated and paid for a period may also get changed.
• Making changes back in time can lead to unexpected consequences

Actually, this is the correct thing to do. We don’t have any choice but to find a design that makes this as efficient as possible.

[Joshua_Bowman]

I have to say that I don’t understand why anyone is arguing against an immutable ledger at the database level. Anyone who runs their business without a full audit history is looking a disaster and/or severe penalties, no matter how much they trust themselves or their bookkeepers. One fat-finger edit can destroy your accounting, and necessitate restoring backups to verify against, if you even have them.

The implementation detail of updating reports to add up the edit entries should never be a reason to outright reject something that actually protects every business owner.

[wale]

Hi @tundebabzy

Trust you’re doing great. Seems like you’re arguing both sides? In the first part of your comment it appears you’re all for immutability and towards the end it seems you’re against it. Could you please clarify?

Thanks

[tundebabzy]

I’m in for ‘immutability’ as in not being able to delete any record from the GL. Like I said earlier, the GL is supposed to be an append-only document so records should only be added at the bottom including records that reverse previous entries. I know that I said users should be able to back date entries into earlier periods and that sounds like I supporting a system that is not append-only. If you think of the GL as a combination of 12 smaller GLs, the append-only requirement will not be hard to imagine.

So to be clear, I’m in for:

• No delete from the GL. This should not be a subject of argument as @Joshua_Bowman and others have rightly pointed out
• Append-only to the GL
• Back dated entries as needed even though it might be expensive and slow. Accounting standards require it. There will be changes and that is why IAS requires disclosure of such.

[tmatteson]

@Chude_Osiegbu

When it comes to accounting documents, ERP systems I’ve been exposed to track the following 3 dates:

Posting Date: The date on which the transaction has an impact on the General Ledger

Document Date: The memorandum date on which a document was physically received, generated or sent. Has no impact on the General Ledger

Entry Date: The date on which the document was entered into the sytem (This date should not be editable)

My understanding up till now is that Posting Date in ERPNext is the same as Posting Date I’ve described above. I believe it should remain so.

Document Date and Entry Date are not really represented uniformly in ERPNext.

For me the proposed Transaction Date should be equivalent to the Document Date as defined above.

Entry date should be the date of the booking in the system. It should not be editable and should represent the time-stamp of when the transaction was entered.

This is really clear and I like it.

[wale]

@tundebabzy

Back dated entries as needed even though it might be expensive and slow. Accounting standards require it. There will be changes and that is why IAS requires disclosure of such.

Hi @tundebabzy

The above point is where I really require clarification. Is the GL still immutable if you allow back dated entries? What would then be the point of the whole exercise? Under what conditions would you bypass the immutability of the Ledger?

Just in case you’re wondering, I am definitely in support of immutability because I know it is the recommended standard practice in accounting and honestly, it significantly improves the reliability of the system not to talk of the bug (as disclosed by @nabinhait) which leaves our Stock Ledger perpetually inaccurate when using FIFO

Having said all this, I’m however a bit concerned, just like several others, about the impact this would have on the end-users. If I correctly understand the earlier explanations from the ERPNext team, we would still have the reports showing ‘amended’ transactions (similar to what we have now) when we run them using the ‘Transaction Date’. Using the Posting Date however would show a report of entries according to their order of creation

At this point, I think the naming convention requires some clarifications too as it might be causing some confusion. Since Posting Date is generally understood as the date when the transactions impact the Ledgers, I think we should keep it this way instead of using the term Transaction Date. For the date when the entry is made, we can consider keeping this simply as ‘Entry Date’

So for every transaction, we have:

Posting Date: Date when the Ledgers are impacted (Can be amended as required)
Entry Date: Date when the entry is Created (Can not be changed)

Therefore, immutable ledgers (from a user’s perspective) simply means that the Ledgers will now be generated using Entry Date rather than Posting Date in order to avoid frequent recalculations and other compliance issues. Also, Cancelling a document will work just like doing a return. There will however be the ability for us to still view reports according to Posting Date (as we have it currently)

If all the foregoing is correct, then there’s not much impact on the end-user as long as the logic for validating transactions is also based on Posting Date and not Entry Date

@nabinhait could you please confirm the above statement regarding logic for validation of transactions?

Thanks

EDIT: The more I look at this, the clearer it becomes (I think). Going from the very definition of Posting Date above, I now understand better why the ERPNext team chose their initial naming convention. If the Posting Date is actually agreed as the date when the transaction impacts the ledger then it means Posting Date = Entry Date because that’s when it actually impacts the ledgers under the new proposed system

The Transaction Date would then refer to the date when the actual transaction took place. If I’m getting this correctly then the initial use of Posting Date and Transaction Date by the ERPNext team is actually the correct way to go under the new proposed system!

[Chude_Osiegbu]

@wale

Is the GL still immutable if you allow back dated entries?

Yes, an immutable ledger just means that entries that have already been made into the General Ledger doctype cannot be amended - the only way to make a change is to append a new line

@wale

If I correctly understand the earlier explanations from the ERPNext team, we would still have the reports showing ‘amended’ transactions (similar to what we have now) when we run them using the ‘Transaction Date’. Using the Posting Date however would show a report of entries according to their order of creation

The only date that should be relevant to the operation of the general ledger is the posting date.

@wale

Since Posting Date is generally understood as the date when the transactions impact the Ledgers, I think we should keep it this way instead of using the term Transaction Date

Exactly. Let the Transaction Date be the memorandum date of the source document. Better still, let’s call it Document Date for more clarity.

[wale]

Hi all,

Based on my current understanding of the proposed new system (as reflected in my edited post above), here are the critical points to note and my submission on the matter

There are 2 important aspects of the changes being proposed:

1. Transaction Documents can no longer be outrightly Cancelled/Deleted after Submission. Cancelling a transaction document will now be handled similar to making a return

2. The order of Posting in the ledgers will now be according to the date when the entry is created. This means you can only back date the Transaction Date but NOT the Posting Date

For Point 1 above, I think most people agree it helps for the reliability of the system and compliance to standards

For Point 2, I think this will not have much impact on end-users and will help improve the general accuracy of the system provided the 2 conditions below are satisfied:

a) We are able to generate reports based on Transaction Date (This will reflect the impact of corrective entries in their actual and expected order similar to what we have currently)

b) The logic for validation of transaction documents is also based on Transaction Date

The part about reports has already been confirmed and we await confirmation on the validation logic from @nabinhait or any other member of the ERPNext team

Thanks

[tundebabzy]

@wale
You are on point.

Now that we have more or less finalized the design contract, we now need input on the design implementation

[Chude_Osiegbu]

@wale

The order of Posting in the ledgers will now be according to the date when the entry is created. This means you can only back date the Transaction Date but NOT the Posting Date

You should be able to back date both the posting date (in cases where you open an already closed accounting period for example) and transaction date. What can’t be backdated is the entry date which is a record of when the posting was performed (this is actually the creation date of the doctype). All three dates are required at a minimum.

[Tufan_Kaynak2]

Dears,
I guess the deletion ability of Journal Entries is a very good feature. Since most SMEs do not have in-house accountants, this ability allows them to do entries without consulting an accountant and keep their records up to date. Whether a closed period is editable or not and if the company tampers with past data is an ethical issue. We cannot stop them from turning accounting tricks by any system.
If we take away this feature, the SMEs would revert to Excel or else to keep their transactions and ErpNext would just simply be another accounting driven system. This generally kills ERPs being used on the spot for transactions and calls for separate solutions being applied.
With the current flow of accounting entries, if you don’t allow negative stocks, all entries need to be made with their actual dates so that stock is valid at all times then the faulty documents are deleted to reflect the correct state of the system.
Let’s say that the SME uses ErpNext as their only system to run the company and does not employ an in-house accountant. This can be the case for many reason. Either their process is repetitive or the value chain produces simple outputs. For all the postings after the accountant’s evaluation if there are records to be corrected for currency changes, posting accounts approach even account names there will be significant changes between the records that the accountant is keeping and the ones at the ErpNext for the SME. This will lead to unmatching ledgers between accountant’s system and the SME. This is a higher risk. This will render SME’s ErpNext system invalid compared to the accountant’s.
Accounting correctness is an ethics issue not a software issue. We should be very careful in applying this new approach.

[wale]

@Chude_Osiegbu

You should be able to back date both the posting date (in cases where you open an already closed accounting period for example) and transaction date. What can’t be backdated is the entry date which is a record of when the posting was performed (this is actually the creation date of the doctype). All three dates are required at a minimum.

Hmmm…

As highlighted in my last post, a major part of this new proposed system is hinged on the premise that the Posting Date MUST be in chronological order (i.e. Entry Date). Since this is the case, allowing Posting Date to be back dated under any circumstance will defeat the purpose of avoiding forward recalculations. I therefore wonder how the issue of reopening closed accounting periods will be handled. Will there be some Tool/Feature that allows a document to have a Posting Date in a different accounting period from the Transaction Date?

This would then mean that a report for an accounting period, say 2017, could potentially contain transactions with Posting Date in 2018 (made by users with appropriate permissions) but the Transaction Date must be 2017. It also means that all such transactions will not be considered while drawing reports for 2018. Basically, the main validation for what transactions fall into an accounting period will be the Transaction Date and not the Posting Date

I think it’s also important to note here that in the ERPNext context, there will be a difference between Posting/Entry Date and Creation Date

Creation Date: The date when the document is Created/Saved on the system
Posting/Entry Date: The date when the document is Submitted and ledgers are actually impacted

Kind regards,

[olamide_shodunke]

Could we borrow a leaf from the banking sector and call the “Posting Date” Value Date?

[Chude_Osiegbu]

@wale

a major part of this new proposed system is hinged on the premise that the Posting Date MUST be in chronological order

Entry date is chronological. Posting date is not. The terms should not be interchangeable as they are not the same thing

@wale

I therefore wonder how the issue of reopening closed accounting periods will be handled

It’s a standard operation in all ERPs. The retrospective posting is is effected by backdating your posting date

@wale

This would then mean that a report for an accounting period, say 2017, could potentially contain transactions with Posting Date in 2018 (made by users with appropriate permissions) but the Transaction Date must be 2017

The terms are being mixed up. We need to standardize on terms to make progress. I’ll write a doc on this over the weekend.

[tundebabzy]

Let’s forget about the naming conventions for now as it’s not very important for the design.

• There should be a date representing the date the entry was inputted into the database regardless of the accounting period (A).
• There should be a date representing when the entry takes effect (B).
• There should be a date representing the date on the source document e.g the date on a purchase invoice ( C)

(A) will be for audit trail
(B) is the date that concerns the ledger
(C ) should usually be same as (B). It will be for audit trail and memorandum.

[Chude_Osiegbu]

@tundebabzy

(A) will be for audit trail

(B) is the date that concerns the ledger

(C ) should usually be same as (B). It will be for audit trail and memorandum.

Exactly. Next step is to give them names. A,B,C are unwieldy in conversation. Proposals for each term:
A = Entry Date or Creation Date
B = Posting Date
C = Document Date or Transaction Date

In addition it is C that determines the sequence for stock valuation (FIFO or MAP)

[tundebabzy]

@Chude_Osiegbu

In addition it is C that determines the sequence for stock valuation (FIFO or MAP)

Good point. Agreed.

@Chude_Osiegbu

Exactly. Next step is to give them names. A,B,C are unwieldy in conversation. Proposals for each term:

A = Entry Date or Creation Date

B = Posting Date

C = Document Date or Transaction Date

I propose:
A = Entry Date
B = Posting Date
C = Document Date

cc: @nabinhait

[Not_a_countant]

One slight modification :

A = System Date // instead of Entry Date.
B = Posting Date
C = Document Date

[wale]

Hi @tundebabzy

Some further clarification is required here:

@tundebabzy

There should be a date representing the date the entry was inputted into the database regardless of the accounting period (A).

For those less intimate with the inner workings of ERPNext, does this refer to the time of Creation or the time of Submission?

If it is merely the time of Creation then there’s not much point bringing it up since this is naturally captured for every document created in ERPNext and doesn’t have much bearing on the discussion

If however, it is the time of Submission, then (A) = (B) according to the proposed new design and both cannot be altered

We shouldn’t lose sight of the main topic of discussion here which is simply that according to the proposed new design, Posting Date (aka (B) above) = Submission Date and cannot be altered

Kind regards,

[Chude_Osiegbu]

@wale

For those less intimate with the inner workings of ERPNext, does this refer to the time of Creation or the time of Submission?

Time of submission. Before submission, the document is just a proposal.

@wale

If however, it is the time of Submission, then (A) = (B) according to the proposed new design and both cannot be altered

No, the discussing has moved beyond the initial proposal. In this case, Posting Date (B) can be altered and even set to a date in a previously closed period whereas (A) cannot be.