A 500 Year Old Idea

To fully appreciate the Chart of Accounts (CoA) it’s worthwhile to step back 500 years to the invention of double entry book keeping.

Double entry is a revolutionary way to record business transactions and track key financial information including:

• Assets and liabilities
• Profitability i.e. revenue minus expenses over a given period
• Cash flow: cash received minus cash spent over a given period.

Double entry involves recording each transaction from two perspectives which are equal and opposite.

An example; in manufacturing a raw material is received from a supplier, this is a business transaction which increases inventory (asset) and increases a supplier balance (liability). Other examples utilise further account categories:

• Assets, liabilities, equities
• Revenue, expenses
• Gains, losses

The sum of the accounts in these categories constitute the CoA. This is a key structure in business with the ability to succinctly describe the day to day operations of an enterprise.

That Created a Monster

What started from seven categories of accounts, has grown over the years in number and complexity to hundreds or in some cases thousands of accounts at medium and large sized enterprises.

• As trade grew in volume the need to break up business transactions into more and more detailed categories for analysis and reporting grew
• With the advent and increase in statutory and regulatory reporting a number of mandated categories of reporting appeared
• With the development of enterprise systems the ability to capture more transactional detail and run higher volume transactional businesses evolved and these systems came to significantly influence how the CoA works.

The level of detail and structure of the CoA is a basis for corporate reporting and decision making, therefore it’s key to ensure the CoA matches the focus of the enterprise. In financial services the structure of the balance sheet is key, in manufacturing the ability to track detailed costs for the purposes of profitability is key. Furthermore accounts together with other objects; e.g. cost centres and profit centres, are used to manage the performance of departments and divisions and can affect the behaviour of management. This all highlights how seriously CoA design and governance should be taken.

A Few Technicalities

Chart of Accounts – Usually refers to a full set of accounts set up for one or more legal entities in an organisation. Accounts included will depend on business activities and the reporting location. Note – some countries have mandated account names and numbers for local reporting.

Group Chart of Accounts – For enterprises that consist of more than one legal entity consolidated reporting is required, this usually requires less detail than individual legal entity reporting and therefore a group chart of accounts is used which may have a many to 1 mapping from legal entity to group chart of accounts. Note – it’s common to see account naming conventions such as XXXXYYYY as the full account name where XXXX is the group level account.

Local Chart of Accounts – In some multi-national enterprises a standardised international chart of accounts is used according to IFRS or their home country GAAP, however local statutory bodies in individual countries may mandate certain accounts or valuation methods. In this case multi-nationals need to be able to produce two sets of financial statements based on standard and local accounts.

GL Code Block – The term general ledger (GL) is more or less synonymous with chart of accounts. When you post a transaction to a general ledger account e.g. say 100 USD to sales, more information than just 100 is recorded, initially the currency ‘USD’ and whether it’s a debit or credit. In addition to this many additional dimensions can be captured, the full list of dimensions captured with a general ledger posting is referred to as the GL code block. Note – while this is a technical name from the applications world, the conceptual design of the dimensions captured on GL postings is key in complex modern businesses.

Factors of Poor CoA Design and Governance

The CoA is has a far reaching impact on the enterprise, the list of design considerations, pain points are often unique to the industry and ‘current state’ of processes, systems and reporting, however it’s useful to look at some common examples:

1. More than one CoA (due to decentralised business model / acquisitions etc.)

• Lack of standard financial language
• Need for multiple mappings to group accounts
• Extra effort required to interpret accounts

2. CoA does not mirror financial and management reporting structure

• (Significant) manipulation required during preparation of financial and management reports (manual or automated)

3. Lack of detailed policy and guidelines on accounts

• Transactions entered against inappropriate accounts; statutory reporting misleading or business performance misinterpreted
• Incorrect valuation methods, approvals, materiality limits etc. applied to certain postings

4. Accounts not governed to meet changing requirements

• New statutory or regulatory requirements met using workarounds with existing accounts
• No longer required accounts still used – missed opportunity to streamline transaction capture, close and reporting

5. Different CoA accross different systems

• No ability to ‘drill down’ from consolidated reports to originating transactions – increased time and reduced transparency to queries

6. CoA not used as ‘main basis’ for management and regulatory reporting as well as statutory

• As the CoA is primarily finance owned (statutory), management and regulatory reporting needs are given secondary status:
  • Parallel similar structures maintained in management reporting tools
  • Effort to reconcile statutory, management and regulatory numbers
  • Potential confusion between stakeholders on ‘correct final numbers’ versus various estimate, flash etc.

7. Excessive number of accounts – excessive use of ‘nice to have’ – excessive detail

• Increased difficulties in:
  • identifying right account for posting
  • maintaining controls and policy
  • interpreting account balances

8. Account design based on systems

• Software houses are not experts in the structure of individual businesses, systems driven structures can be ineffective for reporting and decision making. Start with system agnostic conceptual designs.

9. Effective flow of numbers, but lack of contextual information

• The process of recording transactions through to preparing financial statements is heavily based on numbers coded with data dimensions, careful consideration needs to be placed on how commentary for business analysis fits with this flow on key transactions.

9. Extent of usage of GL code block

• There is a trade off between simplicity of the GL for maintenance and number of dimensions populated in the GL code block. For example for any dimension that full accounts are required e.g. legal entity, business segment they have to be in the GL, for other dimensions are they best in the GL or in other reporting.

CoA Good Practice

Discussion of ‘best practice’ are not necessarily useful based on the different requirements across enterprises by industry, size, focus etc.

And with the 80/20 rule in mind it’s often better to focus on eliminating major pain points and pursuing the more obvious elements of ‘good practice’. With that in mind, a few examples of good practice include:

• The volume of accounts reflect a sensible view of level of detail that needs to be captured in order to meet statutory and regulatory requirements and support the management and regulatory processes
• The usage and control requirements of each account is clearly defined
• The majority of transactions are automatically posted to the general ledger based on originating entries in business systems e.g. financial trades, invoices etc.
• Use of manual accounts are minimised
• Use of reconciliation accounts are minimised to those truly required
• The Chart of Accounts and associated GL code block has a systems agnostic basis meaning that any change to the IT landscape does not lead to extra complexity and acquisitions and divestitures can be easily handled
• A clear strategy should be in place to handle multiple valuation methods e.g. different depreciation rules in different countries. Depending on systems there are various approaches from multiple accounts to multiple ledgers, as this adds complexity the right solution should be carefully identified.
• A limited number of manual adjustments at period end close. Adjustments logged and reason for adjustment clearly documented. Accounting policy and CoA design constantly reviewed in order to reduce required adjustments.
• Group and operational CoA closely aligned, similar financial language at all levels.
• The CoA is designed in accordance with an overall conceptual data / information model which clearly defines how accounts vs. other objects work e.g. profit centres, countries, business areas etc.