ERP Implementation Consultant, NZ

Common failure points in New Zealand ERP projects

New Zealand rollouts face the usual ERP risks, but some problems are more likely here because of how businesses have grown around an accounting app and a ring of add-ons, and because implementation teams are often small:

• Too much in one person's head. A key implementer consultant makes design choices that are never written down, then moves to another project or leaves.
• Data scattered across apps. The same customer or product exists in the ledger, the inventory app and the CRM with different names and codes, and nobody has decided which version is right.
• Peppol treated as a later phase. E-invoicing is pushed past go-live, then customers or suppliers using the network cannot exchange invoices with the new system.
• Payroll boundaries unclear. The payroll product keeps running, but the wage journal, cost allocations and employee master data are not designed or tested.
• GST on imports missed. Border GST, freight and customs charges are not set up in purchasing and landed cost, so margins and GST figures both drift.
• Variations agreed informally. Small requests made in passing add up to a larger bill.

Each of these is manageable when someone on the client side owns it, tracks it and raises it early. If several are already causing trouble, ERP recovery and the guide to fixing a failed ERP implementation describe how a project can be reset.

Running the client side when the implementer team is small

A small implementer can move quickly and give you senior attention, but it also concentrates risk. My oversight is designed around that reality, while respecting the implementer's method and expertise.

Decisions are logged as they are made, with the reason and the approver, in a document your business owns. Designs are reviewed with your process owners before configuration and stored on your side, not only in the implementer's systems. Administrator procedures, such as adding users, changing tax codes or maintaining price lists, are written down during the build rather than promised for the end. If a named consultant is replaced, I make sure the handover is documented and that the newcomer has read the decision log before changing anything.

Variations follow a simple path. The implementer describes the change and estimates it; I test it against the signed scope to see whether it is truly additional; your sponsor sees the cost and schedule impact and decides. Smaller items can be grouped and approved together so the process does not slow the build.

Finance designs get close attention: GST codes for local, zero-rated and imported transactions, the chart of accounts and tracking categories, and how payroll journals will arrive. Where an Australian entity shares the environment, I check that its tax settings stay separate. For the broader approach, see ERP implementation.

Moving data out of Xero, MYOB and their add-on apps

A New Zealand migration is rarely a single export from one ledger. More often it means combining Xero or MYOB with an inventory app, a job management tool, a CRM and a few spreadsheets, each holding its own version of customers, products and suppliers. The hard part is deciding which source wins for each field, before the implementer's import tools are involved.

I start by mapping every source and agreeing a master for each data type with the people who maintain it. Duplicates are merged, codes are standardized and inactive records are archived rather than migrated. Finance then decides how much history to bring: a frequent approach is to load balances plus unpaid invoices and bills while the old ledger stays open for reference, but your accountant should confirm how long records must remain accessible.

Each trial load is reconciled against the sources:

• Ledger balances by company at the cutover point.
• Open debtors and creditors by invoice, with GST on each preserved.
• Stock on hand and value by location, matched between the inventory app and the ledger.
• Customer and supplier records with GST numbers, bank details and Peppol identifiers where used.
• Open jobs or projects with costs to date, if they move into the ERP.

Where Xero tracking categories or MYOB jobs held reporting meaning, I map them to the new dimensions with finance. See ERP data migration and ERP integration for the wider method.

Testing and choosing the cutover point

UAT should prove the transactions that would cause the most damage if they failed. Your staff run scripts built from real records: a local sale, a zero-rated export, an import with border GST and landed costs, a Peppol invoice sent and another received, a supplier payment file accepted by your bank, the wage journal from payroll, and a full month-end close. For trans-Tasman groups, an intercompany sale to the Australian company is included, with each country's tax kept apart.

Choosing when to switch matters as much as what is tested. In New Zealand, I work through these questions with your finance lead and accountant:

• Which GST period? A clean break where a GST period begins means each return comes from one ledger. When the business cannot wait for that point, the accountant decides in advance how the return covering both systems will be put together and checked.
• Near balance date or not? Opening the financial year in the new ledger helps comparisons, yet annual accounts work lands on the same finance staff you need for the switch. Groups with an Australian company that uses another year-end need a plan for both.
• Is payroll moving too? Where the payroll product stays, the work is limited to the wage journal and its mappings. Where it changes, payday filing continuity, KiwiSaver and leave balances become part of the plan, designed by your payroll provider and advisor.
• Are Peppol partners ready? Key customers and suppliers should confirm they can exchange invoices with your new identifiers before the switch.

Directors approve go-live only once process owners have signed UAT, balances agree, users have practiced and a fallback exists. See UAT and go-live support.

Hypercare that works across the time difference

Go-live is when staff discover whether the system fits their day. In hypercare, I run a short daily call in the New Zealand afternoon with implementer consultants and super users. Each issue is classified as a defect, a training gap or a request for later, given an owner and logged where the directors can see it.

The time difference turns out to be useful here. Issues raised during your morning are triaged on the afternoon call; analysis, test cases and draft fixes for the implementer can be prepared outside your hours, so the next day starts with progress rather than a queue. The implementer still owns configuration changes, and nothing goes into the live system without passing a quick retest.

Settling is judged by evidence rather than mood: the opening month closes with bank accounts, inventory and both ledgers agreeing, and your accountant is comfortable with the GST figures produced by the new system. Gaps found at either point are estimated and scheduled by the implementer instead of being patched in a rush.

Hypercare, like the rest of the work, is remote; an on-site day can be booked by arrangement where your team would benefit. Still at the choosing stage? Read about ERP selection in New Zealand first. For more context, see ERP consulting in New Zealand, the freelance engagement options and the New Zealand hub.