# E-Invoicing in Netherlands

- 2026-08-29

Key formats, routing options, and a practical checklist for sending compliant e-invoices in Netherlands.

## What matters in practice

This Netherlands guide explains PEPPOL delivery, UBL mapping, KVK and VAT validation, and the common routing questions that decide whether an invoice is accepted.

## Common e-invoice formats

- PEPPOL BIS 3.0 (UBL)
- EN 16931 mappings

## Routing & delivery

- [PEPPOL](https://peppol.eu/): Network

## Common identifiers

- KVK number
- VAT ID

## Mandate & scope

The Netherlands frequently uses PEPPOL-based delivery models and EN 16931-aligned invoice mappings, especially for structured B2B/B2G exchange.

## Country-specific operating notes for Netherlands

- Dutch implementations often start with PEPPOL BIS 3.0 UBL; keep local KVK and VAT checks close to onboarding, not only at invoice export.
- Recipient discovery matters: a valid VAT ID does not prove that the buyer is reachable for the process/profile you plan to send.
- Many rejections are operational rather than semantic: wrong endpoint scheme, missing order reference, or supplier data that differs from buyer records.
- Many Dutch buyers expect the KvK number (Chamber of Commerce) in BT-30 (legal registration identifier).
- For government routing, OIN identifies the public organisation. Do not replace it with the supplier’s KVK number.

## Quick checklist

- Delivery: PEPPOL is commonly used via a certified access point.
- Identifiers: KVK (Chamber of Commerce) and VAT ID are frequently used identifiers.
- Profiles: ensure PEPPOL BIS settings match the recipient expectations.
- Dutch public bodies have had to receive and process European-standard e-invoices since 18 April 2019. A supplier’s sending obligation can also follow from the buyer’s procurement terms.
- NLCIUS is the Dutch usage specification for EN 16931. Apply it when the recipient or delivery process requires it.
- For central-government invoices, use the route and OIN stated in the order or buyer instructions; a PDF by email is not a structured e-invoice.

## How to send (practical steps)

1. Choose a PEPPOL access point/provider and register the correct participant identifiers.
2. Confirm recipient participant ID and supported process/profile.
3. Generate a PEPPOL BIS 3.0 invoice (UBL) with valid code lists and identifiers.
4. Validate and send; store delivery acknowledgements.

## Validation & compliance

- Use correct participant ID schemes (endpoint IDs) for routing.
- Validate UBL structure and business rules (including VAT, totals, and line items).
- Ensure unit/currency/tax category codes match the expected lists.

## Common pitfalls

- Wrong participant ID scheme causing PEPPOL routing failures.
- Missing mandatory endpoint IDs for buyer/seller in PEPPOL workflows.
- Invalid unit or VAT codes leading to rejection.
- Sending generic EN 16931 UBL without applying the NLCIUS overlay — may pass syntax validation but fail business rules expected by Dutch buyers.

## Frequently asked questions

### Which invoice channel is most common in the Netherlands?
PEPPOL is the most common structured delivery model, especially for B2G and many B2B exchanges.

### What should I verify before sending a Dutch invoice?
Check the participant ID, KVK or VAT details, UBL structure, and recipient profile settings before sending.

## Official links

- [Dutch government e-invoicing guidance](https://www.rijksoverheid.nl/themas/overheid-en-democratie/zakendoen-met-het-rijk/ik-wil-meedingen-naar-opdrachten)
- [NLCIUS — Forum Standaardisatie](https://www.forumstandaardisatie.nl/open-standaarden/nlcius)

## Related resources

- [Peppol Network Guide](/resources/compliance/peppol-network-guide)
- [UBL (Universal Business Language)](/resources/compliance/ubl-universal-business-language)
- [DIN EN 16931-1 Standard](/resources/compliance/din-en-16931-1-standard)