Chart of accounts optimisation

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.

Insight in finance – the light bulb moment!

Insight is often talked about in Finance, but not always clearly defined. What does it really mean to provide insight and how does this differ from the core role of preparing financial and management reports and accounts?

Let’s Start By Defining The Basics:

Financial reports & accounts: A balance sheet, profit and loss, cash flow and other KPIs which correctly record and value business activities to accepted accounting standards.

Management reports & reports: Additional breakdown of the financial accounts by other dimensions; e.g. product, sales person etc. and other calculated KPIs.

Do these accounts and reports provide insight about a business on their own?

One of the primary purposes of the financial statements is to give analysts and shareholders information to compare companies on a like for like basis.

An expert can read financial statements and gain an understanding of the business e.g. sales, costs, investments, debt, cash etc. However this is limited to a publicly available view of the current state of a business, it would be a stretch to consider it as insight.

What Do We Consider As Insight?

One definition from the Oxford dictionary is, “An accurate and deep understanding.” This is a little abstract. Let’s further say that:

  • Deep means understanding business patterns; having an intuitive view of how business activities translate into financial numbers.
  • It’s not only financial and management balances and KPIs with explanatory comments. It’s something more – advice which leads directly to increased revenue, margin, asset utilisation etc.

What Kind of Analysis do Finance Do

Insight is driven from analysis, so it makes sense to think about the typical types of analysis finance does; common examples include:

  • Review the account postings; apply business knowledge, identity, investigate and resolve errors
  • Review the account postings & balances vs. prior period and plan – to identify and explain unexpected activities
  • Calculate KPIs – review vs. prior period and plan.
  • Develop scenario plans, what if analysis etc.

This analysis brings finance to a clear mechanical description of current business performance, yet it doesn’t on its own cross the boundary into Insight.

A Light Bulb Moment!

Perhaps the best way to think of insight is that it doesn’t come from one report or KPI, but rather it comes from a skilled individual / team using layers of information:

  • An individual or team – with deep knowledge and experience of the business and a critical thinking mind-set
  • Layers of information – validated account balances exist, with overlays of finance generated info – prior period, plan, KPI, trend analysis etc. And further overlay of non-finance data – market analyst, economist etc.
  • A light bulb moment – a leap or a light bulb moment, the individual or team bring together the business context and the layers of information to say, “Ah! We should do this”.

Examples 1: Inconsistent revenue

A company organises market festivals. They have predictable costs, but their revenue varies widely.

  • Deep knowledge – Finance have deep understanding of the business – they know historical performance and what has affected it.
  • Information – Alternative plan versions, monitoring actual performance against it, overlay of economics, weather, news, sales performance etc.
  • Insight – A late spring may affect produce availability and hence cost.

Example 2: Receivables Recovery

A company delivers business services. The demand from clients is highly variable and in addition clients may pay less than agree based on performance:

  • Deep knowledge – Finance understand the services, and the business teams, they have a solid view of factors which affect receivables historically – difficult clients, poorly performing divisions etc.
  • Information – Close monitoring of services provided, outstanding receivables, overlays of performance vs. plan and risk assessments on clients.
  • Insight – The ability to identify high risk receivables and focus attention.

These are basic examples, perhaps not quite Aha – light bulb! Moments, have you come across any great examples of finance insight?

The role of the finance business partner

One of the more forward looking roles in the finance function is the business partner. It’s something that is often talked about in articles, but less commonly seen in real life.

A good place to start thinking about the business partner is with a clear definition, I think the following is a good summary:

  • Finance working alongside business departments;
  • Providing tools, analysis and insight,
  • To make more informed decisions.

Essentially; by being closer to the business, finance skills can be applied to make better decisions. This shouldn’t be considered as something wooly or indistinct. It’s using proven analysis techniques and expert knowledge to spot opportunities to increase sales, improve margin and reduce costs.

It’s not really a new role, but rather part of management accounting

The business partner appears to be positioned as a new role in some articles. However when you dig into the details e.g. using financial analysis, generating insight, making recomendations, it’s seen that most of the technical capabilities that a business partner needs are simply parts of management accounting.

Why then, is there so much focus on the business partner?

The question then is why do we need to talk about business partnering rather than simply management accounting. I think this is because management accounting has failed to deliver decision support in many organisations. Why might this be the case?

  1. Due to the nature of accounting the 1st priority of work is always compliance with legal, statutory and regulatory requirements. Decision support often falls to the bottom of the ‘to do’ list.
  2. Finance sometimes talk in a different language from business counterparts. The finance focus is initially on standards, accuracy, control, stability etc. This view doesn’t always connect well with the business focus on growth.
  3. The education and career path for a finance professional may be more weighted towards classic control topics vs. networking, influencing etc. which are often required to get a seat at the table when it comes to even giving recommendations.

So the difference between management accounting and business partnering may come down to soft skills

While management accounting should cover information and analysis required for management decision making, the gap is likely the aforementioned wider business skills; the business acumen, influencing, probing etc.

A simple model for finance

I would suggest business partnering as being a subset of the management accounting capability, somewhat similar to how financial controllership is a subset of financial accounting capability.

Business Partnering In Detail

I think there is a sliding scale here. Business partnering can be implemented several ways from light touch; as part of a financial controller’s role, to a full blown separate team. A starting point for discussion is to consider which capabilities are included:

  • Management Accounting – handling complex queries, ad hoc requests, special projects e.g. acquisitions support, insight development, fighting decision bias, measuring decision impact, ensuring management information is relevant and utilised, assembling multiple complex information.
  • Planning – forward looking, understands and applies strategic goals, close to execs, business leaders and revenue generators, ability to understanding scenario models and plans.

Critically, in the case of partnering, these are supplemented with:

  • Business – business acumen, commercial environment / curiosity, internal consulting, professional judgement, business strategy, business history, market / product focussed.
  • Interpersonal – relationships, conversations, asking the right questions, challenging people, observation, resilience,

Is the business partner just an ‘interface’ or do they do accounting and analysis. I think this can also be done in several ways.

The most important thing to remember is they are not separate from financial and management accounting. Whether they are an interface or more, they need to be tightly integrated to the complete delivery model.

How Many Business Partners?

As mentioned the business partner may in some cases be the financial controller, or may be a separate role:

  • The most valuable focus is probably on partnering with the revenue generators in the business – so the product or service lines – depending on the business 1 per line or less.
  • From a group perspective the CFO could be considered as the business partner, there may be a need to have dedicated support for them – much like the group financial controller.
  • For shared cost functions, it may make sense to business partner – especially if operating margin is a key focus.

What Are the Risks?

There is genuine value in the business partnering discussion, however there are some risks to consider before implementing:

  • Is it truly partnering? There is an argument that finance is not truly a partner. Finance is a service provider. It might be better received by some businesses to stick to ‘management accounting’ for provision of insight.
  • Despite the talk there seems to be little concrete evidence of finance as a business partner making a measurable impact to business results.
  • A balanced view is important, if there are any issues in basic financial and management reporting (accuracy, transparency, controls etc.) finance will probably deliver more value for money fixing these than focussing on business partnering.
  • If partnering and controllership is in the same role it may cause some conflicts of interest. My personal take is that most finance teams can benefit more by optimising basic reporting and putting an effective model for ‘decision support’ e.g. ad hoc queries, self-service reporting etc. I do however see value in a program of capability enhancement for all of finance to work with a ‘business partner’ mind-set.

Recommended reading

A couple of excellent papers exist on this topic, one from the ICAEW and one from CGMA: