E-Invoicing & NLCIUS in the Netherlands: The Complete Guide for 2026

E-invoicing in the Netherlands has been mandatory for suppliers to government bodies for years. Yet many organizations find that, in practice, it is more complex than expected. Terms like NLCIUS, EN 16931, Peppol, UBL, Digipoort, and Peppol BIS are frequently mentioned. And if you are working with a legacy ERP system, connecting to these standards can seem even more challenging.

But this is where the risk lies:

If your e-invoice does not comply with the correct standard, it can be rejected. This leads to payment delays, additional administrative work, and frustration for both your team and your customer.

The rules are particularly strict when invoicing Dutch public authorities. Your invoice must not only be digital, but also fully structured and compliant with the European standard EN 16931 as well as the Dutch specification NLCIUS. Sending a PDF by email is therefore not an e-invoice.

You may be wondering:

• When exactly is e-invoicing mandatory in the Netherlands?
• What is NLCIUS, and why does it exist alongside EN 16931?
• What is the difference between NLCIUS and Peppol BIS?
• Do you always have to invoice via Peppol?
• And how can you ensure your organization remains compliant in 2026 and beyond?

In this complete guide, we take you step by step through everything you need to know about e-invoicing and NLCIUS in the Netherlands.

---

Key Takeaways

• E-invoicing has been mandatory since 2017 for suppliers to Dutch government bodies (B2G).
• A PDF is not an e-invoice; a valid e-invoice must be structured and XML-based.
• E-invoices to the government must comply with both EN 16931 and NLCIUS.
• NLCIUS is the Dutch specification of the European EN 16931 standard and includes additional BR-NL validation rules.
• Submission to government bodies is done via Digipoort or Peppol, with Peppol offering better scalability.
• Not every EN 16931 invoice automatically complies with NLCIUS.
• Correct implementation requires alignment between EN 16931, NLCIUS, and Peppol BIS.
• Automation helps prevent rejections, speeds up payments, and reduces administrative workload.
• European initiatives such as ViDA make further digitalization of invoicing increasingly likely.

---

What is an e-invoice?

An e-invoice is a fully structured, electronically exchangeable invoice in XML format that can be processed automatically by software and complies with the European standard EN 16931. A PDF sent by email is not an e-invoice.

That distinction is essential.

Many organizations still send invoices today as PDF files. While that may sound digital, a PDF is essentially just a visual representation of data. An accounting system cannot automatically interpret its contents without additional processing, such as OCR.

A true e-invoice is fundamentally different.

What makes an e-invoice different from a PDF?

An e-invoice:

• Contains structured data in XML format
• Is fully machine-readable
• Can be automatically validated
• Is directly imported into ERP and financial systems
• Complies with defined European standards

As a result, systems can automatically recognize, verify, and process invoice data without manual input.

That means:

• Fewer errors
• Faster processing
• Shorter payment cycles
• Lower administrative costs

For organizations invoicing government bodies, this is especially important, as strict requirements apply to the structure of an e-invoice (which we will cover in more detail later in this guide).

When is e-invoicing mandatory in the Netherlands?

E-invoicing is not mandatory for everyone in the Netherlands, but it is required in specific situations. In particular, clear rules apply when doing business with government bodies.

Let’s break it down.

E-invoicing mandatory for government invoicing (B2G)

Since 1 January 2017, suppliers have been required to send electronic invoices to:

• The central government
• Provinces
• Municipalities
• Water authorities
• Other (semi-)public institutions

This means that as a supplier, you can no longer send a PDF or paper invoice to government entities. The invoice must be submitted as a structured e-invoice that complies with the European standard EN 16931.

In practice, e-invoices to the government are sent via:

• Digipoort (the government gateway), or
• The Peppol network

For fully automated processing and bulk invoicing, Peppol is most commonly used.

Later in this guide, we’ll explain which additional Dutch specifications apply.

Is e-invoicing mandatory for B2B in the Netherlands?

For B2B transactions (between private companies), e-invoicing is not yet mandatory in the Netherlands.

Companies may still invoice using:

• PDFs sent by email
• EDI solutions
• Structured e-invoices

That said, more and more organizations are voluntarily adopting e-invoicing because it:

• Reduces errors
• Lowers administrative costs
• Speeds up payment processes

E-invoicing can become mandatory in B2B scenarios if you do business with companies in other EU countries where national e-invoicing obligations already apply.

