What is a CIUS?
A Core Invoice Usage Specification (CIUS) is a formal set of rules that adapts the EN 16931 European e-invoicing standard for a specific country, sector, or use case. The key constraint: a CIUS can only restrict the standard — never expand it. Any invoice that conforms to a CIUS automatically conforms to EN 16931, which means any system built to process EN 16931 invoices can also process CIUS-compliant invoices without modification.
This restriction-only principle is the defining feature of a CIUS and the reason it preserves interoperability across the European e-invoicing ecosystem.
What a CIUS Can Do
EN 16931-1 (Section 7) defines exactly which amendments a CIUS is permitted to make:
1. Make optional fields mandatory. A field that is conditional (0..1) in EN 16931 can be made required (1..1) in a CIUS. Example: XRechnung makes BT-10 (Buyer Reference) mandatory, while EN 16931 leaves it conditional.
2. Reduce cardinality. A repeating field (0..n) can be limited to a single occurrence (0..1 or 1..1). The CIUS cannot increase the maximum.
3. Mark fields as not used. A CIUS can declare that certain optional fields should not be populated in its context.
4. Restrict code lists. If EN 16931 allows a broad code list (e.g., all UNTDID 1001 document type codes), a CIUS can limit it to a subset relevant to its jurisdiction.
5. Constrain data types. A CIUS can impose stricter formatting rules — for example, limiting a free-text field to a maximum character length or requiring a specific date format.
6. Add business rules. A CIUS can introduce new validation rules (Schematron assertions) that further constrain valid combinations of fields. These rules must not conflict with existing EN 16931 rules.
7. Add synonyms and descriptions. A CIUS can provide localized names and explanatory text for business terms without changing their semantics.
What a CIUS Cannot Do
Equally important is what a CIUS is not permitted to do:
If a use case requires any of these "expansive" amendments, it must be defined as an Extension rather than a CIUS.
CIUS vs. Extension
The distinction matters for interoperability:
A receiver that supports EN 16931 is implicitly able to process any CIUS-conformant invoice (they may ignore extra constraints they don't enforce). An Extension, however, may contain data elements the receiver's system does not understand.
In practice, some specifications blur this line. Factur-X Extended profile, for example, adds fields beyond EN 16931 and is technically an Extension, not a CIUS — even though Factur-X EN 16931 profile is a proper CIUS.
Major CIUS Implementations
Peppol BIS Billing 3.0
The most widely adopted CIUS, used across 39+ countries in the Peppol network. It uses UBL 2.1 syntax and adds Peppol-specific business rules (e.g., requiring EndpointID for electronic delivery). Identified by CustomizationID:
urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0XRechnung (Germany)
Germany's B2G CIUS, maintained by KoSIT. Notable for making BT-10 (Buyer Reference / Leitweg-ID) mandatory and adding ~15 additional German-specific Schematron rules (BR-DE-xx series). Supports both UBL and CII syntax. Current version: XRechnung 3.0.2.
CIUS-IT (Italy)
Italy's national CIUS mapping EN 16931 to the FatturaPA format used by the SDI clearance system. Adds Italian-specific rules for fiscal codes (Codice Fiscale), stamp duty (bollo), and withholding tax.
Factur-X / ZUGFeRD (France / Germany)
The EN 16931 profile of Factur-X/ZUGFeRD is a CIUS that uses CII syntax and embeds the XML in a PDF/A-3 container. The Extended profile exceeds CIUS boundaries and is technically an Extension.
NLCIUS (Netherlands)
The Dutch national CIUS, maintained by STPE. Adds rules for Dutch VAT number formatting and requires specific electronic address schemes.
EHF (Norway)
Norway's CIUS for public-sector invoicing, now aligned with Peppol BIS 3.0 since 2019. Previously maintained as a separate specification.
BEcius (Belgium)
Belgium's CIUS supporting the January 2026 B2B e-invoicing mandate via Peppol.
How a CIUS Is Identified in XML
Every EN 16931 invoice carries a Specification Identifier (BT-24) that declares which CIUS it conforms to. This is the CustomizationID element in UBL or the GuidelineSpecifiedDocumentContextParameter in CII.
The identifier uses a hierarchical URN structure:
urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0
└── base standard ──────┘ └── CIUS identifier ─────────────────┘
The #compliant# fragment signals that the document is a CIUS (restriction-only). An Extension would use #conformant# instead, indicating it may go beyond the core standard.
Why ERP Developers Must Understand CIUS
1. Multi-country support. If your customers operate in Germany, the Netherlands, and Norway, you need to produce invoices that satisfy XRechnung, NLCIUS, and EHF respectively — all different CIUS profiles of the same EN 16931 standard.
2. Validation layering. Each CIUS adds its own Schematron rules on top of EN 16931 base validation. Your validation pipeline needs to apply the correct CIUS rules based on the target country or network.
3. BT-24 management. The Specification Identifier must be set correctly for the target CIUS. An invoice with the wrong BT-24 will fail validation at the receiving end.
4. Backward compatibility. Because CIUS only restricts, you can build a single invoice generation engine that starts with EN 16931 completeness and applies CIUS constraints as a final filter. This is far more maintainable than building separate generators per country.
5. Future-proofing. New countries joining the EU e-invoicing ecosystem will create new CIUS profiles. Understanding the CIUS framework means you can add new country support by importing their Schematron rules rather than rebuilding your invoice logic.
Relation to Invoice Navigator
Invoice Navigator validates invoices against both the EN 16931 base standard and country-specific CIUS rules. When you submit an invoice, the engine reads BT-24 to determine the applicable CIUS and runs the corresponding Schematron validation — catching violations of both the European standard and the national customization layer.