Integration Consultant, Netherlands

Logistics providers and the messages that hold stock together

When a Dutch company outsources warehousing, its ERP no longer sees the stock directly. Everything it knows arrives as messages from the logistics provider: goods received against a purchase order, orders picked and shipped, stock counts, damages and returns. If those messages are designed loosely, the ERP and the warehouse drift apart and nobody can say which number is right.

I start from the provider's own interface documentation, since most logistics firms have a fixed set of message types and formats, sometimes EDI standards and sometimes their own files or API. Then I specify the mapping on the ERP side:

• Item codes, units of measure and batch or expiry fields, matched on both sides.
• How partial shipments, substitutions and short receipts are reported and booked.
• Which document number links each message back to its order.
• What happens when a message fails validation or arrives twice.
• A daily stock comparison between the warehouse report and the ERP, with differences assigned to someone.

Testing uses the provider's test environment wherever one exists, with real order scenarios rather than single records. The provider is a party to the test plan, not an afterthought. Broader context for warehouse-heavy Dutch businesses sits on the Netherlands ERP consultant page and the warehousing industry page.

Bank statements, SEPA files and payment providers

Dutch banks generally provide statements in structured formats such as CAMT, and accept SEPA payment and collection files, either uploaded through online banking or exchanged through a direct connection where the bank and ERP support one. I check what your bank offers and what the ERP edition supports before designing anything, because the answers differ between products and between banks.

The design then covers the details that decide whether matching works: the payment reference customers use, how batch bookings are split, how returned direct debits are recognized, and which rules post bank costs and interest automatically. For supplier runs I agree the approval steps in both the ERP and the bank portal, so payment authority is not weakened by the integration.

Online sales add payment providers. Consumers and business buyers may pay through iDEAL, cards or other methods collected by a provider that settles in batches, net of fees and refunds. I specify how each settlement report is broken down into receipts per order, fees, refunds and chargebacks, and how the net payout is matched to the bank line. Without that, the bank account balances but the customer ledger never does. Where the ERP is being replaced at the same time, the flows are tested inside the plan on my ERP implementation consultant page for the Netherlands.

Peppol invoices, payroll journals and the accountant

Structured e-invoicing through Peppol is established in the Netherlands, particularly for invoices to government bodies, and EU policy points toward wider use. Your tax advisor determines what is mandatory for your business. The integration question is how invoices leave and enter your ERP. Some ERPs connect to an access point natively, others through a separate provider or a connector. I map the invoice fields to the required format, check that KvK and VAT identifiers are held correctly, decide how a received invoice finds its purchase order and define how rejected messages come back to finance rather than disappearing.

Payroll in the Netherlands is frequently run by an external payroll provider or by the accounting firm. The ERP needs a journal, not payslips. I write the mapping from wage components to accounts and cost centers with your accountant, agree whether the journal arrives as a file or through an API, and add a control total that ties the posting to the payroll summary.

VAT returns are usually prepared by the accountant from ledger data. Rather than integrate with the tax authority directly, the design makes sure the ledger delivers clean, coded figures and an export the accountant can use. Their software and process stay their own.

Webshops, marketplaces and customers who order by EDI

A Dutch company may receive orders through its own webshop, through one or more marketplaces, from retail customers by EDI and from the inside sales desk. Each channel has its own product identifiers, price logic and timing. The ERP has to turn them into consistent sales orders, and send back stock, prices, shipment status and invoices in the form each channel expects.

The first decision is ownership. Usually the ERP owns items, stock and cost; prices may sit in the ERP or in the webshop by agreement; content such as product descriptions in Dutch, English or German often lives in a separate product information tool. Once that is clear, I specify each flow: trigger, direction, frequency, field mapping and error handling.

Marketplaces deserve attention because they settle on their own cycle, deduct commissions and sometimes handle VAT on certain sales themselves. The integration has to record each sale, fee and payout separately so finance can reconcile and the accountant can see which party accounted for the VAT. Retail EDI brings its own discipline, with order responses and dispatch advice expected within agreed windows. Both cases are covered by scenario tests before the channel goes live. The CRM side of the same customer data is on my CRM consultant page for the Netherlands.

Method, monitoring and ownership after go-live

For every flow I compare the methods that could work. A native connector is cheapest when it covers the real scenarios. A hub like Zoho Flow, Make or n8n earns its place once a growing number of systems exchange records and mappings and logs belong in one console. Custom API work fits high volumes or unusual logic but creates code someone must maintain. Scheduled file exchange is still normal with banks, payroll providers and many logistics firms, and is fine when it is automated and watched.

Monitoring is designed in, not added later. Each flow gets validation before data is written, limited retries for temporary failures, protection against duplicate processing, and an alert to a named person in your organization. A daily control compares counts and totals between systems: orders sent and acknowledged, stock in the warehouse report and the ERP, settlements received and matched.

Finally, ownership. Someone in the Dutch team must know each integration exists, what it does and who to call when it fails. I hand over specifications, a runbook and a contact list, and I can review error trends for a period after go-live. The general approach is under system integration and ERP integration; other work is on the Netherlands overview. Everything runs remotely, with visits by arrangement.