A diet for your General Ledger system: From “Fat GL” to “Thin GL”
Determining the number and composition of the extended accounts (Flexfield structure in Oracle) has been a topic of debate and angst amongst GL architects.
A “Fat GL” design as the name implies contains a very large number of journals, often containing information that would typically be required for operational management reporting and typically containing minimal summarization.
A Fat GL creates a very large number of “account combinations” and journal lines. The “account combination” is a product of number of values in each segment. Valid combinations might be fewer but the multiplication rule still holds. Even if one segment has a large, and may be growing, number of values the number of combinations will be really large. In the mid 90s, I saw a customer with 11 segment accounting Flexfield, with “Project” being one of the segments. It is easy to see that such a company would likely have millions of journal lines coming to its GL system. This company had a pretty rudimentary project accounting system. Hence GL also acted as its system for project profitability reporting.
Typically you would have multiple books due to currency and/ or statutory requirements. These would require several consolidations and you soon have millions of journal lines sloshing around in the system. Add to that the complex organizations created through mergers and acquisitions in the last decade. Soon the GL system becomes cumbersome to maintain and expensive to retrieve data from.
Why did we design such a GL system in the first place?
Most of the fat is create through the addition of “analytical” fields (segments) in the extended account. In many organizations, GL had become not only the system for financials and regulatory reporting, but also a system for operational management and reporting. Hence if you are project oriented organization and lacked a strong application for project accounting and management, GL became the repository for project level operational reporting.
However, as ERP systems became more robust and extended in areas like order management, projects and supply chain, the sub-ledger systems became robust enough to become systems for majority operational management reporting. In many industries like in manufacturing, high tech and project oriented services organization, the GL system became trimmer and fitter geared more towards financial and regulatory reporting
The Financial Services industry, by contrast, has remained one where the sub-ledgers (like core banking, treasury and brokerage applications), both at the front and middle offices are not typically part of the regular ERP applications. Moreover the large numbers of acquisitions with disparate and often duplicate systems have created a situation GL became pretty much the only system with a company wide view. Hence many Financial Services companies have a Fat GL environment creating challenges in reconciliation, reporting and control.
Financial Accounting Hub based Financial Accounting ArchitectureIf you look at Oracle’s current offering, you no longer need to be satisfied with this less than optimal situation. An architecture involving Oracle Financial Accounting Hub, a data warehouse and your General Ledger system can create an architecture that is fast, efficient and overcomes many of the weaknesses of a Fat GL.
In a later post, we will discuss how some of the challenges of a Fat GL can be addressed in this architecture
: The market value of Financial Derivatives, ESOPS, Properties , Machineries etc need to be disclosed as opposed to current practise of accounting only at historical cost. This would facilitate all stakeholders to assess the correct market value of organization.
Since it is a principles based accounting standard, their may be lack of uniformity in disclosures by companies leading to increased complexity for investor. Investors must adjust themselves to such fluctuations