What about archiving requirements?

In addition to sending requirements, there are also retention obligations.

In the Netherlands, businesses must:

• Store e-invoices for at least 7 years
• Store invoices related to real estate for 10 years

Invoices must be archived digitally and remain accessible and auditable throughout the entire retention period.

What does this mean for your organization?

Do you work with Dutch government bodies? Then e-invoicing is not optional, it’s mandatory.
Do you operate exclusively B2B? Then it’s not mandatory (yet), but European developments around VAT digitalization and real-time reporting clearly point toward further standardization.

For organizations that want to be prepared for future e-invoicing regulations, it’s wise to already work with the correct standards.

In the next chapter, we’ll take a closer look at the Dutch specification that plays a central role in this: NLCIUS.

What is NLCIUS?

NLCIUS (Netherlands Core Invoice Usage Specification) is the Dutch specification of the European standard EN 16931 for electronic invoicing to government bodies. It defines which data elements an e-invoice in the Netherlands must or may contain, what they mean, and how they relate to each other.

In other words, EN 16931 provides the European foundation, and NLCIUS translates that foundation into Dutch practice.

Why does NLCIUS exist?

The European standard EN 16931 defines the semantic structure of an e-invoice. However, it deliberately leaves room for national extensions.

This flexibility exists so countries can:

• Incorporate national legislation
• Apply country-specific VAT rules
• Standardize administrative practices
• Prevent differences in interpretation

In the Netherlands, these national additions are laid down in NLCIUS.

Without such a specification, individual government bodies could apply their own interpretations. That would lead to inconsistencies between organizations, resulting in invoice rejections and additional administrative work. NLCIUS prevents this.

What does NLCIUS specify in practice?

NLCIUS defines:

• Which data fields are mandatory on an e-invoice to the government
• Which fields are optional or conditional
• How data elements relate to each other
• Which validation rules apply (the so-called BR-NL business rules)

These BR-NL rules (Business Rules Netherlands) are additional checks on top of EN 16931.

Examples include:

• Specific VAT requirements
• Dutch supplier identification details
• Correct combinations of data fields
• Logical checks on totals and amounts

If an invoice does not comply with these rules, the receiving government organization is allowed to reject it.

Who does NLCIUS apply to?

NLCIUS must be applied when organizations participating in the Dutch economy send electronic invoices intended for:

• The central government
• Provinces
• Municipalities
• Water authorities
• (Semi-)public sector institutions

Its scope therefore covers Dutch government bodies and public institutions.

For B2B invoicing, NLCIUS is not mandatory, but it may be applied if both parties agree to use it.

Is NLCIUS the same as Peppol?

No, and this is a very common misconception.

• NLCIUS defines the content and data model of an e-invoice (what must be in the invoice)
• Peppol is a network for exchanging e-invoices
• Peppol BIS is an implementation specification used within that network

NLCIUS is also independent of transport. This means an invoice that complies with NLCIUS can be sent via:

• Peppol
• Digipoort
• Or another technical exchange method

So, Peppol is a possible transport layer, while NLCIUS focuses on content and validation rules.

How does NLCIUS relate to other standards?

NLCIUS does not stand alone. It has a clear relationship with:

• EN 16931 (European standard)
• UBL 2.1 (commonly used XML format in the Netherlands)
• UN/CEFACT CII D16B
• Peppol BIS Billing 3.0
• SETU (in specific sectors)

Important to understand:

NLCIUS mainly defines the semantic model and does not prescribe a single file format. In the Netherlands, UBL 2.1 is most commonly used.

Why is NLCIUS so important?

Without NLCIUS:

• Differences in interpretation arise between government bodies
• Invoices are rejected more frequently
• Businesses face additional administrative work
• E-invoicing becomes more complex than necessary

With NLCIUS:

• Systems can automatically validate invoices
• There is one uniform standard for government invoicing
• Fewer exceptions are required
• The invoicing process becomes more efficient for both government and businesses

As many government organizations have already experienced, a clear and consistent standard makes it possible to build simple, user-friendly solutions that significantly reduce the administrative burden for businesses.

And that is ultimately the goal of e-invoicing.

NLCIUS vs EN 16931 vs Peppol BIS: What’s the Difference?

