Your implementer is paid to go live. Nobody is paid for the first close after.
Most ERP projects in mid-sized companies are run by IT and operations, with finance listed as a stakeholder rather than an owner. The system goes live, the consultants leave, and the finance team discovers that the opening balances were never reconciled, the chart of accounts was built to suit the software, and the statutory forms do not come out of it. We sit on your side of that.
- What we are
- The finance owner,
not the implementer - Best time to start
- Before you sign,
or 8 to 12 weeks out - Also common
- After go live,
when the close breaks - Scope
- Chart of accounts, opening balances,
parallel run, statutory outputs,
the first three closes - Systems
- Xero, Dynamics 365, PEAK,
FlowAccount, QuickBooks, Odoo,
NetSuite, SAP, Business Central - Vendor commission
- None. We sell no licences
- The test
- Books that still close
Seven ways an ERP project damages the finance function
The wrong internal resource is assigned to it
Companies pick one of two people. Either the person who can least be spared, in which case the business suffers for six months and the project still slips, or the person who can most be spared, in which case the migration is run by someone without the authority or the depth to challenge anything. The right answer is a capable internal lead with genuinely reduced day-to-day load and someone senior alongside them, and almost nobody plans for the second half of that.
Opening balances migrated but never reconciled
Balances get loaded because the project plan says load balances. Nobody reconciles the loaded figures back to the signed closing trial balance line by line, so the first close in the new system starts from numbers no one has stood behind. Every subsequent difference then gets absorbed into a suspense account, and by month four nobody can say what the balance sheet actually is.
A chart of accounts designed for the software
The implementer proposes a structure that fits their template and configures quickly. It is only after go live that you find the new structure cannot produce your management pack, your group submission or your segment margins without manual rework. A chart of accounts should be designed backwards from the reports it has to produce, and that design is a finance decision, not a configuration task.
No parallel run, so nobody can prove the systems agree
Parallel running is the first thing cut when the timeline slips, and it is the only mechanism that proves the new system produces the same answer as the old one on the same data. Without it, the day you go live is the day you lose your ability to check.
Cutover scheduled around the vendor's calendar
Go-live dates get set by consultant availability and licence renewal dates. A cutover in the wrong month means your year end, your audit and your first close in an unfamiliar system all collide, with the implementation team already demobilised.
Statutory outputs assumed rather than tested
International ERPs are not built for Thai filing. Whether the system can actually produce ภ.พ.30, ภ.ง.ด.3 and ภ.ง.ด.53 in a form your tax agent can file, with the right WHT certificates attached, is a question that should be answered in user acceptance testing. It is usually discovered in the first filing month instead.
Nobody decided what you can still answer questions about
Historical data is migrated, archived or abandoned by default rather than by decision. Then an auditor, a tax officer or an acquirer asks about a transaction from two years ago and it is in a system nobody can log into any more.
What we take on
Own the finance side of the project
A named person accountable for what finance needs from the system, sitting in the steering meetings, with the standing to say the date moves. Not a stakeholder consulted at milestones.
Design the chart of accounts backwards from the reporting
Start from the management pack, the board reporting, the group submission and the statutory accounts, then build the structure and cost centre logic that produces all four without manual rework. Do it before configuration, because afterwards it is a data migration project of its own.
Reconcile and sign off the opening balances
Every balance sheet line agreed to the closing trial balance and supported, before anyone posts a transaction in the new system. This is unglamorous and it is the single highest-value thing on this page.
Insist on a parallel run, and define what agreeing means
One full period in both systems, with an agreed tolerance and a written explanation for every difference above it. Sign-off is a finance decision, not a project milestone.
Test the statutory outputs during UAT
VAT and withholding tax returns, WHT certificates, the audit file and the fixed asset register, produced from the new system and reviewed by the people who will have to file them. Before cutover, not after.
Plan the cutover around your statutory calendar
Pick a date that keeps your year end, your audit and your first unfamiliar close apart from each other, and hold the implementation team on site through the first close rather than to the go-live date.
Rewrite the SOPs for the new system
Procedures written for the old system quietly become fiction on day one. The close calendar, the approval routing and the reconciliation steps all need rewriting, and the moment to do it is while the team is already relearning everything.
If it has already gone wrong
A large share of this work is recovery rather than prevention. It is fixable, and it is better faced than carried.
The symptoms are consistent. The close has gone from five days to five weeks. Sub-ledgers no longer agree to the general ledger. There is a suspense account nobody wants to discuss. The auditor has started asking about the migration. The implementer has demobilised and the remaining conversation is about scope and change requests.
Establish what the balance sheet actually is
Reconstruct and reconcile every balance sheet line from source records, agree what was mismigrated, and quantify it. Until this exists, every other number in the system is an estimate.
Repair the sub-ledger to general ledger breaks
Receivables, payables, inventory, fixed assets and bank, each agreed back to the control account, with the mechanism that broke them identified so they stop breaking.
Get the close back to a date
A rebuilt close calendar against the new system's actual behaviour, with owners and dates, and someone senior driving it until it holds for three consecutive months.
Make the statutory filings work
Whatever it takes to produce filable Thai returns from the new system, including the workaround if the honest answer is that the system will not do it natively and something outside it has to.
Rebuild the reporting pack on the new data
Management reporting reconstructed from the new structure, with the comparatives bridged back to the old system so the board can still see a continuous story rather than a break in the middle of the year.
Different incentives, different job
Your implementation partner is measured on going live on time and on budget. That is a legitimate objective and it is not the same as your objective, which is a set of books that closes, files and survives an audit. When those two pull against each other, and near the end of a project they always do, somebody needs to be paid by you.
We take no licence revenue, no referral fee and no commission from any vendor or implementer. Ask anyone advising you on system selection whether they can say the same.
The second difference is that we have lived with these systems afterwards. Jérôme ran ERP and TMS rollouts and a shared services implementation across fourteen APAC markets at Scan Global Logistics, and has rebuilt closes and consolidations on the far side of migrations at PropertyScout and Manuport. Benoît has worked across SAP, IFS, Cognos and Xero and implemented them rather than commissioned them. Knowing what the output has to survive is a different skill from knowing how to configure the software, and it is the one that is usually missing.
It also means we will tell you not to do it. A significant number of companies that believe they need a new ERP have an undesigned process and would get most of the benefit for a fraction of the cost and risk by fixing that first. If that is your situation we will say so on the first call.
| System | Our experience |
|---|---|
| Xero, Microsoft Dynamics 365, PEAK, FlowAccount, QuickBooks | Implemented, and migrated companies both onto and off them |
| Odoo, NetSuite | Run the monthly close on, and rebuilt after a bad migration |
| SAP, Business Central, AS400 | Worked in as a user, at group and regional level |
| Hyperion, Tagetik | Consolidation and planning, as a user |
| Anything else | We will say so. The discipline transfers between systems; specific configuration knowledge does not |
SOPs, process and automation · The rest of the scope · What it costs
Scope and boundaries
Do you implement the ERP?
No. Your implementation partner configures and builds the system. We own the finance side of the project: what the system has to produce, whether the data going in is right, and whether you can still close and file afterwards. Those are different jobs and it is better that different people do them.
Do you recommend a specific system?
We help you choose, and the honest answer is usually that several would work. What matters far more than the brand is whether the process underneath it has been designed and whether the migration is run properly. We have implemented and migrated companies onto and off Xero, Microsoft Dynamics 365, PEAK, FlowAccount and QuickBooks, run the monthly close on Odoo and NetSuite and rebuilt both after bad migrations, and worked at group level in SAP, Business Central, AS400, Hyperion and Tagetik. We take no commission from any of them.
When should we bring you in?
Ideally before you sign, because the chart of accounts and the reporting requirements should shape the selection rather than be retrofitted to it. Realistically, eight to twelve weeks before go live is still early enough to fix the things that matter. After go live is not too late, but it costs more.
We have already gone live and it is a mess. Is it too late?
No, and this is a large part of the work we get called in for. The pattern is nearly always the same: opening balances that were never reconciled, sub-ledgers that no longer agree to the general ledger, and a close that has quietly gone from five days to five weeks. It is recoverable. It takes a few months rather than a few days, and the first step is establishing what the balance sheet actually is.
Do you take commission from the vendor or the implementer?
No. We sell no licences and take no referral fee from any software vendor or implementation partner. Every fee we earn is paid by you, which is the only arrangement under which our opinion on your implementer's work is worth anything.
Can you work alongside our existing implementation partner?
Yes, and that is the normal arrangement. Good implementers welcome it, because for the first time somebody on the client side can specify precisely what finance needs and sign off on it. The ones who object to an independent finance owner are telling you something useful about themselves.