ERP Rescue Consultant, Singapore

Why Singapore ERP projects stall or go live badly

Rescue work starts with understanding how the project got here, because the cause decides the cure. In Singapore, a few patterns deserve particular attention.

• A lean finance team stretched too far. The same handful of people must design processes, test, migrate data and still close the books. Testing is the first thing to slip, so problems surface after go-live.
• A regional scope set too early. The project promised several countries at once, before anyone had confirmed what each subsidiary's tax and invoicing rules required.
• An implementer working from elsewhere. Remote delivery can work well, but only with clear decision owners on the client side and agreed response times; without them, questions wait for days.
• A package scope that did not match reality. Fixed packages, sometimes bought with support from a government grant scheme, may cover a standard flow and little else, so every exception becomes a change request.
• E-invoicing treated as a final step. InvoiceNow sending and receiving left until late, with access point setup, customer identifiers and rejection handling still unresolved at go-live.

A stalled project can show several of these at once. Naming them clearly, without pointing fingers, is what allows a credible plan. The country-neutral version of this method is on my ERP recovery page.

Keeping GST, payroll and the close stable during recovery

While the project is being sorted out, the company still has to bill customers, pay staff, report to the parent and file GST. The first part of a rescue makes sure none of those obligations depends on something that is not yet working.

I meet your finance lead and external accountant to agree, for each obligation, which source can be trusted. Sales invoices might come from the new ERP while purchase records are still checked against the old system. GST working papers might be prepared from the ERP but reconciled against bank and invoice data before submission. Payroll from your provider might post to a holding account until mappings are fixed. The treatment of GST and of any corrections stays with your accountant or tax advisor; I make sure the system side of each arrangement is documented and that every interim step has an owner and an end date expressed as a condition, such as the next successful test.

Month-end close gets a short recovery checklist covering bank reconciliation, intercompany balances, revaluation of foreign currency items, accruals and payroll postings. Getting one close done cleanly, with numbers finance is willing to put its name to, is often the moment the project starts to recover its credibility. The go-live support page covers this stabilization period in more detail.

Untangling InvoiceNow, integrations and migrated data

Technical problems in a troubled Singapore go-live tend to cluster in three places: e-invoicing, connected apps and the data carried over from the previous system.

For InvoiceNow, I list every failed, rejected or unsent document and group them by cause: missing or wrong customer identifiers, unsupported document types such as certain credit notes, access point configuration or timing. Each group gets an owner, which may be the implementer, the access point provider or your own team, plus an agreed test before the fix is declared done.

For integrations, I map what connects to the ERP today and what was supposed to. Bank feeds, expense apps, CRM and ecommerce channels often go live in a partial state, posting duplicates or skipping records. I rank them by the harm they cause to cash, billing or reporting.

For data, the usual issues come from a move off Xero, QuickBooks or a regional package: opening balances that never quite agreed, duplicated contacts, items without proper tax settings and foreign currency balances loaded at the wrong rate. I agree a repair sequence with finance, starting with master data, so later corrections are made on a clean base and leave a clear audit trail.

Resetting the implementer relationship, or planning a handover

A rescue does not have to mean a new implementer. The current team holds the configuration and history, and with a fair reset many can deliver the remaining work well. What usually needs changing is the basis of the work: a scope everyone reads the same way, named people on both sides and checkpoints that surface trouble early.

To prepare, I build a single list of open items and tag each item by origin, whether contracted at the start, requested afterward, contested or now redundant. During the reset session we work through that list with the implementer, agree what is required for a stable operation and what moves to a later phase, and settle acceptance criteria. I keep the conversation on evidence, since an implementer who feels blamed rarely produces their best work.

If you decide to part ways, the handover must be planned before notice is given. That means securing administrator access, configuration and customization records, integration credentials, migration scripts and the issue history. I prepare a factual summary of what was contracted, delivered and outstanding. Any decision on notices, payments or contract remedies should be taken with your lawyer, who will interpret the agreement; I supply the facts, not legal advice.

Three futures for a Singapore group's ERP project

With daily operations calm again and the fact base accepted by all sides, leadership faces the real question: what should this project become? I frame it as three options in a short paper, each described by effort, risk and disruption in words rather than speculative figures.

• Continue on the current platform and scope with a reset plan, when the system fits and the problems came from planning, capacity or data.
• Re-scope to a Singapore core that runs well before subsidiaries join, each country added only when its local tax, invoicing and payroll requirements are confirmed with advisors there.
• Re-platform when evidence shows the chosen system cannot carry your core processes or regional structure without unreasonable customization.

Where a parent company holds a group ERP standard, the paper also shows how each option fits that standard, so the conversation with headquarters starts from facts. Where grant funding was involved, check with the scheme administrator or your advisor before changing scope or vendor.

No software house or implementer pays me anything, in fees, commission or referrals, which keeps the advice tied to your interests alone. Before or after a rescue, the ERP audit service for Singapore gives a structured view of a live system. See also the Singapore overview and my client-side implementation support in Singapore.