Netherlands
Dutch B2G e-invoicing with Beliq, Peppol BIS 3.0 UBL, EAS 9944 NL:VAT routing, and the Logius / Digipoort / SimplerInvoicing transmission boundary; NLCIUS overlay validation is implemented and authority-checked.
The Netherlands’ e-invoicing landscape uses Peppol BIS Billing 3.0 UBL (EN 16931) on the cross-border path. The country also maintains a national CIUS overlay on Peppol BIS, NLCIUS, which Beliq implements and validates (see the NLCIUS section below). Authority: Logius (Dutch government gateway operator); the Dutch Peppol Authority oversees Peppol operations.
So a Dutch invoice in Beliq is a Peppol BIS invoice with Dutch parties (EAS 9944 NL:VAT, or secondary 0106 KvK / 0190 OIN). See the Peppol BIS format reference for the full element layout.
Mandate timing
Dutch public bodies have accepted Peppol e-invoices for years. There is no domestic B2B mandate today; the next hard date is the EU-wide ViDA obligation for cross-border trade.
| Date | What changes |
|---|---|
| 2019 | Public-sector bodies must be able to receive EN 16931 e-invoices; central government has required them since 2017. |
| 1 July 2030 | EU ViDA introduces mandatory structured e-invoicing and digital reporting for cross-border B2B. |
There is no domestic B2B e-invoicing mandate today; B2B e-invoicing is voluntary and needs the recipient's agreement. The next hard date is the EU ViDA cross-border obligation.
Last verified against the European Commission eInvoicing Netherlands country page and the Aanbestedingswet central-government obligation of 1 January 2017 on 24 August 2026. Official source.
If you sell to Dutch public-sector buyers today, you are already in scope. B2B remains voluntary until ViDA harmonisation lands. For the dates Beliq tracks across every covered country, see the mandate calendar.
What Beliq does today
- Generate Dutch Peppol invoices via
standard: "peppol-bis"(profilepeppol), addressed with the Dutch VAT endpoint scheme (NL:VAT, Peppol EAS9944). Secondary schemes0106(KvK Chamber of Commerce) and0190(OIN Dutch Originator’s Identification Number) are also accepted. - Validate and parse Peppol BIS UBL against the full EN 16931 + Peppol BIS 3.0 Schematron (
peppolVersionin the response). - Validation depth on the plain Peppol path is Authority-checked: Beliq asserts verdict parity against OpenPeppol’s own unit-test corpus (62 testSets, 335 cases) plus its 10 published example invoices. OpenPeppol’s own Dutch rules (the
NL-R-*family, which is not the NLCIUS overlay described below) ride that same pinned Schematron, and OpenPeppol’s Dutch unit-test suite (9 testSets, 21 cases) is vendored and asserted beside the shared one. See how verification works for the tier definitions and theverificationTierfield that reports them.
NLCIUS validation
NLCIUS is the Netherlands’ national CIUS overlay on Peppol BIS, maintained by the Nederlandse Peppol Autoriteit (NPa) at peppolautoriteit-nl/validation (MIT-licensed; STPE / Stichting Simplerinvoicing copyright). It tightens Peppol BIS for Dutch domestic use cases with BR-NL-* Schematron rules — most notably BR-NL-1 and BR-NL-10 requiring Dutch suppliers + domestic customers to carry a KvK (Chamber of Commerce) or OIN legal-entity identifier in addition to the VAT id.
Beliq implements NLCIUS via the dedicated netherlands-nlcius profile (current artifact: NPa SI-UBL 2.0 version 2.0.3.13). Call POST /v1/generate with standard: "peppol-bis" and profile: "netherlands-nlcius"; validation routes through the dedicated NLCIUS arm in the engine and surfaces netherlandsNlciusVersion in the response. The overlay is Authority-checked: the full 120-fixture NPa SI-UBL 2.0 authority testset is vendored and asserted by a Schematron-only harness. See the Netherlands NLCIUS format reference for the compliance detail.
For the full technical contract (URN prefix, vendored XSLT, response metadata, BR-NL routing via KvK EAS 0106), see the Netherlands NLCIUS format reference.
In practice, both paths are available. Use the plain peppol profile for cross-border Dutch B2B; use the netherlands-nlcius profile when the receiving party (typically a Dutch public-sector body or a strict private-sector consumer) opts into the stricter overlay.
What Beliq does not do (Peppol transmission boundary)
The Netherlands’ network is the Peppol Network. Beliq is not a Peppol Access Point. It does not:
- Transmit invoices over Peppol or register you as a Dutch Peppol participant.
- Operate the 4-corner exchange on your behalf.
- Submit invoices to Digipoort on your behalf (Digipoort submission is Peppol-AP-routed BYOC).
- Submit signed documents to Digipoort on your behalf (the gateway is Peppol-AP-routed BYOC).
Today you send Beliq’s UBL output through your chosen Access Point (BYOC). Managed delivery over Peppol is in build, targeting Q4 2026 and subject to certification.
Integration architecture (Beliq vs Peppol Access Point vs Digipoort)
| Concern | In Beliq today | Outside Beliq (your stack / partner) |
|---|---|---|
| Peppol BIS 3.0 UBL invoice XML | Generate, Validate, Parse | — |
| Peppol Network transmission (4-corner) | Not offered, see boundary above | Your Access Point provider |
| Digipoort B2G submission | Not offered (Peppol-AP-routed BYOC) | Your Access Point provider |
| NLCIUS overlay validation | Offered via the netherlands-nlcius profile (SI-UBL 2.0.3.13) — see Netherlands NLCIUS format reference |
— |
| SimplerInvoicing routing | Not offered | Your Access Point provider |
Generating a Dutch Peppol invoice
Address both parties with the Dutch VAT endpoint scheme (NL:VAT, EAS 9944) via the peppol block. Use EUR for the invoice currency. Provide either a buyerReference or an orderReference (Peppol requires one). The simpler alternative is to omit the peppol block and pass a vatId (NL…B…) + address.countryCode: "NL"; Beliq then derives the NL:VAT scheme (9944) automatically.
curl -X POST https://api.beliq.eu/v1/generate \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"standard": "peppol-bis",
"profile": "peppol",
"output": "xml",
"invoice": {
"number": "2026-0001",
"issueDate": "2026-06-04",
"currencyCode": "EUR",
"buyerReference": "NL-PO-7711",
"seller": {
"name": "Test Verkoper B.V.",
"vatId": "NL123456789B01",
"peppol": { "schemeId": "9944", "id": "NL123456789B01" },
"address": { "street": "Damrak 1", "city": "Amsterdam", "postalCode": "1012 LG", "countryCode": "NL" }
},
"buyer": {
"name": "Test Koper B.V.",
"vatId": "NL987654321B02",
"peppol": { "schemeId": "9944", "id": "NL987654321B02" },
"address": { "street": "Coolsingel 2", "city": "Rotterdam", "postalCode": "3011 AA", "countryCode": "NL" }
},
"lines": [
{
"description": "Professional services",
"quantity": 1,
"unitCode": "C62",
"unitPrice": 100.00,
"lineTotal": 100.00,
"vatRate": 21,
"vatCategoryCode": "S"
}
],
"taxSummary": [
{ "vatCategoryCode": "S", "vatRate": 21, "taxableAmount": 100.00, "taxAmount": 21.00 }
],
"paymentMeans": {
"typeCode": "30",
"iban": "NL91ABNA0417164300"
},
"totalNetAmount": 100.00,
"totalTaxAmount": 21.00,
"totalGrossAmount": 121.00
}
}'Validation behaviour
On /v1/validate and /v1/generate, Dutch invoices on the plain peppol profile run the full EN 16931 + Peppol BIS 3.0 Schematron; failures carry the relevant BR-* / PEPPOL-* rule id. The response reports profileDetected: "peppol" and a peppolVersion. CreditNote payloads are supported (documentType: "creditnote"). The NLCIUS-specific BR-NL-* rules do not fire on this plain peppol path; select the netherlands-nlcius profile to validate the NLCIUS overlay (see the NLCIUS section above).