In een Peppol-document beschrijft het element cbc:CustomizationID aan welke specificaties uw document moet voldoen. De Peppol BIS‑definitie omschrijft dit als: “een identificatie van de specificatie met het totale pakket regels over semantische inhoud, kardinaliteiten en bedrijfsregels waaraan de gegevens in het document voldoen”. De combinatie van CustomizationID en ProfileID maakt voor de ontvanger én validatietools duidelijk welke set regels moet worden toegepast. Als u invoegt dat het document voldoet aan meerdere specificaties (bijvoorbeeld EN‑16931 én een lokale CIUS of extensie), behoren die allemaal in het CustomizationID te staan.
De Policy for use of Identifiers van OpenPeppol stelt onder andere:
- Een CustomizationID mag geen jokerster (*) of whitespace bevatten.
- Let goed op welk deel van de Document Type Identifier u kopieert uit de Peppol code‑lijst als u de implementatie doet.
- Het CustomizationID uit het UBL-document moet overeenkomen met het deel <CustomizationID> van de Document Type Identifier die in het SMP is geregistreerd.
- Het Document Type Identifier heeft de structuur: <xml namespace>::<root xml element>##<customization id>::<version>
- De syntax specifieke element voor XML staan vooraan vermeld in de elementen xml namespace en het root xml element. Bijvoorbeeld bij een Peppol BIS Billing 3.0 vindt u de volgende waardes: urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice
- Het version element geeft aan welke versie van UBL er wordt gebruikt. In het geval van Peppol BIS Billing 3.0 wordt UBL 2.1 gehanteerd en vindt u de waarde ::2.1 aan het einde van de Document Type Identifier.
Gebruik van een onjuist of te algemeen CustomizationID maakt het voor de ontvanger onduidelijk welke regels gelden en belemmert de rapportage van gebruikscijfers in het netwerk.
Opbouw van de CustomizationID
Een deel van de Document Type Identifier bevat het Customization ID dat gebruikt wordt in de XML. Het is belangrijk om te weten dat het Customization ID altijd als geheel geregistreerd en geïnterpreteerd wordt.
Een CustomizationID is opgebouwd uit URN‑componenten die door een “#” worden gescheiden. Iedere component verwijst naar een (deel)specificatie waaraan het document voldoet.
<basis-specificatie>#<status>#<lokale-specificatie>#<status>#<extensie>
- Basis-specificatie – urn:cen.eu:en16931:2017 geeft bijvoorbeeld aan dat het document voldoet aan de Europese Norm voor e‑factureren (EN‑16931).
- Status – #compliant of #conformant geeft de conformiteitsstatus aan. Compliant wordt gebruikt wanneer de factuur moet voldoen aan alle regels van die specificatie; Conformant wordt gebruikt wanneer een extensie conform de specificatie is maar aanvullende, optionele elementen bevat (zoals bij de g‑rekening implementatie).
- Lokale specificatie en/of Extensie – Dit deel geeft aan dat het document óók een lokale specificatie of sectorale extensie bevat. Door deze in het CustomizationID op te nemen, weet de ontvanger dat er extra velden of regels aanwezig zijn.
Nederlandse implementaties:
| Standaard | CustomizationID | Toelichting |
|---|---|---|
| NLCIUS (SI‑UBL 2.0) factuur | urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl: nlcius:v1.0 |
Geeft aan dat de factuur voldoet aan EN‑16931 én de Nederlandse implementatie NLCIUS. Gebruik deze voor standaard Nederlandse facturen zonder aanvullende extensies. |
| NLCIUS credit note | Voor creditnota’s geldt dezelfde identifier als voor facturen; het documenttype in de DocumentID (Invoice vs CreditNote) bepaalt het verschil. | |
| G‑Account‑ extensie | urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl: nlcius:v1.0#conformant#urn:fdc:nen.nl:gaccount:v1.0 |
Deze extensie voegt gegevens voor het gebruik van een ‘g‑rekening’ toe. Omdat deze extensie additionele velden bevat t.o.v. de NLCIUS, staat er #conformant bij het NLCIUS‑deel. |
| SETU‑extensie (uitzend-branche, versie 2.2) | urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl: nlcius:v1.0#compliant#urn:fdc:setu.nl:invoice:v2.2 |
Deze extensie voegt sector‑specifieke instructies toe voor de uitzendbranche. Het document is compliant met EN‑16931, NLCIUS én de SETU‑specificatie. Gebruik dit CustomizationID altijd als de factuur deze extensie bevat; anders weet de ontvanger niet dat extra instructies aanwezig zijn. Als de ontvanger geen SETU extensie kan ontvangen, dan kan de verzender deze dus ook niet sturen. |
| SeeF‑extensie (energiesector) | Geen geregistreerde CustomizationID | De SeeF‑extensie is (medio 2025) niet geregistreerd in de Peppol‑code‑lijst. Het gebruiken van het NLCIUS‑CustomizationID om een SeeF‑factuur te versturen werkt wel technisch, maar het misleidt de ontvanger en verstoort de rapportage; het is daarom niet toegestaan. |
Tip: Raadpleeg altijd de meest recente Peppol code‑lijst om het juiste CustomizationID te vinden en controleer of een extensie “Active” is. In de lijst is de SETU factuur v2.2 bijvoorbeeld als Active geregistreerd, terwijl niet‑geregistreerde extensies zoals SeeF ontbreken.
Veelgemaakte fouten en best practices
- Alleen NLCIUS gebruiken bij een extensie
Sommige implementaties sturen facturen met een sectorale extensie (zoals SETU) maar gebruiken toch het standaard NLCIUS‑CustomizationID. Dit is problematisch omdat de ontvanger niet weet dat hij extra velden mag verwachten. Gebruik altijd het CustomizationID dat alle gebruikte specificaties bevat. - ProfileID vs CustomizationID
Het ProfileID (BT‑23) beschrijft het bedrijfsproces (bijvoorbeeld factureren, bestellen) en is in UBL het element cbc:ProfileID. Het CustomizationID (BT‑24) beschrijft de technische specificatie en de regels. Verwissel ze niet. - Consistente registratie
Bij het registreren van uw documenttype in de Service Metadata Publisher (SMP) moet de Document Type Identifier exact overeenkomen met het CustomizationID in het UBL‑document. Anders kunnen ontvangers uw factuur niet accepteren en/of verwerken. - Controleer op actief/ deprecated
De Peppol code‑lijst bevat versies die Deprecated of Removed zijn. Gebruik alleen de versies met status Active. - Validatie voorbereiden
Een factuur die aangeeft compliant te zijn met meerdere specificaties moet ook daadwerkelijk aan de corresponderende Schematron‑regels voldoen. Bijvoorbeeld, een Peppol BIS 3‑factuur moet zowel voldoen aan EN‑16931‑regels als aan Peppol‑specifieke regels.
Conclusie
Het correct gebruik van CustomizationID’s is essentieel om interoperabiliteit op het Peppol‑netwerk te waarborgen. Het is meer dan een invulinstructie: de CustomizationID vertelt de ontvanger welke regels en uitbreidingen van toepassing zijn en maakt rapportage over het gebruik van standaarden mogelijk. Zorg er dus voor dat uw factuur altijd het juiste CustomizationID bevat en dat u alleen extensies gebruikt die in de Peppol‑code‑lijst zijn geregistreerd.