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 ﬁnancial information including:
- Assets and liabilities
- Proﬁtability i.e. revenue minus expenses over a given period
- Cash ﬂow: 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 signiﬁcantly inﬂuence 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 ﬁnancial services the structure of the balance sheet is key, in manufacturing the ability to track detailed costs for the purposes of proﬁtability is key. Furthermore accounts together with other objects; e.g. cost centres and proﬁt 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 ﬁnancial 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 ﬁnancial language
- Need for multiple mappings to group accounts
- Extra effort required to interpret accounts
2. CoA does not mirror ﬁnancial and management reporting structure
- (Signiﬁcant) manipulation required during preparation of ﬁnancial 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 ﬁnance 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 ﬁnal numbers’ versus various estimate, ﬂash etc.
7. Excessive number of accounts – excessive use of ‘nice to have’ – excessive detail
- Increased difﬁculties 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 ﬂow of numbers, but lack of contextual information
- The process of recording transactions through to preparing ﬁnancial statements is heavily based on numbers coded with data dimensions, careful consideration needs to be placed on how commentary for business analysis ﬁts with this ﬂow 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 reﬂect 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 deﬁned
- The majority of transactions are automatically posted to the general ledger based on originating entries in business systems e.g. ﬁnancial 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 identiﬁed.
- 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 ﬁnancial language at all levels.
- The CoA is designed in accordance with an overall conceptual data / information model which clearly deﬁnes how accounts vs. other objects work e.g. proﬁt centres, countries, business areas etc.