Peppol & e-facturatie
Peppol: contact en afleveradres
Staat het e-mailadres van je contactpersoon in de Peppol-factuur? Controleer ook bij welke partij het staat en wat het veld betekent. Een contact voor vragen over de factuur en het elektronische adres voor aflevering zijn afzonderlijke gegevens. De aanwezigheid van een e-mailadres bewijst niet dat de juiste ontvanger is ingesteld.
Kort antwoord
Leg verkoper en koper vast, zoek de contactgroep van iedere partij en vergelijk naam, telefoon en e-mail met je bevestigde dossier. Controleer het elektronische afleveradres apart. Herstel een verkeerd bronveld en lees daarna een nieuwe export. Onze werkwijze hieronder is een eigen inhoudscontrole; zij verzendt geen factuur en vervangt geen volledige validatie.
Begin bij de juiste partij
In de actuele BIS Billing-documentatie staat versie 3.0.21; de syntaxpagina’s tonen May 2026 Release. We behandelen een gewone UBL Invoice. Lees bij de koper onder AccountingCustomerParty en bij de verkoper onder AccountingSupplierParty. De verdere plaats is telkens Party en daarna Contact.
De koperscontactgroep BG-9 bevat contactgegevens die voor de koper relevant zijn. De verkoperscontactgroep BG-6 betreft de verkoper. Zet de partijrol boven je vergelijking; een los zoekresultaat voor Contact laat die rol niet zien.
Vraag in je eigen dossier wie vragen behandelt en welke contactgegevens daarvoor zijn bevestigd. Houd dat naast de formele naam en registratie van de koper. Een leesbare contactnaam bevestigt niet wie de contractspartij is, of dat iemand bevoegd is om alle factuurgegevens te wijzigen.
Lees naam, telefoon en e-mail afzonderlijk
Bij de koper is Name, BT-56 het contactpunt. Telephone, BT-57 is het telefoonnummer en ElectronicMail, BT-58 het e-mailadres van dat contactpunt. Neem die drie waarden op aparte regels over; verwissel een telefoonveld niet met een intern klantnummer.
De algemene syntax noemt voor de contactgroep en elk van deze drie kindvelden cardinaliteit 0..1. Dat betekent hier nul of één voorkomen, geen verplichting om overal zelf ontbrekende gegevens te verzinnen. Het is evenmin een volledige lijst van toepasselijke aanvullende regels. Controleer de gekozen situatie en gebruik alleen gegevens waarvan betekenis en herkomst duidelijk zijn.
De volledige kopersnaam BT-44 staat op een andere plaats: RegistrationName onder PartyLegalEntity. Kopieer een contactnaam dus niet automatisch naar de formele naam. Noteer bij een onduidelijk schermlabel welk gegeven het pakket werkelijk uitvoert.
Een contactadres is geen afleveradres
EndpointID, BT-49 identificeert het elektronische adres van de koper waarnaar de factuur wordt afgeleverd. De getoonde syntax verlangt één voorkomen en een identificatieschema via schemeID. Dat is een ander veld dan ElectronicMail in de contactgroep.
R010 controleert in de koperspartij op EndpointID. Een ingevulde contactmail vervangt dat element niet. Andersom bewijst een aanwezige EndpointID niet dat een telefoonnummer of contactmail in je dossier juist is. De controles beantwoorden verschillende vragen.
Houd op je eigen blad daarom een apart onderdeel voor de adrescontrole inclusief identificatieschema. Als de klant andere contactgegevens doorgeeft, vraag dan expliciet of ook de factuurroute verandert. Verander het netwerkadres niet alleen omdat een contactpersoon een nieuw e-mailadres heeft.
Eigen proef: twee mails op de verkeerde plaats
We verzinnen dossier CT2410. De verkoper heeft contactnaam Facturatie S24, telefoonlabel TEL-S24 en mail vragen@verkoper.example. Bij de koper horen Administratie K24, TEL-K24 en inkoop@koper.example. De telefoonlabels zijn geen geldige nummers. Ook de namen en adressen zijn oefengegevens; gebruik ze niet in een echte factuur.
| Onderdeel | Ons fragment C1 |
|---|---|
| Verkoper | Bedoeld: vragen@verkoper.example Gevonden: inkoop@koper.example |
| Koper | Bedoeld: inkoop@koper.example Gevonden: vragen@verkoper.example |
| Overige velden | Beide contactnamen en beide telefoonlabels sluiten aan bij ons fictieve dossier. |
Met een namespacebewuste parser hebben we de zes gekozen waarden uit twee beperkte XML-fragmenten gelezen: drie per partij. C1 bevat twee niet-lege e-mailvelden, en beide verwachte mailteksten komen erin voor. Toch sluiten slechts 4 van de 6 waarden aan bij de bedoelde partij. De twee mailadressen zijn omgewisseld. Zoeken of de tekst ergens bestaat, ontdekt die verkeerde plaats niet.
In C2 wijzigen we alleen de twee mailwaarden. Nu sluiten 6 van de 6 waarden aan bij het fictieve dossier. De contactnamen en telefoonlabels blijven gelijk. Dit is uitsluitend onze beperkte plaats-en-waardevergelijking. Het zijn geen volledige facturen; echte telefoonnummers, mailboxen, bedrijven of netwerkadressen zijn niet gecontroleerd.
Houd een vergelijking en validatie uit elkaar
“Zes waarden sluiten aan” betekent niet dat een factuur technisch of inhoudelijk is goedgekeurd. Onze fragmenten missen andere factuuronderdelen; we hebben geen volledige XSD- of Schematron-validatie uitgevoerd. R010 is in deze proef niet als validator uitgevoerd, en de aanwezigheid van mail zegt niets over het slagen voor die regel.
Lees de toepasselijke aanvullingen naast de algemene syntax. De pagina van de verkoperscontactgroep toont bijvoorbeeld DE-R-002: als verkoper en koper beide in Duitsland gevestigd zijn, moet BG-6 worden opgenomen. Trek uit de algemene 0..1 dus geen universele conclusie voor iedere landcombinatie. Dit voorbeeld stelt geen Duitse of Nederlandse factuurinhoud voor jouw bedrijf vast.
Herstel het brongegeven en vergelijk opnieuw
Bewaar de oorspronkelijke export en noteer per afwijking partij, veld, gevonden waarde en bedoelde waarde. Vraag bij een pakket met één algemeen contactscherm welk bronveld de verkopers- of kopersgroep voedt. Laat de verantwoordelijke de wijziging bevestigen voordat je een nieuw concept maakt.
Lees daarna beide partijgroepen opnieuw. Alleen het e-mailadres op een pdf veranderen bevestigt niet dat de volgende gestructureerde export ook is aangepast. Bewaar versies en uitkomst samen en noteer afzonderlijk welke volledige validatie en adrescontrole nog nodig zijn. Verzend niet nogmaals een al verstuurd document om een onduidelijke contactvraag te onderzoeken; stem eerst de herstelroute af.
Bronnen en verder lezen
Negen officiële OpenPeppol-HTML-pagina’s rechtstreeks gelezen op 24 oktober 2026. Geselecteerd: BIS Billing 3.0, May 2026 Release, versie 3.0.21, gewone UBL Invoice. CT2410, de zes oefenwaarden, C1/C2 en de vergelijking zijn onze eigen fictieve uitwerking. Geen echte contactgegevens, netwerkroute, klantinstelling of volledige factuur gevalideerd en niets verzonden.
- BIS Billing: profiel en versie
- Koper: contactgroep BG-9
- Verkoper: contactgroep BG-6 en aanvullende regel
- Koper: contactnaam BT-56
- Koper: telefoon BT-57
- Koper: contactmail BT-58
- Koper: afleveradres BT-49 en schemeID
- R010: elektronisch adres van de koper
- Koper: formele naam BT-44
Bekijk het Peppol-overzicht voor andere inhoudscontroles vóór verzending. Bewaar contactgegevens, partijidentiteit en elektronische aflevering als herkenbare onderdelen van hetzelfde dossier.