Every ERP migration has a moment when someone from the implementer sends the finance team a spreadsheet with two columns, old account and new account, and asks for it back by Friday. That spreadsheet decides whether the company will still be able to answer questions about its own past. It is the finance team's job, it cannot be delegated to the software vendor, and it is almost never given the time it needs.
What follows is the way we run it on client migrations, whether the move is from an older local accounting package into a mid-market ERP, or off a group SAP after a sale.
Decide first whether you are moving the chart or replacing it
These are two different projects and they are often confused. A move keeps the structure and changes the codes, so history maps one to one and the new system simply continues the old one. A replacement lets the new system's dimensions, cost centres, projects, entities and segments, take over the work that old sub-accounts used to do. Most companies leaving an older package are doing a replacement whether they admit it or not, because the old chart encoded departments, branches and even customers in the account number, and the new system will not want them there.
Decide which one you are doing, in writing, before anyone starts mapping. A replacement with a one-to-one mapping mindset produces a new chart that looks exactly like the old one, with all its faults carried across at considerable expense.
The mapping table is the deliverable
Two columns are not enough. The table that survives an audit has the old code and name, the new code and name, the type of mapping, and a rule. Many old accounts to one new account is easy and loses nothing. One old account to many new ones is where history disappears, because a historic balance cannot be split without a rule, and the rule usually needs information the old system never captured. Where that is the case, be honest: the balance goes to a clearly labelled legacy account and stays there, and the note says why.
Two habits pay for themselves. Keep the old account code as an attribute on the new account, or in a reference field, so anyone can search the old number for the next five years. And give every line of the table an owner, so that when the auditor asks in March why account 5210 became three accounts, there is a name and not a shrug.
Cut over on one date, from one trial balance, with one reconciliation
Choose a cut-over date that is a period end, and if at all possible a year end, because the audited balance sheet then becomes the opening balance and the auditor's sign-off becomes your reconciliation. Load the closing trial balance of the old system as the opening balance of the new one, through the mapping table, and reconcile to the baht: old closing balance, mapped balance and new opening balance must agree, and the sub-ledgers, receivables ageing, payables ageing, fixed asset register, inventory and bank, must agree to their control accounts on both sides.
Keep that reconciliation file. It is the single document the auditor, and later the Revenue Department, will ask for when they want to know that nothing fell between the two systems.
What to do with the history
There are three honest options and one dishonest one.
The first is to load balances only: monthly closing balances for each mapped account for the prior two or three years, so that comparatives and trends exist in the new system, while the transactions stay in the old one. It is the cheapest and it is usually enough.
The second is to load transactions in full. It is expensive, the old transactions carry attributes the new system does not understand, and it is only worth doing when the business genuinely needs transaction-level reporting across the boundary, such as customer margin history for a sales team.
The third is to keep the old system readable: a licence kept alive in read-only mode, or a complete export of the database and the standard reports in a form that an auditor can open without the software. This is the option people forget to budget for.
The dishonest option is a backup file on a server that nobody can open. Under the Accounting Act, accounting records and their supporting documents must be kept for at least five years from the closing date, and longer when a tax assessment is open. Kept means readable: someone must be able to produce the 2023 ledger by account, with the documents behind it, on request. A file that needs a system you no longer have does not meet that test.
The Thai filings tell you what the new chart must produce
Unlike Vietnam, Thailand does not prescribe a chart of accounts. What it prescribes is outputs: the corporate income tax return, the monthly VAT return, the withholding tax returns, the financial statements filed with the Department of Business Development in its electronic format, and the auditor's presentation. So the test of a new chart runs backwards from those forms. Can every line of the tax return and every box of the VAT return be produced from the new accounts and tax codes without a manual reclassification? If the implementer designs the chart first and bolts the tax mapping on afterwards, the finance team will be posting reclassification journals every month for years.
A few things must exist as accounts or dimensions from day one, not be added later: output VAT and input VAT with undue VAT separated, withholding tax receivable and payable by type, and for a BOI-promoted company the segregation between promoted and non-promoted activity, which cannot be reconstructed after the fact.
Leaving SAP is a special case
When the question is how to move off SAP, it is usually a subsidiary leaving a group system after a sale, or a company stepping down to a mid-market product. Two traps are specific to it. The chart in SAP belongs to the group and is built around company codes, profit centres and cost elements; the local statutory chart underneath it may never have existed as a separate thing, so it has to be designed rather than migrated. And the history in SAP belongs to the group. Get the extracts before access ends: general ledger line items, open items, the asset register, the tax reports, in formats readable without SAP. Six months after the sale, nobody on the group side will do it for you.
Who does what
The implementer configures the software. Finance owns the mapping table, the cut-over reconciliation, the decision on history and the first three closes in the new system. That is the division of labour that works, and it is the reason we describe our role on an ERP project as the finance side of the migration rather than the implementation. If you are about to sign with an implementer, or have just gone live and the first close is not coming together, the free health check is the quickest way to see where the gaps are.
Written by Jérôme Le Louer, Managing Partner at SmeCFO.