It's August. The new ERP went live six months ago. The steering committee has been dissolved, the implementation partner has sent its final invoice, and the project was closed as a success.
Then you open the system. Three thousand five hundred sales invoices from April to July are still sitting in draft. The bank account in the ledger shows minus fifteen million baht. Customer payments float unmatched against invoices nobody can find. The opening balances don't agree with last year's audited financial statements, and the auditor is already asking why.
This isn't a disaster story. It's what I see, in one form or another, in most of the ERP migrations I'm called into: moves onto Dynamics 365, Xero and Odoo, moves off local packages like Formula, and companies leaving Excel behind for the first time. Different systems, different industries, the same picture six months after go-live. I have been called into more than a dozen of these over the past decade, and I can count on one hand the ones where the books were clean at six months. The software is rarely the problem. What fails is everything around it.
Go-live is where the risk starts, not where it ends
An implementation project is judged on one date: go-live. The consultant is paid to get there, and once the system is switched on the project is declared done. The real test comes after: the first month-end close, the first VAT return, the first audit. By then the consultants have moved to their next client.
That's the core of the problem. Nobody inside the company owns the system once the consultants leave. The implementer configured it and the finance team uses it, but nobody took the ball. So every small configuration error, every half-migrated master file and every undocumented workaround becomes permanent.
It's a change management project that happens to involve software
An ERP is not an accounting tool. It sits across the whole flow of data and money: how an order becomes an invoice, how an invoice becomes a receivable, how a payment gets matched, how a supplier bill gets approved and paid, how the bank gets reconciled. Change the system and you change every one of those processes.
Most companies install the new software and keep the old habits. The accounting team runs the same routines they ran in the old system, in the same order, with the same spreadsheets on the side. Those routines were built for a different logic. In the new system they don't work, or they half work, which is worse. The result is the opposite of what the project promised: more manual work, more rework, and a team that is slower than before go-live.
The fix is not glamorous. Every key process needs a written procedure, even a simple one: who raises the invoice, who confirms it, when payments are matched, who reconciles the bank and by which day. One page per process is enough. In most migrations I review, not one of those pages exists.
Nobody has the time to do it properly
Thai SME finance teams are lean. During a migration they still have to close the month, file VAT, pay suppliers and answer the auditor. Nobody has spare hours for data cleansing, testing or learning new workflows, so the shortcuts get built in from day one.
After go-live it gets worse. Everyone is running behind the books. Each month the backlog grows, and the team can only just keep up with the current period. Nobody is left to go back and fix the past. The problems from April are still there in August because nobody has had a single free day to look at them.
What it looks like six months in
These are the issues I find most often, and usually several at the same time:
- Sales invoices stuck in draft. Thousands of invoices created but never posted. Revenue and receivables in the ledger are understated, the aged receivables report is meaningless, and nobody can tell a customer what they actually owe.
- Due dates not configured. Payment terms didn't migrate properly, so every invoice shows the wrong due date. Collections follow-up stops working and the cash forecast is fiction.
- A chart of accounts that was never finished. Accounts missing, others duplicated, some too broad to be useful. Transactions get parked in whatever account is closest, and the monthly P&L can't be compared with last year's.
- No bank reconciliation. Not for one month, but for several. The bank account in the system shows minus fifteen million baht, while the real account is nowhere near that. The gap is made of payments posted without their matching receipts, duplicates and transactions nobody recognises.
- Payments not matched to invoices. Customers have paid, but the receipts sit on account instead of against the invoice. The same customer appears to owe and to be in credit at the same time.
- Opening balances that don't reconcile with the audited financial statements. The starting point of the new system doesn't agree with the last signed accounts. Until it does, nothing built on top of it can be trusted, and the auditor will say so.
- Duplicate supplier and customer master data. The same supplier created three times, some without a tax ID or branch number. That matters in Thailand, where a tax invoice without the right details can cost you the input VAT.
- Withholding tax handled outside the system. Withholding tax certificates (50 ทวิ) are still typed in Word or Excel, so the monthly ภ.ง.ด.3 and ภ.ง.ด.53 filings no longer tie to the ledger.
- The VAT return prepared from a spreadsheet. Because the ERP's VAT report doesn't match what the Revenue Department expects, the team rebuilds the ภ.พ.30 by hand every month. The system and the tax return now tell two different stories.
Thai tax is where large ERPs are weakest
Global ERPs are built for global requirements. Thai tax has its own logic: monthly VAT returns, tax invoice format and numbering rules, withholding tax at different rates by type of payment, certificates for every deduction, and e-Tax invoices on top. Many large systems handle this through local add-ons or partner customisations that were never fully tested against a real filing.
The problem rarely shows up in the demo. It shows up on the first filing deadline, when the report the system produces doesn't match the form the Revenue Department wants. From then on the team keeps a parallel spreadsheet, and the ERP stops being the single source of truth it was bought to be.
When the books fall behind, the consequences go beyond tax. The audit slips, the financial statements are filed late with the Department of Business Development, and the penalties follow. A system project has become a compliance problem.
What good looks like
Migrations that work have a few things in common:
- An internal owner, named before the project starts. Someone who will still be there after the consultants leave, with the authority to change processes, not just use the system.
- Extra capacity during and after the migration. You can't ask a team at 100% to run the business and rebuild it at the same time. Budget for temporary support before you need it.
- Written processes for the new system. One page each for billing, collections, payables, bank reconciliation and month-end close, written for how the new system works, not the old one.
- Thai tax outputs tested before go-live. Run last month's VAT return and withholding tax filings through the new system and compare them line by line with what was actually filed.
- Senior finance cover for the first three closes. That's where the configuration errors surface, and where they're cheapest to fix.
If yours has already gone wrong
Most companies don't call anyone before the migration. They call when the books are six months behind and the auditor is waiting. That's the work we do most often: take the backlog off the team so they can run the current month, rebuild the past, and hand back a system that closes on time.
The sequence is always the same. Tie the opening balances back to the audited accounts. Reconcile the bank month by month. Clear the draft invoices and match the payments. Fix the chart of accounts and the master data. Rebuild the tax outputs. Write the processes down. Then run a clean close, and only then trust the numbers again.
An ERP migration rarely fails on the day it goes live. It fails in the six months after, quietly, while everyone is too busy to notice.
Read more about how we handle the finance side of an ERP migration, or read how to migrate a chart of accounts without losing the history.
Written by Jérôme Le Louer, Managing Partner at SmeCFO.