Peppol & e-facturatie
Peppol: boekingscode
Vraagt je klant om een kostenplaats of boekhoudkundig kenmerk op een Peppol-factuur? Laat eerst bevestigen welke waarde voor de hele factuur geldt en welke bij een afzonderlijke regel hoort. Controleer daarna de volledige plaats in dezelfde gestructureerde conceptversie. Een code ergens in het bestand vinden, bewijst die koppeling niet.
OpenPeppol onderscheidt de boekhoudkundige referentie op documentniveau, BT-19, van die bij een factuurregel, BT-133. Beide gebruiken de elementnaam cbc:AccountingCost. Onze praktische controle koppelt daarom niveau, regelnummer en afgesproken waarde. Een interne routecode van de koper heeft een andere functie.
Vraag waarvoor de koper het kenmerk gebruikt
De documentreferentie BT-19 beschrijft waar de relevante gegevens in de financiële administratie van de koper moeten worden geboekt. Vraag dus naar de bedoeling van de ontvangen code: voor welke administratie en voor welk deel van deze factuur is zij afgesproken?
Onze werkwijze is om de naam van het klantveld letterlijk te bewaren, met daarnaast een eigen uitleg van de rol. Leid uit het woord “kostenplaats” op een scherm niet zelfstandig een technische exportplek af. Laat de klant de bedoelde waarde bevestigen en de pakketleverancier aanwijzen waar die waarde in de export terugkomt.
Een project of contract blijft daarnaast een afzonderlijke verwijzing. Vergelijk de project- en contractreferentie met hun eigen bovenliggende groep. Een projectnummer wordt door een vergelijkbare schrijfwijze nog geen boekhoudkundig kenmerk.
Lees de bovenliggende factuurregel mee
Bij een UBL Invoice staat BT-19 rechtstreeks onder de factuur als cbc:AccountingCost. Voor BT-133 op regelniveau staat hetzelfde element onder cac:InvoiceLine. Neem voor die tweede plaats ook het nummer van de onderzochte factuurregel op in je controleblad.
De gecontroleerde syntax vermeldt op beide plaatsen cardinaliteit 0..1. Het documentveld is daarmee optioneel en kan daar hoogstens eenmaal voorkomen; hetzelfde geldt binnen iedere onderzochte factuurregel voor het regelveld. Een klantafspraak over een benodigde waarde is een afzonderlijke inhoudelijke controle.
Onze vergelijking vult geen ontbrekende regelwaarde automatisch vanuit het documentveld aan. Vraag bij een algemene code met uitzonderingen per regel hoe de ontvanger die combinatie wil verwerken. Deze veldbeschrijvingen zijn geen test van overerving of voorrang in jouw boekhoudpakket. Houd ook het factureringsobject bij een regel als eigen rol bij.
Maak vier gerichte controlevragen
Schrijf voor de conceptversie op: welke waarde hoort rechtstreeks bij de factuur, welke bij regel 1, welke bij regel 2 en welke routecode heeft de koper bevestigd? Voeg de herkomst en bevestigingsdatum toe. Vraag om verduidelijking wanneer twee antwoorden alleen “onze referentie” luiden.
De kopersreferentie BuyerReference, BT-10, is bedoeld voor interne routering bij de koper. Zet dat doel apart op het bronblad. Een correcte routecode geeft nog geen antwoord op de drie boekingsvragen. Omgekeerd toont een gevonden boekingskenmerk niet dat de routecode klopt.
Eigen proef BR2710: vier plaatsen vergelijken
Voor onze fictieve factuur BR2710 verzinnen we onderstaande afspraak. Alle codes zijn oefengegevens; hun geschiktheid voor een echte administratie is niet vastgesteld. We onderzoeken twee factuurregels en vier afgesproken plaatsen, zonder bedragen of echte boekingen.
| Plaats in onze proef | Afgesproken oefenwaarde |
|---|---|
| Factuur · AccountingCost | OEFEN-DOC |
| Regel 1 · AccountingCost | OEFEN-A |
| Regel 2 · AccountingCost | OEFEN-B |
| Factuur · BuyerReference | OEFEN-ROUTE |
In kandidaat A verwisselen we OEFEN-DOC en OEFEN-A. Regel 2 en de routecode blijven volgens het bronblad staan. Alle vier plaatsen zijn gevuld en alle vier codes komen voor. Toch passen slechts 2 van 4 koppelingen: de documentwaarde en de waarde bij regel 1 staan op elkaars plaats.
In kandidaat B zetten we die twee waarden terug. Dan passen 4 van 4 koppelingen. A en B bevatten allebei drie AccountingCost-elementen. Alleen op die elementnaam zoeken of het aantal gevonden codes tellen onderscheidt deze kandidaten dus niet voldoende.
Een weggelaten waarde blijft een aparte vraag
Voor kandidaat C nemen we B als uitgangspunt en laten we uitsluitend het AccountingCost-element bij regel 2 weg. Er passen dan 3 van 4 koppelingen bij ons bronblad; één afgesproken waarde ontbreekt. Het aantal opgenomen AccountingCost-elementen daalt van drie naar twee.
Wij noemen C daarom onvolledig tegenover deze verzonnen afspraak. Dat is geen oordeel dat iedere factuur zonder BT-133 ongeldig is: de genoemde syntaxplaats is optioneel. Evenmin betekent de ontbrekende regelwaarde voor onze vergelijking automatisch OEFEN-DOC. Houd “niet opgenomen” zichtbaar totdat de bedoeling is bevestigd.
Voeg niet als tijdelijke oplossing een leeg element toe. De officiële regel R008 verbiedt lege elementen. Een verzonnen code om een vakje te vullen beantwoordt de open klantvraag evenmin.
Scheid deze vergelijking van volledige validatie
De officiële regel R003 verlangt een kopersreferentie of inkooporderreferentie. De getoonde test noemt BuyerReference en de ID onder OrderReference; AccountingCost staat niet in die test. Gebruik de boekhoudkundige referentie daarom niet als vervanging voor die controle.
We hebben onze oefenwaarden op de beschreven plaatsen in gedeeltelijke XML-fragmenten teruggelezen en de vier koppelingen afzonderlijk nageteld. Dit is een beperkte controle van ons eigen voorbeeld. De fragmenten vormen geen volledige UBL-factuur; er is geen schema- of Schematron-validatie uitgevoerd en geen echte pakketexport getest.
Bewaar de conclusie bij dezelfde conceptversie
Noteer bij een verschil de versie, het niveau, het regelnummer, de aangetroffen waarde en de verwachte waarde met haar bron. Laat de invoer in de bronapplicatie corrigeren en onderzoek een nieuwe export van dat concept. Controleer ook de twee plekken die in A al goed stonden, zodat de routecode en regel 2 niet ongemerkt veranderen.
Leg naast elkaar vast wat technisch is teruggelezen en wat de klant nog moet bevestigen. Onze oefening beoordeelt geen rekeningstelsel, werkelijke kostenverdeling, fiscale verwerking, ontvangst of betaling. Er is geen factuur verzonden en geen administratie gewijzigd.
Officiële bronnen en reikwijdte
Zes primaire OpenPeppol-pagina's rechtstreeks gecontroleerd op 27 oktober 2026. De documentatie toont de May 2026 Release van BIS Billing 3.0. De uitleg betreft de genoemde UBL Invoice-plaatsen. BR2710, kandidaten A/B/C en alle OEFEN-codes zijn onze eigen fictieve uitwerking.
- OpenPeppol: actuele BIS Billing-documentatie
- Documentniveau: AccountingCost, BT-19
- Regelniveau: AccountingCost, BT-133
- Kopersreferentie voor interne routering, BT-10
- R003: kopers- of inkooporderreferentie
- R008: geen lege elementen
Bekijk het Peppol-overzicht voor andere gerichte controles vóór verzending.