Many organizations confuse NLCIUS, EN 16931, and Peppol BIS. That’s understandable: they are all related to e-invoicing and partially overlap. However, they serve different purposes and each has its own role.

Here is the difference in one clear overview:

Let’s look at them individually

EN 16931: The European foundation

EN 16931 is the European standard for electronic invoicing for public authorities.

This standard defines:

• Which data elements an e-invoice must contain at a minimum
• What those data elements mean
• How they should be interpreted semantically

EN 16931 ensures that e-invoices across Europe are built on the same structural foundation. It is therefore the baseline for all compliant e-invoices within the EU.

However, the standard allows room for national extensions.

And that is where NLCIUS comes in.

NLCIUS: The Dutch specification

NLCIUS is the Dutch Core Invoice Usage Specification of EN 16931.

This means that NLCIUS:

• Follows the European EN 16931 standard
• Adds additional Dutch-specific rules
• Translates national legislation and practices into concrete validation rules

These additional rules are referred to as BR-NL (Business Rules Netherlands).

Important to understand:

• Every NLCIUS-compliant invoice also complies with EN 16931
• But not every EN 16931 invoice automatically complies with NLCIUS
• When invoicing Dutch public authorities, compliance with NLCIUS is mandatory

Peppol BIS: The network implementation

Peppol is an international network for the secure exchange of e-invoices and other business documents.

Within this network, an implementation specification is used:

Peppol BIS Billing 3.0

Peppol BIS:

• Is based on EN 16931
• Typically uses UBL 2.1
• Includes its own validation rules
• Is designed specifically for use within the Peppol network

This is where complexity can arise.

Although both Peppol BIS and NLCIUS are based on EN 16931, they are not identical. At a detailed level, there are differences in rules and validations.

What are the differences between NLCIUS and Peppol BIS?

For simple invoices, the differences are often limited. However, at a more detailed level, several deviations exist.

Examples include:

• Specific validation rules
• Conditional fields
• National VAT interpretations
• Business rules that exist in one standard but not in the other

When rules differ, there are generally three possible outcomes:

• A rule applies only at national level (BR-NL)
• A change request is submitted to OpenPeppol
• The Dutch specification is updated

This requires careful alignment between NLCIUS and Peppol BIS, especially when future changes are introduced.

In summary

You can think of it as follows:

• EN 16931 = the European foundation
• NLCIUS = the Dutch specification layer
• Peppol BIS = the practical implementation within an exchange network

If you invoice Dutch public authorities via Peppol, your invoice must comply with:

• EN 16931
• NLCIUS
• and the Peppol BIS validation rules

This makes correct implementation essential.

But compliance is only one side of the story. The equally important question is: how do you actually send such an e-invoice in practice?

How does sending e-invoices work in the Netherlands?

Once you create an e-invoice in accordance with EN 16931 and NLCIUS, it must also be sent through the correct channel. In the Netherlands, there are two main options for invoicing public authorities:

• Digipoort (more manual)
• Peppol via an Access Point (automated)

Let’s look at both.

Option 1: Digipoort (manual)

Digipoort is the Dutch government’s digital gateway for electronic message exchange.

Via Digipoort, suppliers can:

• Upload e-invoices
• Submit invoices manually
• Address invoices to specific public-sector organizations

Digipoort complies with the European e-invoicing directive and accepts invoices that are structured according to EN 16931 and NLCIUS.

While Digipoort is a reliable solution, it has limitations:

• Less suitable for bulk invoicing
• More manual steps
• Limited automation
• More complex ERP integrations

For organizations with low invoice volumes, this may be sufficient. However, as volumes increase or automation becomes necessary, Peppol becomes the more attractive option.

Option 2: Peppol via an Access Point (automated)

Peppol (Pan-European Public Procurement Online) is an international network for the secure exchange of e-invoices and other business documents.

Instead of connecting separately to each public authority, you connect once to the Peppol network via a certified Access Point.

This operates according to the “four-corner model”:

1. You (the supplier)
2. Your Access Point
3. The recipient’s Access Point
4. The receiving organization

As a result, you only need a single connection to send invoices to all organizations connected to Peppol.

What is a Peppol ID?

A Peppol ID is a unique identifier that makes your organization recognizable within the Peppol network.

It functions like a digital address.

With a Peppol ID:

• Other organizations can find you in the network
• Invoices are automatically routed correctly
• Systems can verify that you are connected

