Wat is Peppol BIS 3.0? Een praktische introductie voor developers

Als je factureringssoftware bouwt in Europa, kom je vroeg of laat Peppol tegen.

Voor veel developers is de eerste kennismaking verwarrend: XML overal, vreemde identificatoren, SMP- en SML-discovery, UBL-facturen, EN16931-regels, validatiefouten met cryptische meldingen.

Dit artikel legt Peppol BIS Billing 3.0 uit vanuit een praktisch technisch perspectief. Geen managementtaal. Alleen de onderdelen die developers echt moeten begrijpen.

Wat is Peppol?

Peppol is een Europees interoperabiliteitsnetwerk voor de uitwisseling van elektronische zakelijke documenten. Het meest voorkomende gebruik is elektronisch factureren.

In plaats van pdf’s per e-mail te sturen, sturen leveranciers gestructureerde factuurdocumenten rechtstreeks tussen systemen. Een Peppol-factuur is machine-leesbaar, gestandaardiseerd, gevalideerd en automatisch verwerkbaar.

Dit stelt boekhoudsystemen en ERP-platformen in staat facturen te verwerken met minimale handmatige tussenkomst.

Wat betekent BIS 3.0?

BIS staat voor Business Interoperability Specifications. Peppol BIS Billing 3.0 definieert:

• factuurstructuur
• verplichte velden
• validatieregels
• toegestane codelijsten
• transportvereisten

De syntaxis is gebaseerd op UBL 2.1 en EN16931. In de praktijk: EN16931 definieert het semantische factuurmodel, UBL definieert de XML-syntaxis, en Peppol voegt daar interoperabiliteitsregels aan toe. Meer over het EN16931-semantisch model lees je in EN16931 begrijpen.

Waarom Europa overgaat op verplicht e-factureren

Meerdere EU-landen stappen over op verplichte elektronische facturering. Voorbeelden zijn Belgie, Duitsland, Frankrijk, Polen en Italie. Overheden willen btw-fraude verminderen, geautomatiseerde belastingverwerking, interoperabele inkoop en gestandaardiseerde factuuruitwisseling.

Kennis van Peppol wordt daarmee infrastructuurkennis.

Hoe ziet een Peppol-factuur eruit?

Een Peppol-factuur is een UBL 2.1 XML-document.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">

  <cbc:CustomizationID>
    urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1
  </cbc:CustomizationID>
  <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
  <cbc:ID>INV-2025-001</cbc:ID>
  <cbc:IssueDate>2025-11-12</cbc:IssueDate>

  <cac:AccountingSupplierParty>
    <!-- verkoopgegevens -->
  </cac:AccountingSupplierParty>

  <cac:AccountingCustomerParty>
    <!-- koopgegevens -->
  </cac:AccountingCustomerParty>

  <cac:LegalMonetaryTotal>
    <!-- totalen -->
  </cac:LegalMonetaryTotal>
</Invoice>

Anders dan pdf’s zijn deze documenten bedoeld om door software te worden verwerkt. Een enkel ongeldig veld kan leiden tot afwijzing.

De rol van EN16931

EN16931 is de Europese semantische factuurstandaard. Hij definieert begrippen zoals factuurnummer, btw-bedrag, koperidentificatie, betalingsvoorwaarden en belastingspecificaties. Peppol BIS 3.0 bouwt voort op dit semantische model.

Daardoor zien developers regelmatig verwijzingen als BT-10, BT-49 en BR-CO-10. Dit zijn business terms en business rules die door EN16931 zijn gedefinieerd.

Veelvoorkomende pijnpunten voor developers

De meeste Peppol-implementaties lopen uiteindelijk tegen dezelfde problemen aan.

Naamruimteproblemen. UBL gebruikt veel XML-naamruimten. Foute declaraties leveren cryptische parserfouten op voordat er ook maar een stukje bedrijfslogica wordt uitgevoerd.

Validatiefouten. Schematron-validatiefouten zijn lastig te debuggen. De foutmeldingen verwijzen naar BR-codes die de EN16931-spec vereisen om te interpreteren.

