Unified ledger accounting
This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)(Learn how and when to remove this template message)
The concept of a unified ledger accounting application is often new to people who have used traditional modular accounting systems, though the idea is very simple. Traditional modular systems have separate General, Purchase and Sales Ledgers which reflect times when accountants wrote information into large paper books or ledgers. Balances on control accounts were copied from one book to another, so that a full set of accounts could be completed and as an additional process control accounts were reconciled. This ensured that all of the individual entries added correctly to the control totals before any transfers were made.
In the late 1970s computer experts spotted the potential for writing accounting systems using computer software. Quite rightly they asked accountants what they did and replicated the system of accounting used providing a solution that was easy to understand.
This was the birth of modular accounting software which reflects the historic process by either generating information in the background or by batch updates from one ledger to another. What the experts didn’t ask was why accountants had this multiple book system. The reason for which is simply that having a single book would mean that having to accumulate values for what had been bought, sold or received in cash would be extremely difficult to manage and history had taught them how accounting should be done.
A unified accounting system works differently; it is a single book in which two entries, a debit and credit, are made at the same time. All of the debits add to the same value as all of the credits. The result is that no control accounts are required and no transfers to other ledger books.
There is no requirement for you to reconcile control accounts, and no opportunity for your system to be out of balance. In addition, there are no hidden background processes within software that need to be checked or maintained.
Identifying a unified ledger
Today, the vast amount of computing power available means that many software vendors claim to have a unified ledger accounting system, when they do not. The processes and hooks generate the additional entries required in the system are fast enough for the user not to notice, so how can you identify whether your accounting system is modular or unified?
One condition of a unified ledger is that if you enter a purchase invoice with three lines, you will only have three lines written to the database. In modular systems, the purchase or general ledger line will be “re-created” in the appropriate book with a hook back to the invoice. This results in four or more lines being created (depending on how the software has been built), duplicating information. In a unified ledger accounting system, duplicate lines do not exist and software hooks are unnecessary.
Slow down time
Imagine that time was slowed down so that any processes that occur after entering your purchase invoice take over 5 minutes to run. With a modular accounting system the three initial lines of your invoice are placed onto the purchase ledger, wait five minutes, the software creates an additional line in the general ledger, wait five minutes, the control account value is updated as so on.
This may not seem appropriate today, however, there are occasions when systems shut down in the middle of one of these processes, and that is when you get an accounting system that is out of balance. A Unified Ledger accounting system can never be out of balance. (That is on the presumption that proper Database Transaction Controls are in place, and the ″three initial lines″ referred to above are always written either completely or not at all)
Slow reporting and enquiry time
Unified ledgers, simply by their design, tend to store all transactional data in one table - whilst this can have some benefits from a reporting point of view it does make report writing more complicated for the user as they have to distinguish between supplier, customer and nominal transactions. Additionally as data volumes grow reporting can become very slow taking days in some cases to produce profit and loss accounts