Peppol & e-facturatie

Peppol: project en contract

Een projectnummer en een contractnummer kunnen allebei op een Peppol-factuur staan, maar verwijzen naar verschillende dingen. Leg eerst vast welk project je factureert en welk contract daarbij hoort. Controleer daarna de betekenis, waarde en plaats in de export van dezelfde conceptversie. Alleen twee ingevulde vakjes op een scherm zien is onvoldoende.

Kort antwoord

In een UBL Invoice zijn projectreferentie en contractreferentie afzonderlijke, optionele gegevens. Een klantafspraak kan ze voor de verwerking wel nodig maken. Onze proef vergelijkt twee facturen bij één contract en laat zien hoe twee verwisselde waarden na een halve correctie nog één open vraag overlaten.

Geef project en contract hun eigen rol

OpenPeppol noemt de projectreferentie BT-11: het project waarop de factuur betrekking heeft. In de Invoice-syntax staat de waarde onder cac:ProjectReference/cbc:ID. De contractreferentie BT-12 identificeert een contract, met als plaats cac:ContractDocumentReference/cbc:ID.

Onze werkmethode: schrijf bij ieder ontvangen nummer eerst de betekenis en de bronafspraak op. Vraag niet alleen “welke referentie moet erop?”, maar ook welk project of contract de ontvanger ermee wil terugvinden. Een code met het woord project in de bestandsnaam bewijst nog niet dat de waarde bij de juiste rol hoort.

Houd de inkooporder en interne routecode daarnaast apart. De controle van de afgesproken kopers- en orderreferentie helpt bij die gegevens. Zet een onbekend projectnummer niet alvast in het orderveld omdat dat het enige zichtbare referentievakje is.

Lees de groep en het ID samen

De huidige Invoice-syntax geeft beide groepen de cardinaliteit 0..1. Iedere opgenomen groep bevat één cbc:ID met cardinaliteit 1..1. Dat kindelement maakt de optionele groep niet verplicht op elke factuur. Lees daarom de volledige plek van het ID, inclusief de bovenliggende groep.

Een klant die meerdere projecten in de administratie beheert, maakt daarmee nog geen lijstveld van één projectreferentie. Vraag bij een gecombineerde opdracht hoe de factuur moet worden ingericht. Voeg niet zelf een extra projectgroep of een met komma's samengestelde code toe om een onduidelijke opdracht passend te laten lijken. Deze eigen controle bepaalt niet hoe een concrete verzamelfactuur moet worden opgesteld.

Maak een klein bronblad vóór de export

Noteer per onderzochte factuur de klant, het project, het contract, de bevestigde waarden, de datum van de afspraak en de conceptversie. Voeg bij elke waarde toe uit welk stuk of antwoord zij komt. Houd een eigen interne projectcode apart wanneer je nog niet weet of de klant diezelfde code gebruikt.

Vraag de leverancier van je factuurpakket vervolgens welke invoervelden deze twee exportplaatsen vullen. Een schermlabel als “Referentie” is geen technische veldbeschrijving. Laat een concept en de bijbehorende gestructureerde inhoud aanwijzen; stuur hiervoor geen proefrekening naar een echte klant. Wij hebben voor dit artikel geen pakketaccount ingericht of export gemaakt.

Eigen proef PC2010: één contract, twee projecten

We verzinnen dossier PC2010. Voor onze oefening bevestigt de fictieve klant contract C-420 met twee aparte projecten P-A20 en P-B20. De verkoper bereidt facturen F-A en F-B voor. De onderstaande tabel is ons eigen afgesproken bronblad, geen echte opdracht of beoordeeld contract.

FactuurProjectContract
F-AP-A20C-420
F-BP-B20C-420

Hetzelfde contract komt in deze verzonnen situatie op twee afzonderlijke facturen terug. We vergelijken per factuur één projectwaarde met één contractwaarde. Dat is iets anders dan beide projectcodes in één project-ID zetten. Er is geen echte afspraak over samenvoegen, factureren of betalen vastgesteld.

Vergelijk de inhoud, niet alleen het label ID

