Peppol & e-facturatie
Peppol: naam en omschrijving
Een lange tekst op je factuurregel bewijst niet dat de artikelnaam in de Peppol-export staat. Controleer de naam en de uitgebreidere omschrijving op hun eigen plaats, bij dezelfde regel. Zelfs een gevonden veld Name kan over een artikelkenmerk gaan in plaats van over het artikel zelf.
Kort antwoord
Vergelijk drie dingen afzonderlijk: de naam van het artikel, de details die je over dat artikel wilt doorgeven en een eventuele extra regelnotitie. Leg eerst de afgesproken tekst vast en lees daarna de juiste velden in dezelfde conceptversie terug. Alleen tellen hoeveel teksten aanwezig zijn, mist een ontbrekende naam of een verkeerde ruimte in de omschrijving.
Deze uitleg gebruikt de UBL Invoice van Peppol BIS Billing 3.0.21, May 2026 Release. AN2610 is ons fictieve oefendossier met drie onvolledige XML-fragmenten. We hebben geen boekhoudpakket, pdf-weergave, ontvangend systeem of volledige validator getest.
Geef naam, omschrijving en regelnotitie ieder een rol
De officiële pagina Artikelnaam, BT-153 beschrijft Name direct binnen Item. De cardinaliteit 1..1 betekent dat deze naam één keer bij het artikel hoort. Een pakketlabel als Omschrijving vertelt op zichzelf nog niet welk exportveld wordt gevuld.
Artikelomschrijving, BT-154 biedt ruimte voor meer detail over het artikel en zijn kenmerken. De syntax noemt 0..1: het veld kan ontbreken of één keer voorkomen. Dat technische verschil zegt nog niet of de voor jouw opdracht benodigde uitleg daadwerkelijk is opgenomen.
De regelnotitie, BT-127 staat rechtstreeks onder InvoiceLine en bevat ongestructureerde informatie bij die regel. Zij staat dus naast de artikelgroep, niet binnen Item. Gebruik de afzonderlijke controle van factuur- en regelnotities om de bovenliggende groep mee te lezen.
Zoek de naam rechtstreeks bij het artikel
Het overzicht van de artikelgroep zet Description, Name en AdditionalItemProperty op afzonderlijke plaatsen. Bij een eigenschap staat opnieuw een Name, de kenmerknaam BT-160, maar dat is de naam van die eigenschap. Dezelfde elementnaam kan dus twee verschillende rollen hebben.
Onze proef bevat bij het artikel het kenmerk Werkplek met waarde Berging C. Wie ergens onder Item naar Name zoekt, kan Werkplek vinden terwijl de directe artikelnaam ontbreekt. Noteer daarom het hele pad: InvoiceLine / Item / Name voor de artikelnaam, tegenover InvoiceLine / Item / AdditionalItemProperty / Name voor de kenmerknaam.
Gebruik voor die aparte paren de uitleg over de naam en waarde van een artikelkenmerk. Een bruikbare kenmerknaam vult de afzonderlijke artikelnaam niet in. Bewaar op je eigen controleblad het regelnummer en de bronversie bij beide plaatsen.
Eigen proef: één regel, drie tekstplaatsen
We verzinnen regel 10 van AN2610. Ons oefenblad noemt als artikelnaam Slotonderhoud, als detail “Twee cilinders nagekeken in berging C.” en als regelnotitie “Toegang via beheerder.” Het extra kenmerk Werkplek/Berging C blijft in alle fragmenten gelijk. Dit zijn oefenafspraken, geen echte werkzaamheden of klantinstructies.
| Fragment | Onze tekstvergelijking |
|---|---|
| A · naam ontbreekt | Detail noemt berging D. Alleen de regelnotitie past: 1 van 3 plaatsen. |
| B · naam toegevoegd | Slotonderhoud staat bij Item. Detail noemt nog D: 2 van 3 plaatsen passen. |
| C · detail hersteld | Detail noemt C. De naam, het detail en de notitie passen: 3 van 3 plaatsen. |
Een namespacebewuste parser heeft de drie eigen fragmenten uitgelezen. In A vinden we één Name ergens onder het artikel: Werkplek. Toch zijn er nul directe artikelnamen. In B en C zijn er twee Name-elementen onder het artikel, waarvan één rechtstreeks bij Item. Een brede zoekactie en de bedoelde veldcontrole beantwoorden dus verschillende vragen.
De overeenstemming met ons oefenblad stijgt van 1 naar 2 naar 3 tekstplaatsen. Een tweede controle vergelijkt de drie plaatsen apart met de vooraf vastgelegde ja/nee-rijen: A heeft nee/nee/ja, B ja/nee/ja en C ja/ja/ja. Deze aantallen beschrijven alleen onze fragmenten; ze meten geen foutpercentage van Peppol.
Een aanwezige naam bewijst de omschrijving niet
BR-25 verlangt een artikelnaam per factuurregel. De getoonde test kijkt naar niet-lege genormaliseerde tekst op de directe plaats Item/Name. De veldpagina classificeert de regel als fatal. In A is precies die directe naam afwezig; de kenmerknaam Werkplek en de aanwezige Description vullen haar niet aan.
In B is Slotonderhoud wel op de bedoelde plaats aanwezig. Daarmee is het andere verschil nog niet opgelost: onze verwachte omschrijving noemt C, maar B noemt D. De BR-25-voorwaarde vergelijkt die ruimte niet met ons oefenblad. De eigen tekstvergelijking blijft dus nodig naast een technisch rapport.
Wij hebben de regelpagina gelezen en de eigen velden gecontroleerd, maar geen volledige XSD- of Schematron-validatie uitgevoerd. C bevat nog steeds slechts een onvolledig fragment. De drie passende teksten maken het geen complete of verzendbare factuur.
Leg een schermtekst naast de export van dezelfde versie
Vraag bij een demonstratie om de artikelnaam, het detail en de regelnotitie ieder aan te wijzen in de gestructureerde inhoud. Laat ook zien welke bronvelden de drie waarden bepalen. Een samengevoegd tekstvak op een pdf maakt die afzonderlijke plaatsen niet zichtbaar.
Gebruik de eigen tekst met berging C als vergelijkingspunt en noteer letterlijk waar de export D vermeldt. Bewaar het bronconcept, de export en de eventuele leesbare weergave van dezelfde versie samen. Wij hebben geen viewer gebruikt en doen geen uitspraak over het afbreken, samenvoegen, inkorten of vertalen door een bepaald pakket.
Controleer bij een echte opdracht welke details zijn afgesproken. Een optioneel veld in de syntax is geen reden om zelf een onbekende prestatie of locatie te verzinnen. Noteer ontbrekende onderbouwing als open vraag en laat de verantwoordelijke bron bevestigen.
Herstel gericht en lees de andere tekstplaatsen terug
Voor A luidt onze eigen vraag: “Bij regel 10 ontbreekt Item/Name; de gevonden Name hoort bij Werkplek. Welk bronveld levert de artikelnaam?” Na het toevoegen van Slotonderhoud ontstaat B. Lees het directe veld opnieuw terug en controleer daarnaast het detail en de notitie die niet door die handeling zijn verklaard.
Voor B blijft één verschil over: D tegenover C in Description. C wijzigt alleen die letter in het detail. Vergelijk vervolgens alle drie de tekstplaatsen en het gelijk gebleven kenmerk. Bewaar welke correctie bij welke versie hoort en vraag afzonderlijk om het volledige validatierapport voor het uiteindelijke document.
Onze slotnotitie is beperkt: drie afgesproken tekstplaatsen in drie eigen fragmenten onderzocht, met één gerichte naamcorrectie en één detailcorrectie. Dat bewijst geen uitgevoerde levering, ontvangeracceptatie of betaling. Bij een al verzonden factuur moet eerst duidelijk zijn welke versie de klant heeft ontvangen en welke herstelroute is afgesproken.
Officiële bronnen en proefgrenzen
Acht officiële OpenPeppol HTML-pagina's rechtstreeks gecontroleerd op 26 oktober 2026. De release-informatie noemt 3.0.21, gepubliceerd op 20 mei 2026 en verplicht vanaf 17 augustus 2026. AN2610, de werkzaamheden, teksten en drie fragmenten zijn onze eigen fictieve uitwerking. De proef gaat alleen over UBL Invoice, niet over een uitgewerkt Credit Note-, CII- of Self-Billing-document.
- OpenPeppol: BIS Billing 3.0, May 2026 Release
- OpenPeppol: artikelgroep, BG-31
- OpenPeppol: artikelnaam, BT-153
- OpenPeppol: artikelomschrijving, BT-154
- OpenPeppol: regelnotitie, BT-127
- OpenPeppol: BR-25, aanwezige artikelnaam
- OpenPeppol: release 3.0.21
- OpenPeppol: kenmerknaam, BT-160
Bekijk het Peppol-overzicht voor andere gerichte factuurcontroles.