E-Invoicing in the Netherlands: Simpler Invoicing, NLCIUS and Reaching a Dutch Buyer

The short answer

If you supply goods or services to Dutch central government, you must invoice electronically — that has been the rule for new procurement contracts since 1 January 2017. If you invoice any other Dutch public body — a municipality, a province, a water board, any organisation subject to procurement law — that body has been obliged since 18 April 2019 to be able to receive and process an invoice in the European format, EN 16931. Both facts come from the Dutch government's own legislation table, published by Logius.

In practice that means Peppol. The Netherlands has its own profile of the European standard — the thing people still search for as Simpler Invoicing, and which is now properly called SI-UBL 2 (NLCIUS) — and its own rule about which number identifies a government buyer. That second rule is where most first invoices fail, so it has a section to itself below.

Who in the Netherlands must send an e-invoice?

Read the Dutch rules as two obligations pointing in opposite directions, because conflating them is the commonest mistake.

The obligation to send falls on suppliers to central government. Logius states it in one line: "Voor iedereen die goederen of diensten aan de Rijksoverheid levert is e-factureren verplicht" — for everyone who supplies goods or services to central government, e-invoicing is compulsory. The legislation table dates it to new procurement contracts entered into after 1 January 2017.

The obligation to receive falls on the buyer, and it is much wider. From 18 April 2019 every contracting authority in the Netherlands — central government, municipalities, provinces, water boards and all other bodies subject to procurement law — must be able to receive and process an invoice in the European format. That obligation is the Dutch implementation of the EU's public-procurement e-invoicing directive, and the national translation of it was made on 6 September 2018.

There is a third date worth knowing because it explains the maturity of the Dutch system: central government has been able to receive e-invoices through Digipoort, the government's own message gateway, since 1 January 2011. The Netherlands is not standing up this capability now. It has been running it for fifteen years.

What about business-to-business?

The rules above are procurement rules. They govern invoicing to the public sector, and they do not create a general obligation between two private companies in the Netherlands. Where a Dutch business sends structured invoices to another Dutch business today, it is usually because the buyer asked, or because the supplier's accounting software already does it.

What is settled, and dated, is the European layer. The VAT in the Digital Age package — Council Directive (EU) 2025/516 — makes structured e-invoicing on EN 16931 the basis for intra-EU cross-border B2B transactions from 1 July 2030, with digital reporting alongside it.

We are not going to give you a Dutch domestic B2B date, because we do not have one we can source to the Dutch government. If you have read one elsewhere, check whose announcement it came from before you plan around it. Our neighbouring guide to Belgium is a useful contrast: Belgium does have a domestic B2B mandate, live since 1 January 2026, and the difference between the two countries is real rather than a matter of interpretation.

What is Simpler Invoicing, and what is NLCIUS?

This is the question behind most Dutch searches that reach us, and the answer has two halves.

The organisation is gone. Stichting Simplerinvoicing — the Dutch foundation that built the profile — ceased to exist on 31 December 2020. Its website redirects to the Netherlands Peppol Authority (Nederlandse Peppolautoriteit, NPa), which took over the role and operates on behalf of the Ministry of the Interior and Kingdom Relations.

The profile did not go anywhere. What Simplerinvoicing built lives on as SI-UBL 2.0, the Dutch narrowing of EN 16931, written in the Authority's own publications as SI-UBL 2 (NLCIUS). It is still maintained on the ordinary Peppol release schedule: the Authority published its most recent validation artefacts in the May 2026 release, on 22 May 2026, with the release before it in November 2025.

So if you are searching for Simpler Invoicing, SI-UBL 2 is what you are looking for, and the Netherlands Peppol Authority is who maintains it. The format question — what UBL is, what a CIUS narrows, and how the layers stack — is answered in full in What is a UBL invoice?; this page stays on the country.

Which standards must an invoice to a Dutch buyer use?

The Netherlands Peppol Authority names them explicitly, and there are three:

It also names which Peppol identifiers may be used when a message is sent to a Dutch entity:

The OIN is required for central government, provinces and municipalities. Other organisations may choose between the KVK and VAT forms.

The OIN rule that fails a first invoice

If you take one operational fact from this page, take this one. The Dutch central government's own supplier helpdesk answers the question directly:

Can I use a KVK number instead of the OIN? No. The OIN is compulsory on an e-invoice to central-government organisations. If you fill in a number other than the OIN, your e-invoice will not be accepted.

Three practical consequences follow.

The OIN is a twenty-digit number, and it belongs to the buying organisation, not to you. A large ministry may have more than one.

It is written in your order letter. If it is not there, the helpdesk's instruction is to ask the organisation that placed the order — not to guess, and not to substitute a number you do have.

The old public list of OINs has been withdrawn. Logius used to publish an alphabetical index of government bodies and their invoicing OINs; that page now says the information has been removed and will eventually be deleted altogether. The two routes that remain are your order letter and a lookup in the Peppol Directory.

How do you reach a Dutch buyer through Peppol?

