Estimates of Chart of Account Elements

Dr. William McCarthy recently asked me, “Can you guess for me: What is the average G/L code block size in small, medium, and large enterprises? And what is the average number of G/L accounts in small, medium, and large enterprises (thousands, millions)?” Below is my answer to this thoughtful question.

Typical General Ledger Chart of Accounts

The following table gives my best guess at what counts would be for the chart of account elements for various size firms.

I don’t have extensive experience in small or medium sized firms, but these counts are what I would expect.

The first two columns are individual values for fields in the Chart. The Nominal Account is the most important element of the chart, as it uniquely identifies what type of balance is being maintained.

The Fully Qualified Chart of Account (COA) is a combination of fields. For example, a partnership might require two fields, one for the nominal account, and another for the partner identifier, more generally called the Legal Entity. This is usually a grouping of accounts for a particularly taxable entity, a partner, a company, etc. In the smallest companies there is only one legal entity. In large organizations there are hundreds of them, and if one goes globally even thousands of them.

Another example field would be cost center, typically a grouping of accounts that are managed for budget or forecasting purposes. In large organizations there can be thousands of these as well.

>>> Related Post: Metric Engine and Data Normalization <<<

The third column is an estimate of the combinations of these fields that are actually assigned to data in what is typically the General Ledger. Although the theoretical possible values will be factorial of the possible values in each of the fields in the chart of account, not all combinations actually occur. For example, certain departments do not manage certain products, so accounts for those products never show up in combination with that department or cost center value.

When the possible value counts become thousands of rows, many of them are set in automated ways through the Accounting Rules Engines.

>>> Related Post: Reference Architecture Interface Layer <<<

Exceptional Examples

On the Large enterprise side, one of the most extensive coding structures I’ve seen is the coding structures mandated by regulatory compliance in financial services in Brazil, where the regulatory chart of accounts is over 100,000 categories and the resulting rows are, if I remember correctly, in the millions for their large banks.  They are things like types of loans, with particular maturity dates, collateral, interest rates, customer types, geographies, etc.

Why a Chart of Accounts

The definition of the Chart is critical in establishing any financial reporting system. It is like a combination table of contents and index to a book; the ledger created will only be able to answer questions that are listed by specific combinations of values in the predefined chart of accounts.

And simply defining a potential value is not helpful if no transaction is ever mapped to that value. As Rick Roth told me once, defining the column headings to a spreadsheet (the field names in the chart of account) takes a little bit of time, and defining the potential values in each one of those columns (domain values) takes longer still. But the real time is consumed in defining the actual combinations of values that are in each row of the spreadsheet. The amount of time spent on this last step dwarfs the other two steps.

>>> Related Post: Metric Engine and the Chart of Accounts <<<

The Chart of Account effectively codifies every financial transaction in an enterprise into one consistent structure. I think this fact has been overlooked as we have built sub-ledgers to manage increasing levels of detail in transaction systems, and the needs for reporting on them, but not increased our ability to combine and analyze these transactions in relationship to the larger enterprise or other types of activity. Reversing this trend would require us to build what I term a Metric Engine.

Consolidated General and Subledgers

One of the key ideas behind a Metric Engine–something which calculates a metric, rather than just a Search Engine–would be to add one more chart of account element, with far-reaching impacts upon the entire reporting structure of the organization. It would be to add a customer/contract identifier (on the revenue accounts), or vendor/contract identifier (on expenses accounts. Note that in banking customers provide deposits and take out loans, so it’s the same identifier on each side). This new chart of account element increases substantially the number of values in a historical General Ledger chart of accounts. But it does not increase the overall number of balances maintained in all ledgers because these elements are maintained in subledgers today.

>>> See the my monograph for an overview of what a Metric Engine is and why it is important: Metric Engine: Reinventing Data Supply Chains for Business <<<

Instrument Ledger Element

My paper, A Proposed Approach to Minimum Costs for Financial System Data Maintenance, notes that the elements by which balances are maintained in the organization (the actual enterprise “chart of accounts”) includes subledger balances. I have built systems for very large organizations which included this customer/contract identifier, effectively adding millions of chart of account element values.

When this is done, effectively the General Ledger, renamed an Instrument Ledger to reflect it very different nature, contains individual customer or vendor Balances Sheets and P&L’s; these can contain enterprise owned balances (like loan loss reserves or other things not shared with the customer). It transforms the way we think about the financial system, while at the same time moving towards a lower overall cost of maintaining financial data.

But in the end, this is a very different chart of account element.

>>> Related Post: Metric Engine and a Detailed Identifier <<<

The following video was released early in the blog series. Many of the above items are touched upon in it. It’s worth a review if you haven’t watched it recently.