Business Process Consultant, Netherlands

Where Dutch order to cash loses time

For many Dutch companies the order to cash process runs through at least one outside party: a logistics provider that stores and ships the goods, a carrier that delivers them, a payment provider that collects from web customers. Each passes information back, and each handoff is a place where the process can stall without anyone noticing.

I trace a sample of real orders from receipt to cash. The questions are simple. When does the logistics provider confirm a shipment, and when is the invoice created? Who checks that the quantity invoiced equals the quantity shipped? When a delivery is short, who decides whether to back-order, credit or ship again? When a customer disputes an invoice, where is that recorded, and does it stop the reminders?

The current-state map usually shows a few recurring patterns: invoices waiting for a confirmation nobody chases, credit notes created on request without a reason code, customer master data updated by whoever spotted the error. None is dramatic on its own. Together they explain why the sales ledger needs a long clean-up every month. The future process gives each decision an owner and each handoff a rule, documented so your logistics provider can see it too. Where requirement-level detail is needed later, the work continues as business analysis in the Netherlands.

Direct debits, iDEAL and Peppol as process steps

Payment and invoicing practices in the Netherlands shape the process in ways teams take for granted. Many Dutch businesses collect recurring revenue by SEPA direct debit, web customers often pay with iDEAL, and business customers pay by transfer. Each route needs its own steps, and those steps need owners.

For direct debits, the process covers obtaining and storing the mandate, notifying the customer before collection, handling a failed or reversed collection and deciding when to move a customer to another payment method. For iDEAL and card payments, it covers how payment confirmations reach the order and how refunds are approved. For transfers, it covers how incoming payments with poor references are investigated and by whom.

Invoicing is changing too. Dutch public bodies can receive structured invoices over Peppol, and the wider EU direction points toward structured electronic invoicing between businesses as well. In process terms that adds steps: checking customer identifiers before invoicing, handling a rejected invoice message and receiving supplier invoices as data. I design those steps now and leave the question of what is required of your company, and when, to your tax advisor. The technical connection belongs to integration work in the Netherlands.

Record to report, BTW and the audit file

The close is where weaknesses earlier in the chain become visible. I map record to report as a process with steps and owners, not as a list of accounting tasks: cut-off for sales and purchases, goods received but not invoiced, accruals, bank and intercompany reconciliation, BTW preparation and the review by your accountant.

Two points get particular attention in Dutch companies. First, the BTW return depends on transactions being coded correctly when they are entered, so the map traces where the tax code on a sales or purchase invoice is set and who checks it, including for intra-EU trade that feeds the ICP listing. Second, accountants and the tax authority may request an audit file, a standard extract of the ledger. I do not judge whether your file meets requirements; that is for your accountant. What I check is the process that feeds it: whether postings are complete, whether corrections are made by reversal rather than deletion, and whether the person preparing the extract knows what it contains.

The future process makes these checks routine steps in the close calendar, owned by named people. That keeps the accountant's review focused on judgment rather than on finding missing documents, and corrections that keep coming back are traced to their source upstream.

Ownership, approval limits and the ondernemingsraad

Dutch organizations are often flat, and decisions are reached through discussion. That is a strength, but it means process ownership is easily left implicit. When a step in purchasing fails, the buyer, the warehouse and finance each have a reasonable view of who should have acted.

I make ownership explicit without adding hierarchy. Each cross-team process gets one owner who approves changes and watches whether it works, and each step names the role that performs it. The approval matrix sets bands rather than fixed amounts for purchases, credit notes, write-offs, supplier bank changes and payment releases, with a second approver where the risk justifies it. Management sets the values.

Process changes can affect staff in ways that matter under Dutch employee participation rules. Where a company has an ondernemingsraad, changes that introduce new ways of recording or monitoring employees' work may need its involvement, and management decides with HR and legal advisors how to handle that. I keep a list of the process changes that touch how work is recorded or reviewed, so the conversation can start in good time. GDPR questions arising from new process steps go to your privacy officer in the same way, before anything is configured.

From agreed process to the right software

Only once the future process is agreed do I look at software, and the answer is not always a new system. Sometimes the existing accounting package or ERP can support the agreed process once it is configured properly and used consistently. Sometimes the gap is a few repetitive steps that targeted automation can handle, which my business automation page for the Netherlands describes. Sometimes the maps show that the current tools cannot carry the business further, and then they become the basis for requirements and selection.

Whatever follows, the process documentation stays useful. I keep it brief: one map per process, short role instructions and the approval matrix, stored where the team works and owned by the process owner. When the business changes, the owner updates the map, and any system change is checked against it.

This order of work, process first and technology second, also keeps an implementation partner focused. A partner configuring to an agreed process has less room to redesign your business around their defaults. The method is described on my ERP process mapping page, and my Netherlands page covers the rest of my work for Dutch companies. Delivery is remote, and a visit can be planned by arrangement.