There are two books of accounts maintained in an Organization. One is called variously as Day Book, Journal or Sub-ledger and the other is the main book of accounts called General Ledger or simply GL.
The day book is also called the book of original entry. The details of the transactions are entered in day book and at the end of the day or the week, the accounting summary of the transactions is moved to the GL.
Let us look at this with an example.
Let us say that in a day, the accountant booked three sales invoices for rupees 1000, 2000 and 3000 against Customer X. He enters the detail in day book as follows.
Sold 10 quantities of the finished product to Customer X against his PO number 123 at a price of rupees 100 per unit value 1000
Accounting entry Debit Customer X 1000 Credit Revenue 1000
Sold 20 quantities of the finished product to Customer X against his PO number 345 at a price of rupees 100 per unit value 2000
Accounting entry Debit Customer X 2000 Credit Revenue 2000
Sold 30 quantities of the finished product to Customer X against his PO number 456 at a price of rupees 100 per unit value 3000
Accounting entry Debit Customer X 3000 Credit Revenue 3000
At the end of the day a summary transaction is passed in GL to the extent of:
Debit Debtors Control Account 6000 Credit Revenue Account
As you can see the details of the transaction remains in the Day book (Sub-ledger) and the summary is passed to GL.
At the end of the month the auditor will want the transaction details for the balance of 10000 rupees in Creditors Control Account. The report should be prepared from the Sub-ledger and given to the auditor. Reports will show that company sold 6000 worth of goods to Customer X and 4000 worth of goods to Customer Y.
Transactions details stay in Sub-ledger and summary is passed to GL.
This is Thin GL in a nutshell. In this concept the only accounting entries manually entered in GL are the month end provision and adjustment entries.
However, most of the ERP Implementations violate thin GL. I will explain two violations with reference to the above example that makes the GL progressively fatter.
First violation is to transfer the transaction details to GL. In this case the accounting entry for each transaction is sent to GL. The logic is that it helps to take reconciliation reports from GL. This is not a good argument. You are fattening the GL and creating two sources of truth. The original source of truth is the point of original entry, which is the day book. The second source of truth is the GL where the details of each transactions are passed to. In case of any mismatch between the two you have no way of knowing which is right.
This fattening of GL is aggravated by creating a customer as a reporting segment in GL. This further fattens the GL by creating unnecessary new segment and generating accounting transactions on the segment. This adds another source of truth to the single transaction, which is the accounting entry against the customer segment.
Another way of fattening GL is to pass direct accounting entries in GL. Most of the time this is resorted to to reverse the mistakes created in the original transaction. For example, assume that a payable invoice is entered for 10000 whereas the original invoice value is 1000. The best way to reverse this transaction is to create a debit note in Payables Sub-ledger with a specific error code and approval process. But that is not how it is usually resolved. The simple solution suggested is to pass a reversal journal entry directly in GL. This not only fattens the GL, but also creates conflict between data in day book and GL. Day book shows 10000 creditors while GL shows only 1000 !.
You can see the confusion, can't you.
Thin GL is a concept that every consultant should know. Without that knowledge, you will create a Fat GL and sub-optimal ERP implementation.
No comments:
Post a Comment