Identificatorformaten. Deelnemer-ID’s en endpoint-ID’s zijn strikt. Een Belgisch bedrijf dat het ondernemingsnummerschema 0208 gebruikt, moet precies dat schemacode als prefix gebruiken.

XML-handtekeningen. Canonicalisatieproblemen breken handtekeningvalidatie regelmatig. Dit is een bijzonder vervelende categorie bugs: de XML ziet er correct uit, de handtekening is geldig, maar ze verifiëren niet tegen elkaar. Zie Valkuilen bij XML-handtekeningvalidatie in Peppol voor details.

Landspecifieke profielen. Duitsland, Belgie en Frankrijk stellen aanvullende eisen bovenop de basis Peppol BIS 3.0-specificatie. Een document dat geldig is voor het ene land kan ongeldig zijn voor een ander.

SMP- en SML-discovery

Peppol gebruikt een discoverymechanisme vergelijkbaar met DNS. De stroom werkt globaal als volgt:

1. Hash de deelnemersidentificator
2. Construeer een DNS-hostnaam uit de hash
3. Bevraag de SML (Service Metadata Locator) om de SMP van de deelnemer te vinden
4. Bevraag de SMP (Service Metadata Publisher) om servicemetadata op te halen
5. Bepaal ondersteunde documenttypen en endpoint-URL’s
6. Lever het document via een Access Point af

De SMP-reactie zelf is een ondertekend XML-document. Die handtekening is de oorzaak van de hierboven genoemde canonicalisatieproblemen.

Waarom pdf-facturen niet volstaan

Traditionele pdf-facturen zijn leesbaar voor mensen. Peppol-facturen zijn machine-leesbaar. Veel moderne systemen combineren beide: PDF/A-3 voor visuele weergave, ingebedde XML voor automatisering.

Dit is de basis van Factur-X en ZUGFeRD. Zie Factur-X vs ZUGFeRD vs XRechnung vs Peppol voor een vergelijking van hoe deze formaten zich tot elkaar verhouden.

Het moeilijke deel

Geldige UBL-XML genereren is niet het moeilijke deel. Het moeilijke deel is XML genereren die de werkelijke interoperabiliteitstest doorstaat:

• Schematron-validatie over meerdere nationale regelsets
• SMP-discovery met dynamische naamruimteprefixes
• XML-handtekeningverificatie op opnieuw geserialiseerde documenten
• Landspecifieke verplichte velden die niet in de basisspecificatie staan
• Afrondingsregels die verschillende resultaten opleveren afhankelijk van of je per regel of per document afrondt

In komende artikelen behandelen we: EN16931 in detail, UBL vs CII, SMP-discovery internals, valkuilen bij XML-handtekeningen en veelvoorkomende Peppol-validatiefouten.

De werkelijke kosten van het moeilijke deel zitten niet in het lezen van de specificatie. Ze zitten in de operationele overhead: Schematron-regelsets up-to-date houden bij elke Peppol BIS-release, SMP-discoverystoringen netjes afhandelen, landspecifieke regelvariaties bijhouden voor Duitsland, Belgie, Frankrijk en Polen.

SealDoc is een API die deze laag voor zijn rekening neemt. Je stuurt je factuurgegevens als JSON-payload. De API genereert het UBL-document, voert EN16931- en Peppol BIS 3.0 Schematron-validatie uit, voert SMP-discovery uit, verpakt het document in een AS4-envelope en levert het af bij het Access Point van de ontvanger. Als de ontvanger niet bereikbaar is of het document de validatie niet doorstaat, ontvang je een gestructureerde foutmelding die exact aangeeft welke stap mislukte en waarom.

Voor testen en debuggen accepteert de SealDoc publieke validator UBL- en CII-factuurbestanden en geeft een rapport in gewone taal van elke geschonden EN16931- en Peppol BIS 3.0-regel, met het BT-nummer en de business rule-code. Geen account vereist.