Netherlands NLCIUS

Generate and validate Peppol BIS Billing 3.0 UBL with the Dutch NLCIUS (SI-UBL 2.0) Schematron overlay; Digipoort submission stays with your Access Point.

NLCIUS is the Netherlands’ national Core Invoice Usage Specification on top of Peppol BIS Billing 3.0 UBL, maintained by the Nederlandse Peppol Autoriteit (NPa) at peppolautoriteit-nl/validation (MIT-licensed; STPE / Stichting Simplerinvoicing copyright). NLCIUS is the cited Dutch CIUS recognised by EC eInvoicing-Netherlands and used for Digipoort B2G submissions when the receiving authority opts into the stricter overlay.

Beliq targets SI-UBL 2.0 version 2.0.3.13 (vendored from the NPa 2026-05-21 GitHub release). The cbc:CustomizationID URN prefix is matched starts-with:

The starts-with match allows the trailing v1.0.x minor-version increments to validate without engine re-pinning.

What Beliq emits

Call POST /v1/generate with standard: "peppol-bis" and profile: "netherlands-nlcius". The output is xml (PDF output is not defined for NLCIUS; the format is UBL only).

{
  "standard": "peppol-bis",
  "profile": "netherlands-nlcius",
  "output": "xml",
  "invoice": {
    "number": "2026-NL-0001",
    "issueDate": "2026-06-09",
    "currencyCode": "EUR",
    "buyerReference": "BUYER-REF-NL-001",
    "seller": {
      "name": "Verkoper B.V.",
      "vatId": "NL123456789B01",
      "peppol": { "schemeId": "0106", "id": "12345678" },
      "address": {
        "street": "Damrak 1",
        "city": "Amsterdam",
        "postalCode": "1012LG",
        "countryCode": "NL"
      }
    },
    "buyer": {
      "name": "Koper B.V.",
      "vatId": "NL987654321B02",
      "peppol": { "schemeId": "0106", "id": "87654321" },
      "address": {
        "street": "Coolsingel 2",
        "city": "Rotterdam",
        "postalCode": "3011AA",
        "countryCode": "NL"
      }
    }
  }
}

The builder emits the current urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0 URN on cbc:CustomizationID. Everything else (party endpoints, addresses, VAT IDs, invoice lines, tax breakdown, totals) follows the standard Peppol BIS 3.0 UBL layout.

Invoice.netherlands is an optional namespace reserved for future NL-specific fields. It is intentionally empty today because the engine consumes only generic UBL fields for NLCIUS; the NL-specific legal-entity-identifier requirements are satisfied via the existing peppol block (see below).

NL legal-entity identification: KvK and OIN routing

NLCIUS adds two rules that distinguish it from plain Peppol BIS:

• BR-NL-1 — Dutch suppliers MUST provide a KvK Chamber of Commerce or OIN identifier as a legal-entity identifier (not just a VAT id).
• BR-NL-10 — When the customer is also in the Netherlands, the same requirement applies on the buyer side.

Beliq satisfies both by routing the legal-entity identifier through the existing Party.peppol block, using one of the Dutch ISO 6523 ICD schemes:

Beliq’s ISO 6523 ICD emission writes cac:PartyLegalEntity/cbc:CompanyID@schemeID from the peppol block whenever the scheme is in the 0xxx range — so passing {schemeId: "0106", id: <kvk>} satisfies both rules without a dedicated namespace.

For cross-border invoices where Dutch suppliers route via VAT, you can still emit a KvK identifier separately by using 0106 on the seller peppol block; this puts the KvK at PartyLegalEntity and the VAT id at PartyTaxScheme (different UBL slots, no conflict).

NL-specific fields you already use

These are standard UBL / EN 16931 fields that the NLCIUS Schematron enforces for Dutch invoices. Beliq emits them from generic invoice data; you don’t need a NL-specific namespace to populate them.

Validation pipeline

For NLCIUS the validation chain runs the same XSD + Schematron stack as cross-border Peppol, with the NL overlay layered on top:

Input → UBL 2.1 XSD → NLCIUS XSLT (EN 16931 + Peppol BIS + BR-NL-* rules) → Result

A single vendored XSLT runs — si-ubl-2.0.xsl covers both ubl:Invoice and cn:CreditNote. This is distinct from Romania (which fires two XSLTs in sequence: CIUS rules + operational rules). The NPa-compiled XSLT bakes in the EN 16931 and Peppol BIS rules, so firing the NLCIUS XSLT alone is sufficient. Errors carry their original Dutch rule IDs (BR-NL-*).

When validation passes, the /v1/validate response includes:

{
  "valid": true,
  "format": "ubl",
  "profileDetected": "netherlands-nlcius",
  "ciusVersion": "2.0.3.13",
  "netherlandsNlciusVersion": "2.0.3.13",
  "errors": [],
  "warnings": []
}

The netherlandsNlciusVersion field mirrors ciusVersion for NL-specific consumers (mirror of romaniaRoCiusVersion for Romania).

Verification

NLCIUS is Authority-checked (fully-verified) — the only format in Beliq’s catalogue to hold the fully-verified depth qualifier. Beliq runs the authority’s own NPa SI-UBL 2.0 XSLT against the full 120-fixture NPa Tier-1 testset (expected outcome encoded in each filename), with a fail-closed manifest drift-check. A rule-coverage audit confirms a Tier-1 negative the engine rejects for every critical rule family (BR-NL-*, BR-CO-15, BR-S-08, BR-CL, UBL-CR-561, UBL-SR, BII2-T10-R001, and the EN 16931 base BR-* rules).

Two residuals are documented: UBL-SR-09 / UBL-SR-15 reject via an upstream XSLT XPTY0004 type error (the document is still rejected, via a transform crash rather than a clean assertion; a candidate upstream issue to raise with NPa), and BR-NL-34 fires under the BR-NL-32 id. Neither blocks fully-verified status (the bar is one Tier-1/Tier-2 negative per critical rule family). The corpus is the authority’s own Tier-1 testset; no spec-derived (Tier-3) fixtures are used here.

Further reading

• Netherlands country guide — mandate timing, transmission boundary, Digipoort + SimplerInvoicing routing.
• Peppol BIS format reference — base format Beliq layers NLCIUS on top of.
• NPa validation repository: github.com/peppolautoriteit-nl/validation
• NPa publications: github.com/peppolautoriteit-nl/publications
• EC eInvoicing-Netherlands: ec.europa.eu/…/eInvoicing+in+The+Netherlands