Custom NLCIUS integration
Appfront builds integrations that create and read e-invoices in line with NLCIUS, the Dutch implementation of the European e-invoicing standard. NLCIUS is mandatory for invoices to the Dutch government and is increasingly requested between businesses. We make sure your own invoicing system produces an invoice that meets the rules, validates it before sending, and reads incoming e-invoices into your accounts.
What is an NLCIUS integration?
NLCIUS is the Dutch implementation of the European e-invoicing standard, EN 16931. An NLCIUS invoice is a structured file, usually in UBL, with fixed fields and rules: which data is mandatory, how it is recorded and how it is validated. NLCIUS is mandatory for invoices to the Dutch government, and it is increasingly requested between businesses too. Peppol is often used for transmission; NLCIUS governs the content.
A standard accounting package often already produces e-invoices. But companies with their own invoicing system, their own ERP or an order platform often don't have that. An invoice to the government is then sent as a PDF and comes back rejected. Or an e-invoice is rejected because of a missing field, and nobody can see why. And on the receiving end, e-invoices are still opened as PDFs and retyped.
We build custom software because the integration has to fit your system: where the data on an invoice comes from, which customers ask for e-invoices, which channel you use for sending, and where received invoices should go. We check what your invoice lines require against the NLCIUS validation rules.
Invoices to the standard
Invoices from your own system converted to UBL under NLCIUS, with all mandatory data included.
Checked in advance
Validation against the rules before sending, so an invoice is not rejected by the recipient.
Received and processed
Incoming e-invoices imported into your accounting or purchasing system, without re-keying.
How we build your NLCIUS integration
We start with your invoices: which system they come from, who requests e-invoices, and how you currently send and receive them.
Your invoicing system, the data per invoice, your customers and the channel for sending.
Invoices converted to UBL under NLCIUS, and checked against the validation rules.
Sending via Peppol or another channel, and importing incoming e-invoices.
Testing with real invoices and recipients, going live, and maintenance when the rules change.
What an NLCIUS integration actually does
The components below come up in almost every NLCIUS integration. Which ones you need depends on your role.
Conversion
Invoices from your system converted to UBL under NLCIUS.
Validation
Validation against the rules before sending.
Dispatch
Sending via Peppol or whichever channel the recipient requires.
Receiving
Incoming e-invoices imported into accounting or purchasing.
Notifications
A notification with the reason when an invoice is rejected.
Audit log
Per invoice sent or received, and with what outcome.
Who we build NLCIUS integrations for
The integration is intended for organisations where the standard package does not produce e-invoices.
Suppliers to government
Invoices to government bodies. An invoice that never comes back is the core problem.
Companies with their own ERP
Invoices from an in-house system. Conversion and validation matter most.
Organisations that receive invoices
High volumes of purchase invoices. Reading them in without retyping is what counts.
Software suppliers
Invoicing within your own product. Support for the standard is the core requirement.
Technology and integrations
This page covers the content of e-invoices under NLCIUS. For sending through the Peppol network, see our page on a Peppol integration; for bookkeeping, our page on an Exact Online integration; and for purchase invoices, our page on accounts payable management. You can read how we work at getting software built.
For orders, delivery notes and catalogues in UBL, alongside the invoice, see our page on a UBL integration.
Why choose Appfront for your NLCIUS integration?
An invoice that gets rejected is paid late. That is what we build around: invoices that meet the standard, checked before they are sent, and received invoices that flow straight into your accounts.
Not rejected
Pre-send validation catches what the recipient would reject.
No retyping of PDFs
Received e-invoices flow straight into your accounts.
Ready for government
Invoices to government bodies in the format they require.
Security and privacy in an NLCIUS integration
The integration processes invoices containing customer and supplier details and amounts. Access credentials for sending channels are stored encrypted and used only by the integration.
The integration runs in a European data centre, with encrypted storage, daily backups and a log of every invoice.
Frequently asked questions about an NLCIUS integration
Questions businesses ask before getting started.
NLCIUS is the Dutch implementation of the European e-invoicing standard, EN 16931. It defines which data an e-invoice must contain and how it is validated, usually in the UBL format. An invoice that complies with NLCIUS can be read in automatically by the recipient, without anyone retyping a PDF.
NLCIUS concerns the content of the invoice. Peppol is a network for sending e-invoices. They are often used together: an invoice that follows the rules, sent via Peppol.
For invoices to the Dutch government, e-invoices that comply with the standard are required. Between businesses it is not yet mandatory everywhere, but large customers increasingly ask for it. Your adviser can help you establish what applies to you.
Yes. Every invoice is checked against the validation rules before it is sent, with a clear message if something is missing or incorrect, such as a missing VAT number, a customer order number or an error in the amounts. This lets you fix the problem before the customer sees the invoice.
Yes. Received e-invoices are read into your accounting or purchasing system, with supplier, amounts and line items, without retyping. Invoices that cannot be read in are held for review, with the reason given.
Yes, that is precisely what this integration is for. We take the data from your system and convert it. A standard accounting package often has this built in already. In the first step, we look at which data from your system is needed and which is still missing.
The validation rules sometimes receive a new version. In maintenance, we adjust the integration accordingly, so your invoices continue to comply.
E-invoices that never come back?
Tell us which system your invoices come from, who requires e-invoices, and how you currently send and receive them. We will show you what the integration would look like.