The map is not the territory – Setting up a Chart of Accounts

Accounting is a numerical history of a business.  We summarize the millions of transactions into a cogent one page document that tells the status of the business. The financial statements however, are not the same as the business. Alfred Korzybski said that “the map is not the territory”, referring to the object and its’ representation.  A financial statement summarizes, and a summary leaves out details.  Tracking which data goes where is the job of the general ledger and chart of accounts.

The core of reporting is the chart of accounts.  Financial statements summarize sales into one line.  Accounting might have half a dozen sales accounts and hundreds of departments, which all roll up to one single number – sales.  These accounts are used to better understand the summarized information.  Sales are reported net of returns, but accounting departments track the returns in a separate account so that department heads can see if return rate is trending up or down.  If your ERP or sales software tracks returns, you probably don’t need a separate account for tracking that information.

However, accounts seem to proliferate.  Charts of accounts grow over time – someone wants to know some summary fact of the business and the systems that generate that data don’t supply the summarized data to management.  Commonly at retailers it is a POS (Point of Sale) system that runs the cash registers and reports summary data to a sales data warehouse or general ledger.   Usually they only report data to the general ledger, so operating data is sourced from accounting records.

In an e-commerce firm it is the order entry and fulfillment systems, which may not be connected with purchasing or payroll systems.  In addition, management has come to rely on the controls put in place in a general ledger system.  In the 1990s we used a lot of database query tools that would often give different answers based on query design, so one meeting might have three different set of numbers based on who’d written the query.

The use of data warehouses should decrease demand for general ledger detail.  Sales splits can be done in more detail using a database with all the relevant sales data, rather than the general ledger which might contain only weekly summary data.  However as the needs of the company change, often it is easier to just add an account number than reconfigure a reporting system.  Data warehouses – an idea that dates back 20 years – still don’t function as well as they should.  So the g/l becomes a stand in.

I’ve typically used a couple of hundred “natural” accounts for businesses from $5m to $500b in revenue.  An account like “sales” or “payroll” are called natural accounts.  These are modified by department code and sometimes other codes for cost accounting or for projects.  This can result in thousands of combinations.  In a typical retailer with 100 stores they would support 60-70 natural accounts, for 6-7,000 combinations.  Add in district and regional codes you could reach another 1-2,000 combinations. Designed right that level of detail is easily handled by your accounting team.  Designed wrong and you spend hours trying to reconcile the source systems to the general ledger.  Which adds cost without benefit.

Manufacturers sometimes have additional codes for production cost allocations.  If you are running the same line in two buildings, under one department, you might also use a location code.  All these codes end up making a chart of accounts pretty complicated.  This is worsened if you end up layering on the complexity as you go, rather than plan it in.   Knowing going in you will likely need a location or a production line code and planning for it makes a big difference later.

Much of the complexity of the chart of accounts depends on what information you will want to retrieve.  Simple natural accounts and department codes can get a business a long way.  Accounting codes begin to change if you are running project-level or fund accounting.  Sometimes you can keep the reporting structure out of the chart of accounts.  For instance, if you have a district manager with 10 units, you likely don’t track the district code in each transaction, but roll up the district report by selecting which units are in a district when you summarize the data.  This is the default mode for most firms who report with excel.  Changing the unit roll-up when a district manager leaves the firm is not Excel’s strength.  Excel’s data summarization and analytical tools have improved, but realistically, converting from a trial balance to report is an area ripe for errors.

If you have online reports, managing the access in an ERP system can be a hassle, unless you have some hierarchy built into the system.  Imagine allocating 600 units amongst 60 district and 10 regional managers?  If each of the units had an assigned district and regional code, the reporting would be much easier to manage and control.  With the rise of reporting dashboards, this feature is almost always built in.

The general ledger and financial statements are summaries but useful ones, where similar data is grouped, analyzed and decisions can be made.  Too big a chart of accounts and you will spend hours managing complexity rather than providing information.  Too small a chart and you will your time breaking out the details you need. A map is a representation of a territory which can be held in your hand and used to navigate.  Good design and a thought for the future of the business will help develop a solid organization for your accounting data so that it will supply you the information you need to navigate.

***

Dr. John Zott is the Principal consultant at Bates Creek Consulting. John is the chair of the Careers Committee at FEI Silicon Valley, a senior adjunct professor at Golden Gate University and comments regularly on issues that affect consumer businesses.  If you are looking for a CFO for your e-commerce/retail/consumer company, or are a former student, colleague or would just like to connect – reach out.