« | »

How the general ledger can become a data warehouse

Many companies today rely on the general ledger as key part of their management reporting, well beyond the obvious financial information. This has often been shaped by how companies first adopted information technology.

In some firms, their management reporting systems reflect the fact that as information technology began to be used extensively by business, often the very first functional area to be automated was accounting, and the first database within an enterprise was often the general ledger.

In many companies, the general ledger became the clearing house for all information- not just financial, and in effect became a data warehouse before the concept of data warehousing had even evolved.

The problem is, in some organisations, the data warehouse didn't come. The general ledger kept its place as the central repository for not just financial, but also management reporting. Finance argued successfully that the cost of all the business intelligence architecture was unnecessary- adding accounts and bolt on tables was cheaper. ERP vendors supported this by creating ever more flexible ledger structures, allowing additional ledgers for parallel accounting and management reporting.

Huge amounts of non-financial information is still stored in many general ledgers. There are so many reasons this is a bad idea. Here are just three:

1) It forces you to compromise on level of detail and drill down, and history

No general ledger can hold the level of detail available in many source systems. As a result, any interface from the sales system, manufacturing system etc. feeding into the GL will have to create journal entries that summarize a great deal of information.

While the detail of course will still exist in the source system, if your management reporting is all from a general ledger based system, upper management will tend to use this single source- and as a result important granularity may be lost to the decision making process.

This summarization also makes it more difficult to have drill down into the details, giving up some of the greatest benefits of modern business intelligence systems.

Finally, general ledger based data storage does not usually allow for the tracking of reference data changes over time. As sales regions are modified, and territories shift, comparing one period to another becomes increasingly difficult. Data warehouses, designed from the beginning to store this type of slowly changing reference information, can provide a much more insight and historical analysis.

The bottom line is, the data model of the general ledger module is just not designed for analysis.

2) It results in an overly complex chart of accounts and may even affect month end close

As the source systems become more and more capable of collecting data, the tendency is to want to increase the amount of management reporting. If this is being done in the general ledger, it means that further charts of account must be added, and an increased number of journal entries need to be done. Depending how the overall process is setup, its even possible that the increased complexity might affect the speed at which month end closing can be completed, if for no other reason that the same finance resources must both tend to the financial and the management reporting needs.

3) It discourages cross functional definitions and collaboration on analysis

By making one of the functional areas (finance) the center and owner of management reporting, a general ledger based reporting architecture can actually increase the severity of the information silos it is most likely trying to eliminate.

Because the general ledger reporting does not require all the detail available, each department only needs to provide the summarized information required by finance. While every department has to coordinate with finance, there is no requirement for departments to work with each other to coordinate data and definitions. While at a high level data is integrated, any benefit from more tightly integrating information across silos that a data warehouse can bring is lost.

In a very real way, a successful general ledger based management reporting system is in fact an impediment to progress for an enterprises business intelligence and data analysis evolution.

Because management reporting is available, the justification or need for a data warehouse is not felt as strongly. However, as needs continue to evolve, the effort expended in the constantly growing general ledger, and its impact on the financial processes, and the companies overall information management culture will become increasingly damaging.

Ironically, companies who failed to ever establish a general ledger based management reporting system could leapfrog their more financially focused competitors, as they embrace the modern data warehouse and the the tools available for data analysis.

A true data warehouse is not an easy road, and is only one component of a broader data analysis strategy.

Readers of this blog know that we advocate an approach that balances "Big Business Intelligence" with nimble, user focused data exploration and transformation.

In the short term, using the general ledger for management reporting can seem easier, but in the long term, it probably makes the task of creating an enterprise wide architecture harder- while your general ledger has been growing in the center, individual departments have probably been pursuing uncoordinated, fragmented business intelligence architectures of their own.

Tagged as: ,


« | »


  1. I couldn't describe better what I've seen happen in so many SMBs.

    I just add a couple of points: capturing more details than those required by accounting principles is an annoyance even for accounting. Hand maintained informations in a rush situation are likely to be omitted.

    Sometimes, the general ledger based DW is enough to provide all the essential informations to the company top management. So, top managers will likely think that no more spending is required on the BI area.

  2. I think pros could have been addressed more thoroughly. It many ways the GL is perfect to be used as a sort of data warehouse. Take a look at the flexibility and capabilities modern ERP vendors are tying in with it and how it fits into the standard data flows (lots of stuff has to make its way to the GL anyway). The "data" being in there does not preclude throwing extra tools on top of it.