ERP Rescue Consultant, Netherlands

What a Dutch ERP crisis tends to look like

The specific symptoms vary, but in a Dutch company that moves goods they usually cluster around the links between systems rather than the ERP screens themselves:

• Order releases to the warehouse provider fail or arrive incomplete, so pickers wait while sales staff phone customers.
• Shipment confirmations do not post back, leaving orders open and invoices unsent.
• Webshop and marketplace orders arrive with wrong prices or VAT codes because product mapping was never finished.
• Customer payments arrive by bank file but cannot be matched, because open invoices were migrated as balances.
• The accountant cannot produce the BTW figures or the audit file from the new ledger, and the old package is still being used for parts of the work.

On projects that have not gone live, the picture is quieter but just as worrying: test rounds that never finish, a growing list of change requests, a partner asking for more budget and a go-live date nobody believes. Either way, the cause is rarely one party. Thin requirements, late decisions, underestimated data work and optimistic plans usually all played a part. My job is to get things working and then help everyone look forward, not to assign blame. The general method behind this is described under ERP recovery.

Restoring orders, shipments and payment matching

When a go-live has gone badly, the first days of a rescue are about operations. I set up a short daily call with your operations lead, finance, the implementation partner, the connector supplier and, where stock is held externally, the logistics provider. Everyone works from one issue list, ranked by what stops goods or cash moving.

Blocked messages come first. We find out which orders, confirmations and receipts are stuck, why they failed and how to resend them without creating duplicates. Where a mapping is wrong, a temporary manual step may be accepted, but it is written down with an owner and an end date so it does not become permanent. Stock is compared between the ERP and the warehouse once the flow is moving again, and differences are corrected through proper adjustments rather than quiet edits.

Cash comes next. If payments cannot be matched because open items arrived as totals, the receivables have to be rebuilt at invoice level, from the old system, before reminders and collections can resume. Invoice sending, including Peppol messages to customers who expect them, is checked and restarted, with rejected messages given an owner. Only once orders, shipments, invoices and receipts move reliably does the rescue turn to the wider project.

Closing the period and the BTW return with your accountant

A rough go-live often lands in the middle of a BTW period, with some transactions in the old package and some in the new ERP. Your accountant needs a clear basis for the return and the intra-community listing, and later for the annual accounts. I help agree that basis with them rather than leaving finance staff to improvise.

Together we decide which system holds which transactions for the period, how opening balances in the new ledger reconcile to the closing position of the old one, and which corrections are needed before the return can be prepared. Tax treatment and any corrections to earlier returns are decided by the accountant or tax advisor; I make sure each item has evidence, an owner and a check.

The same discussion covers the audit file. If the accountant expects one and the new system cannot yet produce a complete version, we agree an interim approach and a test date for a full export. Retention of records from the old package matters too: it usually stays available read-only, and how long is a question for your accountant. Once one period closes cleanly in the new system, I hand the routine back to finance and keep an eye on the next one. The structured checklist for that stage is on my go-live support page.

A neutral fact base and a reset with the partner

With operations steadier, attention turns to the project itself. Dutch business culture tends to value direct conversation, which helps, but direct conversation without shared facts often hardens positions. So I build the facts first.

I hold separate conversations with the directors, finance, operations, key users and the partner's project lead, and with the connector supplier and logistics provider where they are involved. I read the agreement, statement of work, requirements, plan, change requests and issue log, and test the main flows in the system. The resulting status report sets out what was agreed, what exists, what the business now needs and where those differ, with root causes described without naming culprits.

That report becomes the basis for a reset session with the partner. Remaining work is sorted into what the business needs to operate, what can follow, what is no longer wanted and what is disputed. Disputed items are tested against the signed scope and the business impact. The outcome is a revised plan with acceptance criteria, named owners and checkpoints. I also list the commercial points in the agreement and change orders worth discussing, such as acceptance, payment stages, ownership of custom code and exit support; interpretation and any negotiation stay with your lawyer.

Continue, narrow the scope or change platform

Every rescue ends with a choice. Continuing with the current platform and partner, under a reset plan and tighter governance, is the right answer when the foundations are sound and the trouble came from planning and decisions. Narrowing the scope suits a project that tried to do everything at once: perhaps finance, sales and the warehouse link first, with manufacturing, a second entity or advanced pricing later.

Moving to a different partner or platform is sometimes justified, for example when the product cannot handle your warehouse or pricing model without heavy custom work that keeps breaking. It is a serious step that deserves its own analysis, not a reaction to a bad week. If it comes to that, I help plan a controlled transition and a fresh vendor selection, reusing requirements, test scripts and cleaned data.

For each option I describe the effect on operations, finance, staff and customers and the cost drivers involved: remaining build, licenses already committed, connector work, internal time and the cost of a longer transition. No invented figures. The directors decide. I can then run the recovery plan remotely with your team, with visits by arrangement. For a system that runs steadily but falls short of expectations, the ERP audit for the Netherlands is the lighter option. See also my implementation page for the Netherlands and the Netherlands overview.