The Dutch government's helpdesk sets out four routes, and the difference between them is mostly a question of how many invoices you send.

1. Your own accounting package. Many Dutch packages are already connected to Peppol. This is the cheapest answer when it applies, and the question to put to your software vendor is not "do you support e-invoicing" but "are you on Peppol".

2. A service provider bolted onto your package. The usual answer when the package itself is not connected. A service provider — an access point — connects it.

3. A general invoice portal. These reach central government and municipalities, water boards and ordinary companies. Pricing is set by each provider; free tiers commonly exist and are usually bounded by volume or features.

4. The government's Supplier Portal. You type the invoice in by hand and send it. It is the right answer for an occasional invoice and the wrong one for a stream, because it reaches central government only — no municipality, no water board, no company.

Being reachable is a separate question from being able to send

Reaching a Dutch buyer over Peppol means their address must be findable. Receivers are published by a Service Metadata Publisher (SMP) — the register that says which documents an organisation accepts — and SMPs in turn register with the central Service Metadata Locator (SML), which is production only. Testing happens against the SMK, the SML's test environment.

The Netherlands Peppol Authority states a caveat about the international Peppol Directory that is worth repeating, because it catches people out: the Directory tells you an organisation receives documents over Peppol. It does not tell you whether that organisation also sends them. Do not read a Directory entry as evidence that your supplier will invoice you electronically.

What trips up a first Dutch invoice?

These are the answers the government's own helpdesk gives most often, gathered in one place.

• The invoice number must be unique. A number reused in the Supplier Portal is rejected.
• A sent invoice cannot be edited. The correction path is to credit the sent invoice in full, raise a new one, and state the reason for the credit in the description or comments field.
• Attachment limits differ by route. Over Peppol: a maximum of nine attachments totalling 20 MB. Through the Supplier Portal: 14 MB. A few ministries set lower limits of their own.
• You do not need to attach the PDF. Your buyer's system reads the structured invoice. Attach the PDF only if the order letter asks for it.
• No KVK or DUNS number means no e-invoice. If your business has neither, the helpdesk's instruction is to tell the buyer, who will explain how to submit the invoice another way.
• The VAT identifier has a shape: NL123456789B01, with no dots and no spaces. A sole trader enters the btw-id, not the older turnover-tax number.
• The order number is in the order letter. If it is missing, ask the buyer.

How do you test before you send?

The Netherlands Peppol Authority publishes a Peppol Test Tool with four functions, and it is free to use:

1. Find receivers — look up whether an organisation receives Peppol documents, by KVK, OIN or VAT number. It searches identifiers, not names.
2. Document validation — check an XML file against the applicable standards before anyone sees it.
3. Send test — check that your message actually transmits.
4. Application test — exercise your ERP or accounting package end to end, which is the one most people skip and the one that finds real problems.

Testing before the first live send is the same discipline we describe for any network in Peppol test bed: how to test before you go live. It costs an afternoon and it is cheaper than a rejected invoice explained to a customer.

What this page does not tell you

Two honest gaps, stated rather than papered over.

We do not give a Dutch domestic B2B mandate date, because no Dutch government source we can point to sets one. The dated European commitment is ViDA's 1 July 2030 for intra-EU cross-border B2B, and that is the only date on this page for anything outside public procurement.

We do not reproduce the full Dutch validation rule set here. The rules that decide whether an invoice to a Dutch party passes or fails — the identity, address, credit-note and payment-means constraints — are set out with their rule codes in What is a UBL invoice?, which is the right place for them. The Authority's own release notes are the authority, and they move on the Peppol release schedule.

How GoRoute fits

GoRoute is a Peppol access point. Sending to a Dutch buyer means validating the document against Peppol BIS Billing 3.0 and SI-UBL 2, resolving the receiver through the SMP and SML, and delivering over AS4 — the same path our Belgium customers already use, with the Dutch profile and the Dutch identifier rules applied instead. If you want to see where a document would fail before you send it, that is what our validation does, and the glossary defines every term on this page in one place.

Sources

Every Dutch statement on this page comes from one of these, each read on 2026-08-23:

• Logius — E-factureren and its how-it-works page — the obligation on suppliers to central government, what counts as an e-invoice, and the routes for sending one. Logius runs the Dutch government's digital infrastructure on behalf of the Ministry of the Interior and Kingdom Relations.
• Logius — e-invoicing legislation table — the dated milestones: 1 January 2011, 1 January 2017, 6 September 2018 and 18 April 2019.
• Netherlands Peppol Authority — technical specifications — the three mandatory standards, the Dutch Peppol identifier schemes, the SMP/SML/SMK arrangement, the Peppol Directory caveat and the Peppol Test Tool.
• Helpdesk e-factureren (Dutch central government) — the four sending routes, the OIN rule, the attachment limits and the correction procedure. An English version is published.
• Directive 2014/55/EU and Council Directive (EU) 2025/516 — the European obligations that sit above the Dutch ones.