Without a Peppol ID, you cannot send e-invoices via the Peppol network.

What is the role of a certified Access Point?

A Peppol Access Point is a certified service provider that:

• Connects your organization to the Peppol network
• Validates invoices according to Peppol BIS
• Ensures secure and correct delivery
• Maintains technical updates and compliance

Access Points are certified by national Peppol authorities. In the Netherlands, this is handled by the Dutch Peppol Authority.

This is crucial because validation is not only technical, but must also comply with:

• EN 16931
• NLCIUS
• Peppol BIS

A certified Access Point ensures that your invoices are validated against all these standards before they are sent.

Why is Peppol more scalable than Digipoort?

Peppol is designed for automation and international scale.

Advantages of Peppol:

• Fully automated invoice delivery
• Suitable for high-volume and bulk processing
• Easy integration with ERP systems
• Supports international exchange (not limited to the Netherlands)
• Minimal manual intervention
• Better error handling through pre-validation

Where Digipoort mainly functions as a submission portal, Peppol is a network solution built for continuous, large-scale exchange of structured data.

For organizations that:

• Invoice public authorities on a regular basis
• Operate in multiple countries
• Want to automate their AP/AR processes
• Need to remain NLCIUS-compliant without manual checks

Peppol is generally the most future-proof choice.

Common Mistakes in E-Invoicing in the Netherlands

Although e-invoicing has been mandatory for invoicing public authorities for years, issues still frequently occur in practice. This is especially true when organizations implement e-invoicing themselves without a deep understanding of EN 16931, NLCIUS, and Peppol. Because e-invoices are automatically validated, even small deviations can quickly lead to rejection. These are the most common mistakes:

1. Sending a PDF as an e-invoice

One of the biggest misconceptions: a PDF is not an e-invoice. A PDF:

• Is visually readable
• But not structured
• Cannot be automatically validated against EN 16931 or NLCIUS

Public authorities are allowed to reject such invoices.

2. Incomplete or incorrect VAT data

Within NLCIUS, specific validation rules (BR-NL) apply to VAT information.

Common errors include:

• Incorrect VAT rate
• Missing VAT specification per invoice line
• Incorrect combination of VAT code and amount
• Totals that do not add up

Because e-invoices are validated automatically, these issues almost always result in immediate rejection.

3. Using the wrong format

Not every XML file is automatically compliant.

Common mistakes:

• Using a UBL that is not EN 16931 compliant
• Using an outdated UBL version
• Invoices that do not comply with NLCIUS
• No alignment between NLCIUS and Peppol BIS

Every layer must be correct: the format, the semantic model, and the national specification.

4. Not having a Peppol ID

If you use Peppol, a valid Peppol ID is required.

Without a Peppol ID:

• Invoices cannot be routed correctly
• You cannot receive e-invoices via the network
• Your organization is not discoverable by trading partners

5. Incorrect digital archiving

E-invoices must be:

• Stored for 7 years
• 10 years for invoices related to real estate

And they must:

• Remain digitally accessible
• Be stored without modification
• Be auditable by the tax authorities

Storing only a PDF is not sufficient when the original XML file is the legal invoice.

How Do You Stay Compliant with NLCIUS and Peppol?

Staying compliant means meeting all requirements both technically and semantically. Use this practical checklist to stay on track:

Compliance Checklist

• Use an EN 16931–compliant format
• Comply with all NLCIUS BR-NL business rules
• Check and account for differences between NLCIUS and Peppol BIS
• Automate validation before sending e-invoices
• Ensure proper digital archiving (7–10 years, depending on the invoice type)

Relying on manual checks is risky and time-consuming, especially as invoice volumes increase or as European regulations continue to expand.

That’s why more and more organizations are choosing automation to stay compliant.

How Do You Automate E-Invoicing in the Netherlands?

For error-free, scalable, and future-ready e-invoicing, automation is a fundamental requirement. Especially when you must comply with EN 16931, NLCIUS, and the validation rules of Peppol BIS.

Below is a step-by-step overview of how to automate e-invoicing in the Netherlands, and how Klippa supports this process.

Step 1: Convert Invoices to UBL/XML

The foundation of automated e-invoicing is a correctly structured XML file. Many organizations still work with:

• PDF invoices
• Legacy ERP systems
• Custom internal invoice formats

