When charities are in the process of implementing a new finance system, one of the major areas for consideration must be the chart of accounts (COA) and its structure.

The older a finance system is, the more likely is that the COA has become muddled, with accounts which are not used any more still available to be posted against or account structures not being used how they should. In some more extreme cases, COA tables could be thousands of codes long, of which only a fraction are actually used.

A well thought out COA within an enterprise resource planning (ERP) system will enable users to easily develop and obtain key analytics on organisational performance on both a summarised and detailed transactional level for areas such as:

• Structured statement of financial activity (SoFA) reports.
• Multiple-company and consolidation.
• Income and cost trend analysis.
• Award and grant analysis.
• Budget management.
• Internal reporting considerations.

A change of finance system provides organisations with the perfect opportunity to review the existing chart and consolidate/redesign to facilitate any changes within the organisation since the last COA review. There is no getting away from the fact that this task isn’t quick and can be extremely resource intensive as your organisation thinks of what changes are needed to not only suit requirements short term, but also to give flexibility in the medium and long term. This isn’t something that anyone wants to be doing on a regular basis. However, get it right, and you will clear any historical reporting issues you may have experienced.

From several years of implementing financial systems within the charity and not-for-profit sector, we would offer a number of observations in relation to creating a COA structure when you move to a new ERP system.

Structured SoFA reporting

Before designing a new COA, always refer to the final SoFA report output to ascertain what must be considered in the overall structure. Newer ERP systems, for example, try and promote a smaller COA with the use of dimensions or analysis codes at transactional line level to give more segmented analysis. Examples of this would be fund type and department.

Within the COA itself, best practice would be to use sub-categories or parent/child relationships to group individual account codes into the relevant headings within the SoFA report itself. These roll ups will allow organisations to see summarised groupings of account codes, but also the individual balances themselves as shown on page 186.

Multiple-company and consolidation

Although many organisations have a group structure with consolidation requirements, quite often multi-company structures allow each company to devise their own COA resulting in consolidation being more complex than it should be.

Modern ERP systems, as well as modern reporting/analytics platforms, no longer require any part of the COA to denote which company a transaction relates to, as intercompany modules now form part of a standard product. This means that in many ways it makes complete sense to have the same COA structure across all of an organisation’s companies, cascading down from the top-level consolidation company throughout the whole organisational structure.

Taking this approach not only results in consistency across all of the companies in the group structure, but also makes reporting and consolidation processes so much easier, saving you time and money on complex mapping processes to provide consolidated financial statements.

Income and cost trend analysis

When thinking about income and expense matching, organisations should consider how to use their COA numbering sequence in a logical way, while always leaving room to grow and add in further codes without causing any reporting disruption.

Where possible, structure COA codes accordingly and with the same numbering sequence. For example, revenue codes can all begin with the same number (eg 1****); likewise, for costs (2****) and expenses (3****). Matching income/expenditure codes can be structured using common values for the remainder of the code – for example, the code for “shop sales revenue” might be 10001 with “shop sales cost” as 20001.

This approach can be implemented across an organisation’s whole income statement and balance sheet, therefore allowing users to match the end codes and produce mini–income statements for each revenue type quickly to see the trends over chosen accounting periods.

Award and grant analysis

Many organisations manage their grants and awards in separate systems, with only basic financial data coming into the ERP system due to the sensitivity of data being held and approval processes for the agreement of any award/grant payments.

However, dependent on how many grant/award types your organisation may have will depend on how this is reflected within a COA structure. Organisations are more commonly wanting to report on timelines between when a contact applies for a grant/award and when this is hitting the organisation’s income statement.

Reflecting the different kinds of grants and awards within your COA structure (using the subcategories as mentioned above) will allow report users to see not only the total amount of awards and grants hitting the financial statements each month, but also will provide them with the drill down capability to see this value broken down further by type.

Budget management

Another essential consideration when developing a successful COA structure is ensuring that internal budgetary control is easy to manage. Quite often, budget holders are not financial people and do not come from a financial background, so the reports provided to them need to be as simple as possible from a structure point of view. The sub-categories and roll ups as discussed previously will provide simplified data for budget holders, but this is still very dependent on the COA structure being such that if a budget holder only has an “expense budget”, then they do not have to see anything other than the expense codes within the COA. This is much easier to do when organisations have the expense codes all prefixed in the same way than if codes were a mix and match of numbers.

Internal reporting considerations

Although external reporting is, and should be, at the forefront of your mind when thinking about any new implementations, you should not disregard internal reporting when it comes to creating a new COA structure.

As mentioned previously, some newer ERP systems enable a smaller COA with other ways to tag transactions by the likes of fund type and department. So in these systems it does allow for more thought to be directed towards internal day-to-day reporting requirements and where the COA can provide more deeper analysis than your current system.

An example of this can be seen in something as simple as expenses. Some customers have just one “travel and expenses” code in their COA, whereas others have different types such as hotels, meals, parking etc to provide more granular analysis. However, when asked to split these codes by type of claimant, this becomes more difficult and very resource intensive.

If this level of reporting is required, the COA should reflect this, with the potential to hold codes for employee, volunteer and trustee expenses, all with similar coding structures, and all potentially under an overall category of expenses – therefore giving organisations all levels of expense reporting, and specific values on the three claimant types.

In summary

The COA drives all business transactions and reporting requirements, both internally and externally, and there is no right or wrong way of creating a new structure; it is completely dependent on specific organisational needs.

The key element within the whole process is to keep it simple and structured. Try to avoid having numbering sequences that do not flow within an income statement or balance sheet.

It is essential not to limit yourself when creating your COA. Always leave room within the coding structure for growth or organisational change and try to avoid adopting a different approach for internal reporting compared to your external and statutory reporting requirements.

By using the techniques and guidance provided above, you should be able to meet all internal and external reporting requirements and any future growth.

Daniel Booth is ERP product manager at m-hance

Charity Finance wishes to thank m-hance for its support with this article.