ERP Requirements Consultant, Netherlands

Building a programma van eisen around Dutch goods flows

Many ERP buyers in the Netherlands are trading, distribution or logistics-heavy businesses, often acting as a European hub for a foreign parent. Their programma van eisen should follow the goods: purchase and inbound shipments, storage at an own or third-party warehouse, order intake from EDI, web shop or sales staff, picking and dispatch, returns, invoicing and collection, then the finance close. Service and project companies follow their own flows, but the principle is the same.

Within each flow, a requirement is a single statement a supplier can answer as fully met, partly met or not met. Alongside it sit a code, the person or party who asked for it, a priority tier and a description of the proof expected at acceptance, for example "a return with partial credit shows the restocked quantity and the credit note in the same customer history".

Around the flows the document adds four blocks that Dutch lists often leave out: tax and invoicing requirements, rules on platform behavior, a message and interface catalog, and data takeover rules. A short glossary pairs English terms with the Dutch words key users actually say, such as pakbon, inkooporder or creditnota, so nothing is lost when Dutch-speaking staff test. The approach mirrors my ERP requirements gathering method.

BTW, the ICP listing, the auditfile and Peppol as checks

"Supports Dutch tax" is not a requirement anyone can test. I break the subject into statements with a visible outcome, each one confirmed by your accountant or tax advisor before release:

• Every BTW code maps to a box of the return, and a code-by-code report agrees with the general ledger.
• Intra-EU supplies are captured with validated customer VAT numbers and feed the ICP listing.
• Import VAT postings follow the treatment your advisor confirms, including any deferment arrangement you hold.
• The system can produce an auditfile of the financial records in the format the Belastingdienst works with, and a sample opens in your accountant's tools.
• Sales and purchase invoices can be exchanged over Peppol, and incoming structured invoices are validated, matched to order and receipt, and stored as received.
• Invoices to government customers can be delivered in the electronic route those customers require.
• Records are retained and retrievable for the period the bewaarplicht requires, as your advisor specifies.
• Payroll journals from your payroll bureau post to agreed accounts and cost centers.

With European rules heading toward structured invoices and transaction reporting, the requirement asks how each product supports that today rather than relying on a roadmap slide. How these requirements are demonstrated by suppliers is covered on my ERP selection page for the Netherlands.

Hosting, the ondernemingsraad and how the system must behave

A programma van eisen that describes only processes leaves suppliers free to decide everything else. A dedicated block of platform rules prevents that.

Data protection requirements state where production data and backups may be held, whether processing outside the EU is acceptable and on what basis, which subprocessors are allowed and what the processing agreement must contain. Your privacy officer takes the position; the document records it so every supplier answers the same question.

Logging deserves explicit wording. Where a company has an ondernemingsraad, systems that can track the presence, behavior or performance of staff generally fall within its say, and an ERP with scanner logs, pick rates and user histories can do exactly that. I write requirements that such logging and reporting be adjustable per role and fully documented, which lets any agreement reached with the council be configured and later verified. Interpreting employment law stays with HR and counsel.

Further rules cover roles and approval limits, change history on master data and prices, scanner and screen response times during peak picking, behavior when a warehouse connection drops, and backup and restore. Output requirements list each customer-facing document with its language: Dutch for domestic customers, English for the group, and German or French where you sell across borders. Native speakers on your team or a partner check every translated layout.

Messages, data takeover and tiers of priority

For a Dutch distributor, messages with outside parties often carry more risk than the ERP itself. Each one in the catalog states the sending and receiving party, what triggers it, which fields it carries, timing, ownership, and how a rejected or late message is reported. Common entries include stock and shipment messages with a logistics provider, carrier labels and track-and-trace, customs declarations through a broker, EDI orders from retail customers, marketplace and web shop orders, bank statement files and direct debit batches, and the payroll journal. The technical side is described under ERP integration.

Data takeover rules specify which customers, suppliers and articles are carried over, whether stock is counted or loaded from the warehouse provider, which open items and balances start the new books, and how the old package remains readable for the retention period after its subscription ends.

Priorities use tiers in the MoSCoW spirit, described in words: needed on day one, needed soon after, worth having if cheap, and explicitly excluded for now. Tax, invoicing and agreed council requirements sit in the first tier. Exclusion criteria for the supplier round come only from that tier and are written so a supplier who fails one can be told why. Management approves the tiers per flow before suppliers see the document.

Offers, the agreement, acceptance and typical weak spots

Suppliers answer the released programma van eisen requirement by requirement, with a fixed answer code and a short explanation. That makes Dutch offers, which can differ widely in format, comparable on substance. The tender mechanics are explained under ERP RFP consulting.

Suppliers may attach their own general ICT terms to the offer. How those relate to your requirements is a question for your lawyer; my concern is practical. The agreement should name the released version, every requirement should map to a design note from the supplier, and nothing answered as standard should return later as extra work. During testing, each requirement is followed to its acceptance test and the result recorded.

Each version carries a label, a release date, an owner and an entry in the change log. Flow owners approve their sections, the finance lead approves the tax requirements after the accountant's review, and management approves the release.

Weak spots in Dutch requirement lists are fairly predictable: the auditfile assumed rather than tested, Peppol receiving forgotten while sending is covered, no messages defined with the logistics provider, nothing on logging the ondernemingsraad may ask about, and no plan for reading old records. Each is checked before release. I am independent of every supplier, accept no commission, and visit only by arrangement. More on my work in the Netherlands.