Peppol & e-facturatie

Peppol: code en listID

Gepubliceerd: 2026-10-24 · Bronnen gecontroleerd: 2026-10-24

Een artikelnummer is geen classificatiecode. Controleer bij een Peppol-factuur niet alleen welke code je ziet, maar ook welk classificatiestelsel erbij staat. Dezelfde tekst in een ander veld geeft de ontvanger andere informatie.

Kort antwoord

Leg per onderzochte factuurregel de classificatiecode, het stelsel en een eventuele stelselversie naast de export. In UBL heet het stelselkenmerk hier listID. Een attribuut met de naam schemeID neemt die plaats niet over.

Deze uitleg betreft UBL Invoice binnen Peppol BIS Billing 3.0.21, May 2026 Release. Ons oefenscenario heeft een Nederlandse verkoper en koper. De vergelijking hieronder classificeert geen echt product.

Zoek de classificatie bij het artikel

De officiële groep CommodityClassification staat binnen het artikel van een factuurregel. Zij is 0..n: je kunt geen, één of meerdere classificaties opnemen. Binnen iedere opgenomen groep staat één ItemClassificationCode, BT-158. De 1..1 van dat kind maakt de hele groep niet voor iedere regel verplicht.

Een classificatie beschrijft een type of aard. De verkopers- en kopersnummers hebben hun eigen plaats. Gebruik daarvoor onze controle van artikelcodes en regelverwijzingen. Vraag bij een veld dat alleen Artikelcode heet welke betekenis en exportplaats het pakket ermee bedoelt.

Lees de code met het stelsel

De syntax voor listID noemt het attribuut verplicht. De waarde komt uit de gekoppelde UNCL7143-lijst. Daar staat STI voor CPV en TST voor UNSPSC. Die twee korte aanduidingen zijn stelselkenmerken; zij zijn niet zelf de inhoudelijke classificatie van jouw artikel.

De BIS onderscheidt deze plaats ook van een standaardartikelidentificatie met schemeID. Kopieer dus niet de attribuutnaam uit een ander ID-veld. Bewaar code en stelsel samen op je werkblad, zodat een losse cijferreeks later niet zonder context wordt hergebruikt.

Vraag bij de bron van een echte classificatie ook welke productomschrijving is beoordeeld en uit welke lijst de code is gekozen. Een bekend stelselkenmerk bewijst nog niet dat de opgegeven code bestaat of inhoudelijk bij de levering past.

Houd een stelselversie apart

listVersionID geeft de versie van het classificatiestelsel aan en is in de algemene syntax optioneel. Het is iets anders dan de BIS-release of de versie van jouw factuurconcept.

Bekijk ook de toepasselijke landregels. In de huidige DK-R-003 staat de context voor een Deense leverancier én Deense klant; bij TST worden daar specifieke UNSPSC-versies getoetst. Pas zo'n voorwaarde niet automatisch op ons Nederlandse oefenscenario toe. Omgekeerd betekent optioneel in de algemene syntax niet dat je iedere land- of klantafspraak kunt overslaan.

Eigen proef: één verkeerde attribuutnaam

We verzinnen dossier AC2410 met één classificatiegroep. Op ons oefenblad staat code OEFEN-A, stelselkenmerk TST en versie OEFEN-V1. OEFEN-A en OEFEN-V1 zijn bewust geen echte classificatie en geen officiële lijstuitgave. Ze dienen uitsluitend om de plaats van drie waarden te vergelijken.

Gegeven	Aangetroffen in C1
Code	OEFEN-A staat als inhoud van ItemClassificationCode.
Stelsel	TST staat bij schemeID; listID ontbreekt.
Versie	OEFEN-V1 staat bij listVersionID.

We hebben twee eigen, onvolledige XML-fragmenten met een namespacebewuste parser uitgelezen. In C1 kloppen twee van de drie onderzochte plaatsen met het oefenblad: de code en versie. Voor het stelsel ontbreekt de verwachte attribuutnaam. De tekst TST is aanwezig, maar op de verkeerde plaats.

In C2 veranderen we alleen schemeID="TST" in listID="TST". Nu komen de drie onderzochte waarden overeen. De groepentelling blijft één. Dit is een uitgevoerde vergelijking van onze eigen fragmenten, geen bewijs dat de fictieve code of versie voor een echte factuur geschikt is.

Lees wat de regel werkelijk controleert

BR-65 vraagt het stelselkenmerk; de getoonde test kijkt naar de aanwezigheid van @listID. BR-CL-13 toetst een aanwezig listID aan de toegestane stelselcodes. De syntax vermeldt beide als fatal.

Het lezen van deze regelteksten is geen uitvoering van de volledige validator. Onze parsercontrole beoordeelt evenmin een bestaande CPV- of UNSPSC-code, een productkeuze, bedragen of ontvangst. Gebruik de algemene controle van formaat en validatielagen voor de overige documentcontrole.

Herstel de bron en bewaar de versie

Maak een gerichte vraag voor de pakketleverancier: bij welk bronveld en welke exportkoppeling wordt het stelsel van deze classificatie vastgelegd? Voeg regelnummer, conceptversie, verwachte plaats en aangetroffen plaats toe. Alleen melden dat de artikelcode fout is laat verschillende vragen door elkaar lopen.

Laat na herstel een nieuwe export maken en vergelijk code, listID en eventuele versie opnieuw. Houd bij meerdere classificaties ieder groepje bij elkaar. Vraag afzonderlijk om het volledige validatierapport voor die export en de inhoudelijke onderbouwing van de echte classificatie. Bewaar de conclusie precies: drie waarden teruggelezen is geen klantgoedkeuring, juiste productindeling of verzending.

Officiële bronnen

Negen officiële OpenPeppol HTML-pagina's rechtstreeks gelezen op 24 oktober 2026. De documentatie toont May 2026 Release en BIS 3.0.21. AC2410, de oefenwaarden en fragmenten zijn onze eigen uitwerking. Geen echte factuur, productclassificatie, pakketmapping, volledige XSD- of Schematron-validatie of verzending getest.

Bekijk het Peppol-overzicht voor andere gegevenscontroles.