By moving the existing chart of accounts to the new ERP without considering the structure of the original, you risk preserving the same reporting errors the implementation was intended to eliminate. The account numbers may change but the root problem remains unchanged.
The chart of accounts typically looks much like migration data.
Each entry includes an account number; name; a type (asset, liability, equity, income or expense); and a balance. You export this data from your current system. You map each entry to your new system. You import the data.
Technically, that is called a migration.
However, that is not necessarily a good one.
Your legacy chart represents years of decision-making related to how you wanted to present your financials, which employees needed specific pieces of information, and what limitations were present in the prior software. There are many decisions that still make sense today. There are even more that existed simply as workarounds.
So, if you replicate all of these in the new ERP, then it will inherit the same workarounds.
The old chart was designed around old constraints
Old charts rarely get complicated simply because someone deliberately designed them that way. They grow over time.
For example, when a new office opens, you create a new expense account for that office. As additional offices open, you add new expense accounts for those offices. Later on, a product manager requests different revenue reporting options so they create additional sets of accounts.
Eventually, you end up creating multiple combinations of department, geographic area, products and transaction types as separate accounts.
At this point the chart is doing more than just describing accounting activities. It is now being used as a vehicle to track reporting dimensions. This may have been required for your old system. However, your new ERP may be able to store departments, locations, projects, entities, classes or other reporting dimensions natively. Therefore, replicating those combinations within the new ERP as separate accounts would essentially waste that native structure.
Therefore, you have migrated the constraint rather than migrating your data.
Mapping accounts should begin with your reports
In most cases, the source chart serves as the starting point for mapping exercises. For example:
- Account 61010 maps to account 6010.
- Account 61020 maps to account 6020.
- Repeat this process until each source account has somewhere to map.
Answering this question provides information regarding where your old data will reside.
It does not provide insight into whether the new structure can produce the reports your business requires.
Begin with those reports.
- What should appear on the P&L?
- Which areas of the organization should be viewable by entity, department or product?
- What numbers should appear monthly on the board's report?
- What does finance build today using systems outside of accounting due to the ledger's inability to generate it?
Work backwards after answering these questions.
Your target chart should allow you to generate those reports without having to recreate each historical workaround.
Success in mapping is not defined by finding a corresponding account for each old account. Success in mapping is defined by ensuring every significant economic event still correctly lands in a valid location.
Most one-to-many mappings are easier than many-to-one mappings
Let's say your legacy chart contained twelve travel accounts because every office had their own version of a travel account.
Now let's assume the new ERP supports “location” as a reporting dimension. In this case, those twelve travel accounts can become a single travel account.
That is easy to accomplish. Since the legacy transactions included enough identifying information via either source account or vendor identification to determine which office was responsible for each transaction, splitting the single account into multiple accounts is unnecessary.
Conversely, splitting one old account into multiple new accounts is harder.
Assume your legacy system placed software subscriptions; professional services; and equipment rental costs into one generic account. Now assume the new chart separates those items into individual accounts.
There is no direct method to resolve this issue at an account level. Someone will have to review the transactions.
Reviewing vendors will likely give insight into some transactions. Reviewing descriptions will provide insight into others. Reviewing purchase order information may provide insight into some transactions. Unfortunately, reviewing remaining transactions will require manual inspection.
Therefore, it is clear that while chart design and data migration represent two distinct work streams, a clean design can result in a more complex historical mapping exercise.
This complexity is not an argument against designing a clean chart. It is an argument to find out about potential complexities early and address them accordingly.
History has to work after the redesign
When you move to a new chart you may end up creating a fantastic current-year profit/loss but ultimately fail finance in your first month.
This issue arises when somebody asks for a year over year comparison. If last year's activities remain organized under the original structure and this year's activities use the new structure then there will need to be a second layer of mapping for all comparisons. Ultimately, finance will have to go back to using spreadsheets again.
Therefore, the migration plan must include something more than simply bringing open balances forward. For each time period that the organization wants to bring forward, they must decide:
- Which old accounts merge into new accounts?
- What portions of the old accounts require detailed split transactions?
- Can historical dimensional attributes be reliably rebuilt?
- Are there certain historical aspects that could not possibly be recreated?
- How will total values that were created during the migration compare to their original values in the legacy source system?
- Who authorizes the uncertain mapping decisions?
You do not have to provide a high level of detail for every single year of historical data. However, you should make these types of decisions deliberately. Saying “we'll just keep the old system for history” seems like an easy way out; however, once an audit, board inquiry or variance analysis is required that utilizes both systems simultaneously, it will no longer seem so easy.
Inactive accounts create another potential trap
Don't migrate inactive accounts. Problem solved.
In some cases this is absolutely true.
However, an unused account can potentially hold significant historical value. An old account could show up within a previous period financial statement or aid in explaining an older balance. Unused accounts could also reference other systems through integrations or recurring reports that nobody properly documented.
Your question should not solely revolve around if an account is currently used.
Rather ask yourself why the account exists. Then classify it. Retain it. Consolidate it. Terminate it. Only retain it in historical mapping.
Making this determination ahead of loading the data will take longer than migrating everything initially. Cleaning it afterwards will be even worse.
Where this argument is weak
Every Enterprise Resource Planning (ERP) project does not need a chart redesign. There exist businesses with charts that are relatively small, structured and fit very well into a new system. Changing the chart for the sake of changing it creates additional reconciliation effort.
There are also migrations where speed is a greater priority than redesign. In order to first stabilize the general ledger of a distressed implementation, a larger restructuring can occur later.
That can be acceptable.
The error lies in treating “Copy the Chart Now” as a neutral decision.
Regardless of how much planning was involved with this decision, it still represents a design choice. It signifies acceptance of the current charting strategy – complete with its advantages and disadvantages.
The chart should be migrated last, conceptually
Although the chart is one of the first things loaded technologically because transactions rely upon it, it should be conceptualized as the last thing to be migrated.
First, determine what type of reporting the company needs. Determine which pieces of information belong in accounts versus those in dimensions. Determine what portion(s) of historical data must continue to be comparable.
Next, construct your target chart. Afterward, begin mapping your existing chart onto your target chart.
A new ERP can process transactions more quickly than the current one, automatically approve transactions and offer better reporting capabilities. Regardless of which features a new ERP provides, none of these will help you fix your chart's poor description of the business.
If you merely copy the old chart without making changes, the technical success of your implementation may allow you to report problems successfully while leaving your reporting issues unaddressed.