In ons bedachte concept C1 van F-A staat C-420 bij de projectreferentie en P-A20 bij de contractreferentie. Beide waarden zijn ingevuld, maar ze zijn tegenover het bronblad verwisseld. We noteren twee inhoudelijke verschillen: het projectveld verwijst naar het contract en het contractveld naar het project.

Vraag in een inhoudsweergave dus naar het bovenliggende onderdeel. De tekst cbc:ID alleen is hier onvoldoende om te bepalen welke rol je bekijkt. De afzonderlijke controle van factuurregel, orderregel en artikelcode laat zien waarom hetzelfde elementlabel op andere plaatsen iets anders kan betekenen.

Schrijf bij de eigen notitie ook F-A, C1 en de versie van het bronblad. Een schermafbeelding van een ander concept kan de verwisseling niet verklaren. Zoek niet alleen naar de aanwezigheid van de tekens P-A20: kijk ook onder welk onderdeel die tekens in dezelfde export staan.

Controleer ook na de eerste correctie verder

In onze fictieve C2 wordt alleen het projectveld van F-A verbeterd naar P-A20. De contractreferentie blijft ten onrechte P-A20. Er resteert 2 − 1 = 1 open verschil. Twee gelijke waarden maken deze proef dus niet sluitend: volgens ons bronblad hoort bij het contract C-420.

Voor C3 laten we in de oefening ook het contractveld naar C-420 veranderen. Dan resteert 1 − 1 = 0 van de twee genoteerde verschillen. Dit is een telling op ons bronblad, geen uitgevoerd XML-validatieresultaat. Controleer bij de volgende factuur F-B opnieuw het eigen project P-B20; neem de gecorrigeerde projectwaarde van F-A niet automatisch over.

Herstel de invoer in de bronapplicatie en vergelijk een nieuwe export met dezelfde bevestigde gegevens. Alleen de leesbare pdf aanpassen toont niet dat de gestructureerde waarde is meegewijzigd. Bewaar oorspronkelijke en latere concepten apart, zodat zichtbaar blijft wat op welk moment is bekeken.

Houd aanwezigheid en klantafspraak uit elkaar

De regel PEPPOL-EN16931-R003 verlangt een kopersreferentie of inkooporderreferentie. De getoonde test noemt die twee plekken; project- of contractreferentie vervangt die controle niet. De regel R008 verbiedt lege elementen. Neem bij ontbrekende optionele gegevens dus niet zomaar een lege groep met een leeg ID op.

Een aanwezigheidstoets vergelijkt bovendien niet vanzelf onze fictieve bronafspraak. In C1 waren de twee onderzochte waarden al ingevuld. Wij hebben geen validator gedraaid en claimen geen positieve of negatieve volledige validatie-uitkomst. Laat de uiteindelijke factuur met de toepasselijke specificatie beoordelen en koppel het rapport aan de werkelijk onderzochte versie.

Bewaar een conclusie die bij de controle past

Onze slotnotitie noemt welke twee velden en bronafspraken zijn vergeleken, welke concepten zijn bekeken en welke vragen openstaan. Schrijf niet dat een heel contract is goedgekeurd wanneer je alleen een contractnummer hebt teruggevonden. Deze referentiecontrole beoordeelt geen contractgeldigheid, echte prestatie, aanvaarding of betaling.

De uitleg hierboven betreft een UBL Invoice binnen de gecontroleerde BIS Billing-documentatie. De BIS beschrijft voor de projectreferentie in een CreditNote een andere plaats; neem de Invoice-koppeling daarvoor niet automatisch over. Bewaar bij een al verzonden document eerst de verzonden versie en de klantreactie en stem een eventuele herstelroute af.

Bronnen en verder lezen

Acht primaire OpenPeppol-pagina's rechtstreeks gecontroleerd op 20 oktober 2026. De documentatie toont de May 2026 Release van BIS Billing 3.0. PC2010, C-420, P-A20/P-B20, F-A/F-B en C1/C2/C3 zijn onze eigen fictieve uitwerking. Geen klant benaderd, contract beoordeeld, pakketmapping getest, factuur verzonden of volledig XML-document gevalideerd.

Ga naar het Peppol-overzicht voor andere controles vóór verzending.