ERP Business Analyst, Netherlands

BTW, the ICP listing and import VAT deferment

Dutch VAT, known as BTW, is filed with the Belastingdienst, and a business supplying goods or services to customers in other EU countries generally also submits an intra-community listing, the ICP declaration. Some importers hold a license that lets them account for import VAT in the periodic return instead of paying it at the border. Each of these depends on data the ERP must hold correctly from the moment an order or purchase is entered.

Deciding how a transaction is treated is not my job; that sits with your tax advisor. My contribution is turning their guidance into requirements the platform must meet: tax codes per scenario, customer VAT numbers to validate, the import documents that support deferred import VAT, and the return and listing values each transaction should produce. Every requirement carries a test case, so during acceptance testing the system's output can be compared with the figures your advisor expects.

I also note whether your accountant will want a standard audit file export of the ledger, and whether customers or public bodies expect structured invoices through Peppol. Both are worth confirming early, since support varies between platforms and versions. The Odoo and ERPNext pages for the Netherlands look at the platform side.

Third-party warehouses, bonded stock and EDI

A Dutch distributor may not run every warehouse itself. Stock can sit with a logistics service provider, in a customs warehouse under bond, or in transit by barge, rail or road. Requirements written for one owned warehouse break down in this setting, so I map each type of location separately and agree how the ERP should know what is where at any moment.

With a logistics provider, the key questions are which messages flow in each direction, such as advance shipping notices, receipt confirmations, pick instructions and dispatch confirmations, and which system is the master for stock quantities. With bonded stock, customs status becomes part of the item record, and release from bond becomes a recorded event with its own documents. With goods in transit, ownership and valuation rules have to be written down together with finance.

The result is an integration specification attached to the BRD: message types, key fields, frequency, error handling and who resolves a failed message. Implementers can estimate it accurately and testers can run it end to end. My process mapping work produces the flows, and gap analysis shows how each candidate platform copes with them.

Stakeholder interviews across a European headquarters

When the Dutch company is the European base of a group from the United States, Asia or elsewhere, the people with a stake in the ERP are spread out. The Dutch finance team owns local books and filings, country managers run sales entities in neighboring markets, logistics may be outsourced, and the parent sets reporting formats and IT standards. Each group describes the same process in its own way.

I build the interview schedule around that structure. Dutch process owners get working sessions on order handling, purchasing, stock and closing. Sales entities get shorter sessions focused on what they need from a shared system. Group finance and IT review the mapping of accounts, intercompany flows, security and integration standards. Where views conflict, the conflict is logged with an owner and a deadline rather than hidden in careful wording.

Interviews run remotely and in English. Where warehouse or administrative staff prefer Dutch, a bilingual colleague joins the session and checks the notes, and Dutch-language artifacts such as document templates are reviewed by your own people rather than by me. The ERP consultant page for the Netherlands covers multi-entity design in more depth.

Fit-gap results Dutch decision-makers can act on

A fit-gap matrix is only useful if it changes the decision. For Dutch shortlists I weight the requirements that tend to separate platforms: depth of warehouse and order handling, multi-company finance, logistics and marketplace integrations, structured invoicing, and the local tax reporting your advisor needs. Generic features that every candidate handles are recorded but carry little weight.

Each requirement is scored per platform in four categories: standard, configuration, extension or custom development. I add notes on risk, such as an extension maintained by one small developer or a custom report that must be rebuilt at every upgrade. Scripted demos confirm the scores, because a vendor saying a feature exists is different from watching it handle your own transaction.

The management summary fits on a single page: where each platform is strong, where it needs work, and what that work implies for cost drivers and timeline in broad terms. The detailed matrix stays with the BRD for the implementer. If you want help beyond the analysis, such as leading selection or checking proposals, see the freelance ERP consultant page for the Netherlands, along with the Dynamics 365 and Zoho pages.