How your chart of accounts should be designed for hybrid ERP software

Consultant and ERP expert Joshua Dickens explains why you should turn away from textbook approaches to designing a chart of accounts


Executives attempting to implement their first hybrid cloud enterprise resource planning (ERP) software commonly ask what is a low-risk module with which to start. The leading research firms have spoken: Systems of record are a safe bet. In financial ERP, this makes the general ledger (GL) module a good candidate for the cloud. Although the GL serves, in one sense, as a foundation of your entire financial ERP, the discrete functions within this module tend toward homogeneity across enterprises.

The processes for managing budgets, forecasts, accounting periods, journal entries and financial statements tend to be pretty much the same across verticals. This makes some sense; the rules are codified into general accepted accounting procedures (GAAP) and international financial reporting standards (IFRS). Such standards make it seem likely on paper that a robust GL module in any cloud software-as-a-service (SaaS) financial ERP system will meet your company's needs.

Here is what happens in reality: Despite the fact that every company is running the same GL playbook governed by GAAP or IFRS, the plays they call often differ. One stark difference is the chart of accounts (COA). Even though financial transactions ultimately roll up into the same financial statements, individual companies get very creative with their COA; defining COA has always been a key milestone of GL implementations.

Why COA design is often poor

When it is done poorly, this COA design a stumbling block for the entire GL. Because hybrid ERP favors turnkey solutions, the software vendors tend toward minimal, boilerplate guidance to defining a COA. This is where implementation consultancies are meant to come in: They promise to couple their own familiarity with the software-of-choice with some practical method for choosing a company's ideal COA structure.

In real life, the resultant COA design tends to take one of two approaches, neither of which work very well.

The first is the textbook approach. The implementation partner explains to the stakeholders the intended use of each COA dimension the software vendor offers. Between the consultants' and stakeholders' shared knowledge, they are able to derive which of these dimensions are appropriate to support the GL of the company. In so doing, they intentionally disregard the current COA, since textbooks favor forward-looking analyses in lieu of doing things the way they have always been done. Once the design team lands on a set of COA fields to use, they proceed to define values for each field. Then comes the process of mapping these values to the COA values in the existing system. This crosswalk is necessary both as a completeness check and as a tool for converting data.

Why does the textbook approach fail? Sometimes the right stakeholders do not have the bandwidth to design their new COA from the ground up. Sometimes the people who best understand the current COA lack the skills to build an ideal new COA from scratch. On some projects the consultants really do not offer enough extra knowledge produce an ideal new COA from scratch, let alone cross-walk it.

Even when the right people are at hand, the textbook approach takes a lot of time and offers very few guardrails. As a result, it is expensive, risky and prone to error. For these reasons, the textbook approach usually does not happen.

Instead, many projects attempt the antithesis of the textbook approach. In these cases, the software vendor or implementor chucks a spreadsheet over the wall with a list of the new system's COA fields and wishes the stakeholders good luck. The stakeholders take their current COA and hunt for whichever fields sound the same in the new system. Once each of their current COA fields is mapped to a field in the new system, they proceed to cross-walk the values.

This method is quicker than the textbook approach, but it risks overlooking functionality in the new system. It pretty much takes the current COA and moves it to a new geography. Any problems with the current design are carried forward, while the benefits of the new system get overlooked.

Start with the crosswalk

Luckily, there is an alternative that solves the problems inherent to the overly ambitious textbook approach and the sloppy shortcut approach: Do not end with the crosswalk; start with it.

Take each of your current COA fields and ask yourself to define the function of this dimension. No judgement – just ask yourself what it is meant to do. Do this for each dimension and then look at the full set of dimensions. Ask if any of them are redundant. If so, indicate that you might eliminate them.

Now ask if there are any other meaningful dimensions missing. Put any that you have discussed (but not implemented) in this list. Now you have a reasonable model of your new ledger fields. Only at this point, look at the COA fields in your new system. Your consultants can help a lot at this point, and you will be on better footing to understand their advice. Look for fields that match the definition of your existing fields. Once you have mapped them all, look at the available new fields and see if any of those fields trigger ideas of useful dimensions you might have overlooked.

By using this approach, you will have capitalized on the functionality of your new hybrid cloud ERP while respecting the value in your current system – a fine reason to implement ERP in the first place.

The death of itunes cloud investment from microsoft google and oracle and uber and amazon takes flight small

Read next:

Weekend update: The death of iTunes, cloud investment from Microsoft, Google and Oracle, and Uber and Amazon takes flight