7. The Virtual General Ledger

Each of the Entries made in the Journal must be posted twice in the Ledger, one
to the debit and the other to the credit.
Luca Paciolo, Particularis de Computis et Sripturis

The general ledger, or just “ledger,” is made up of a set of accounts, each account representing a source or destination of resource flows within a company’s accounting system. The information in each account is a repetition of the information that has already been recorded in the accountant’s journal. The duplication of information in the general ledger allows the balances of each account to being manually computed. By copying the amounts of each transaction into the account that it is related to, the human bookkeeper needs to only go to the account to be balanced and add up the sums recorded therein.

For example, a transaction is first recorded in the journal with a note that the transaction has a credit (source) effect upon the revenue account and a debit (destination) effect upon the cash account. After this initial recording, the details of the transaction’s record is “posted” to the general ledger by copying the transaction amount to the credit column of the revenue account and then copying the same amount to the debit column of the cash account. When the bookkeeper wants to find the balance of any account, he adds up its debit column and its credit column and the difference between the two sums is the account’s balance (the net balance can be a debit balance or a credit balance, depending upon which sum was greater).

However, using the fundamental principles of software engineering, the general ledger should be an algorithm, a series of steps that are performed by a computer program, rather than a separate database containing data that is already recorded in the journal. The reasons supporting this statement include the following:

1. The general ledger helps with the manual computation of balances; it serves no similar purpose for automated computation.

2. Duplicating the same information in more than one place violates the most fundamental principles of information design (keeping backups of data on tape and other media is not relevant to this argument).

3. The finding of an account balance is a matter of first sorting and then summing data. The traditional general ledger performs the function of the sorting part of this process. Modern computers can do this sorting almost instantaneously and without cost. Therefore, to have the data in a pre-sorted state is of no economic value. Determining account balance is efficiently a simple algorithm that first sorts and then sums.

4. The maintenance of a general ledger as a separate database performs no other function on the computer than to place an artificial boundary upon the data, limiting its availability in both time and semantics. The general ledger limits the data to the time of a single fiscal period and it limits the various ways that the data can be correlated with other dimensions of the transaction, such as business units, products, customers, etc. (this will be detailed in the next post here).

The general ledger should be, by this analysis, virtual data. Modern accounting practices should use the power of the automation to make the general ledger a Virtual General Ledger, implemented as a program that sorts and sums the data already stored in a powerful database.

See Banking the Past.

6. The On-Demand Cash Flow Statement

The cash account should always have a debit balance or be equal [zero balance].
Otherwise, the account will be in error.
Luca Paciolo, Particularis de Computis et Scripturis

The Cash Flow Statement is nothing more than a summary of activity in the company’s cash account. It summarizes how the cash account was debited and credited by the company’s operating, investing, and financial activities during a particular period of time. The debits are referred to as “input” in the report while the credits are therein referred to as “output.”

Typically, a Cash Flow Statement, like an Income Statement, summarizes activity for a particular fiscal period. However, unlike the Income Statement, the Cash Flow Statement does not require that the company’s books be closed before its preparation. This means that, although the Cash Flow Statement summarizes a time period, it is not locked into the constraints of a fixed fiscal period such as the Income Statement is. A Cash Flow Statement could, theoretically, be prepared at any time without the closing of the books and the use of temporary accounts that exist only for the company’s fiscal period.

The Cash Flow Statement could be prepared on a weekly, monthly, or even daily basis. The only impediment to this powerful ability to create useful information is the intensive labor that is required to create the Cash Flow Statement and the only solution to this impediment is to store all of the financial transactions in a data warehouse. A Cash Flow Statement for any time period desired can be prepared effortlessly in seconds with a simple command to a well-designed financial data warehouse.

The use of a data warehouse to back up an accounting system (or be the accounting system) is the key to producing real-time financial statements for arbitrary time periods. This fact is most apparent in the case of the Cash Flow Statement and its growing importance within the company. See Banking the Past, p. 169.