ERP Implementation, Netherlands

What tends to go wrong in Dutch ERP projects

These are the patterns I check for early in a Dutch implementation, because each one surfaces late and expensively if nobody looks:

• The warehouse provider's message formats are discovered late, and order release or shipment confirmation fails in the first test with real data.
• Webshop and marketplace connectors are bought separately, and nobody owns how products, prices and VAT codes map between them and the ERP.
• Open items are migrated as totals, so customer payments in the first weeks cannot be matched to invoices.
• The accountant first sees the new ledger after go-live and finds that opening figures or VAT codes do not follow their structure.
• Peppol sending is switched on for every customer at once, without checking who actually receives invoices over the network.

All of these are avoidable with named owners and testing that starts early. The structure I bring is laid out on my ERP implementation page; the sections below show how it works in a Dutch setting, where much of the risk sits in the links between systems rather than in the ERP itself.

Steering the implementation partner from your side

Dutch implementation partners tend to work in short, practical cycles and expect quick answers from the client. That is efficient when the client side is organized and costly when it is not. I make sure process owners are prepared before each session, that every decision is written down with a reason and an owner, and that open questions do not sit for weeks waiting for someone to pick them up.

Requests for extra work enter one register, each showing why the business wants it, what the partner thinks it will take and what it does to the planning. Your director or a delegate approves, rejects or defers each one; deferred items move to a backlog for a later release. I compare estimates with what the agreement already covers and ask for detail where the two seem to overlap.

Once a week the partner's project lead and your team go through blockers, and a short steering meeting covers anything that needs management's authority. If the relationship is already under strain, I begin by reviewing open issues and agreeing priorities with both sides. For a project that has gone badly off course, ERP recovery is the better route.

Migrating from Exact, AFAS, Twinfield and local packages

Dutch companies usually come to a new ERP from an established accounting package such as Exact, AFAS, Twinfield or SnelStart, often with stock held in a separate tool, the warehouse provider's portal or spreadsheets. In some cases the accountant keeps the books and the company only invoices. The migration plan has to reflect that starting point.

With the partner and your accountant I agree what moves: customers, suppliers, items and prices after cleansing; open receivables and payables as individual items so payments can still be matched; opening balances from the ledger your accountant signs off; and stock by location, agreed against the warehouse provider's count. History usually stays readable in the old package, and how long records must be kept is confirmed with your accountant before any subscription is cancelled.

Every trial load closes with a reconciliation by account, open item and stock location, signed by your finance lead. Common problems, such as duplicated relations, inconsistent VAT numbers or items without a cost price, are corrected in the source during the trials. More on the method is on my ERP data migration page.

Testing warehouse messages, BTW, the audit file and Peppol

A Dutch test plan has to go beyond screens and into messages and files. Together with the partner I plan:

• End-to-end order flows with the warehouse provider: release, pick confirmation, partial shipment, return and stock adjustment, using their test environment.
• Webshop and marketplace orders arriving with the right prices, VAT codes and customer data.
• BTW scenarios for domestic, intra-EU and import flows, compared with a return prepared from the old package.
• Bank statement imports and payment batches in the formats your bank uses.
• An audit file export for a trial period, reviewed by your accountant.
• Peppol invoices sent to and received from a few willing customers and suppliers, including credit notes.

Your accountant confirms whether the results meet Dutch requirements; my part is that real cases are used and the results reach them in time. Defects go into one log, classified by severity, and the partner fixes them before the next cycle. My ERP testing and UAT page covers the method, and ERP integration explains how I approach the links themselves.

Cutover, payroll journals and hypercare

Cutover in a Dutch distribution business usually needs a short, coordinated freeze with the warehouse provider: final stock positions agreed, open orders moved, connectors switched in the right order. I build the cutover plan with the partner and the logistics provider and rehearse it in a test environment so timings are known.

Payroll typically runs in a separate package or with a provider, and the ERP receives journals. Ahead of go-live, one trial payroll period is posted to confirm format, accounts and cost centers, and a named person reviews the first real journal. Work instructions in Dutch are written by your key users; I check that every role has one.

Hypercare is run remotely, with a quick review every working day involving key users and the partner, a single issue register and priorities set around orders, shipments, invoicing and payments. I close it once a month-end and a BTW period have run cleanly in the new system, whatever the calendar says. The checklist is on ERP go-live support. For the decision before delivery, see ERP selection in the Netherlands; the Netherlands overview covers my other services.