These formats are usually not suitable for direct delivery via Peppol or Digipoort. That’s why converting PDFs or other formats into a structured e-invoice is the first step.

With Klippa, invoices are automatically converted into:

• UBL 2.1 (the most commonly used standard in the Netherlands)
• XML compliant with EN 16931
• Structures that meet NLCIUS requirements

This process not only converts the format but also validates whether all required fields are present and correctly structured. That way, you don’t need to replace your existing IT landscape to become compliant.

Step 2: Connect to Peppol via a Certified Access Point

Once your invoice is in the correct format, it must be transmitted correctly.

Klippa is certified by the Dutch Peppol Authority and operates as an official Peppol Access Point. This gives you access to the entire Peppol network through a single connection.

In this step:

• A Peppol ID is requested for your organization
• Invoices are automatically validated against Peppol BIS
• Compliance with EN 16931 and NLCIUS is verified
• The invoice is securely delivered to the receiving party

You don’t need to build individual technical integrations with government bodies or manage complex contractual setups.

Step 3: Integrate with Your ERP, CRM, and Financial Systems

Automation is only truly effective when e-invoicing is fully integrated into your existing processes.

Using a plug-and-play API, you can:

• Integrate e-invoicing directly into your ERP or accounting software
• Automate synchronization between internal systems and Peppol
• Process invoices in bulk
• Digitize both accounts payable (AP) and accounts receivable (AR)

Even organizations with legacy systems can implement integrations without fully modernizing their infrastructure.

Step 4: Set Up Proper Digital Archiving (7–10 Years)

Sending invoices alone is not enough. Dutch legislation requires e-invoices to be stored for:

• At least 7 years, or
• 10 years for real-estate-related invoices

With Klippa, e-invoices are automatically:

• Stored digitally in the correct XML structure
• Securely archived in a cloud environment
• Processed in an ISO-certified setup
• Managed in full GDPR compliance

This ensures invoices remain accessible, verifiable, and legally valid throughout the entire retention period.

Step 5: Automate Validation and Fraud Prevention

The final step is continuous control.

During conversion and transmission, invoices are automatically:

• Validated against EN 16931
• Checked against NLCIUS BR-NL business rules
• Tested against Peppol BIS validations
• Analyzed for inconsistencies or anomalies

This allows errors to be detected early, preventing rejections and payment delays. At the same time, it reduces the risk of invoice fraud or data manipulation.

Why Start with NLCIUS-Compliant E-Invoicing Now?

E-invoicing for Dutch government entities is no longer a future requirement, it has been mandatory since 2017. Yet many organizations still struggle with the correct implementation of EN 16931, NLCIUS, and Peppol BIS.

And that’s a missed opportunity. Because NLCIUS-compliant e-invoicing is about working more efficiently.

When you set up your e-invoicing process correctly, you:

• Comply with the Dutch B2G e-invoicing mandate
• Reduce errors through automatic validation
• Prevent invoice rejections and payment delays
• Speed up payment cycles
• Lower administrative workload
• Prepare for future European initiatives such as ViDA

In short, you turn a legal obligation into a strategic advantage.

With the increasing digitalization of the public sector, and the possibility of future B2B e-invoicing requirements, it makes sense to invest now in a scalable solution, rather than waiting until regulations become more restrictive.

Why Do Organizations Choose Klippa for E-Invoicing?

If you want to set up e-invoicing properly, without complex implementations or the risk of non-compliance, you need an e-invoicing solution that covers every layer of the process: conversion, validation, delivery, and archiving.

With Klippa, you get:

• Conversion to UBL 2.1 and XML compliant with EN 16931 and NLCIUS
• A certified Peppol Access Point (Dutch Peppol Authority)
• Automatic validation against BR-NL rules and Peppol BIS
• Direct Peppol ID registration
• Full digital archiving (7–10 years compliant)
• ISO-certified and GDPR-compliant processing
• A plug-and-play API for fast integration
• Integrations with ERP, CRM, and financial systems
• Support for legacy software
• Up to 60% cost savings through automation

This makes e-invoicing not only compliant, but also scalable, efficient, and future-proof.

Are you an organization that is not yet fully compliant with NLCIUS or Dutch e-invoicing requirements? Or are you looking for the right e-invoicing software solution? Get in contact with us or schedule a demo, we’ll guide you step by step toward full compliance.

FAQ