Peppol-handleiding voor ontwikkelaars: BIS Billing, SMP-lookup, AS4 en responses

Peppol is een vierhoekennetwerk (four-corner model): de software van de verzender (hoek 1) geeft een document aan zijn access point (hoek 2), dat het access point van de ontvanger (hoek 3) vindt via een DNS- en SMP-lookup en het via AS4 aflevert; hoek 3 geeft het door aan de software van de ontvanger (hoek 4). Voor een ontwikkelaar betekent dit drie afzonderlijke problemen — een Peppol BIS Billing 3.0-document produceren, het adresseren met de juiste participant-identifier, en een geaccrediteerde access point-aanbieder vinden die het vervoert. KRONENWERK lost de eerste twee zelf op en delegeert het derde aan Storecove, een geaccrediteerde access point-aanbieder.

BIS Billing 3.0 is EN 16931 met de beperkingen van Peppol

Peppol BIS Billing 3.0 is een Core Invoice Usage Specification (CIUS) van EN 16931: elk document dat aan de BIS voldoet, voldoet ook aan de Europese norm, en de BIS voegt eisen toe die het netwerk nodig heeft om een factuur te routeren en te verwerken. De actuele publicatie op het moment van lezen is versie 3.0.21 (release van mei 2026). Ze bindt het semantische model aan UBL 2.1 Invoice en CreditNote; CII wordt op Peppol niet gebruikt voor facturatie.

De identifiers die van een UBL-bestand een Peppol BIS-factuur maken, zijn vaste strings:

Bovenop de kernregels vereist de BIS de elektronische adressen van verkoper en koper (cbc:EndpointID met een schemeID), een koperreferentie of inkooporderreferentie, betaalmiddelen met een code, en een handvol opmaakbeperkingen. Die worden afgedwongen door de Peppol-Schematron (PEPPOL-EN16931-UBL.sch) als regels met de naam PEPPOL-EN16931-Rxxx, bovenop de CEN-regels (CEN-EN16931-UBL.sch). De kernregels zelf worden uitgelegd in de EN 16931-handleiding voor ontwikkelaars.

Participant-identifiers

Een Peppol-deelnemer wordt geadresseerd met een schema en een waarde, geschreven als schema:waarde — bijvoorbeeld 0208:0123456789 voor een Belgisch ondernemingsnummer of 0204: gevolgd door een Leitweg-ID voor een Duitse koper uit de publieke sector. De schemacodes komen uit de ISO 6523-lijst van International Code Designators zoals bijgehouden in de Policy for use of Identifiers van OpenPeppol (versie 4.4.0, geldig vanaf 1 november 2025 op het moment van lezen). Dezelfde identifier komt op drie plaatsen voor, en die moeten overeenstemmen:

1. In het UBL-document, als cac:AccountingCustomerParty/cac:Party/cbc:EndpointID schemeID="0208" (BT-49) en het equivalent voor de verkoper (BT-34).
2. In de envelop (SBDH) als verzender- en ontvangeridentifier, met het identificatieschema iso6523-actorid-upis.
3. In de SMP-vermelding van de ontvanger, waar de lookup plaatsvindt.

Welk schema een bepaalde onderneming gebruikt, hangt af van haar land en van wat ze heeft geregistreerd. België registreert onder 0208 (ondernemingsnummer), de Duitse publieke sector onder 0204, en daarnaast bestaan btw-gebaseerde schema's zoals 9925 (BE:VAT) of 9930 (DE:VAT). Identifierschema's, hun formaten en hoe u de geregistreerde identifier van een partner vindt, worden behandeld op Peppol-identifiers; de gratis Peppol-identifier-tool controleert het formaat van een waarde.

Discovery: SML, DNS en SMP

Peppol heeft geen centrale directory die een verzender bevraagt. Het verzendende access point vindt het endpoint van de ontvanger dynamisch:

1. Hash de participant-identifier. De actuele SML-specificatie (1.3.0) gebruikt een U-NAPTR-record: de identifierwaarde wordt in kleine letters gezet, gehasht met SHA-256, Base32-gecodeerd zonder de afsluitende "=" en vóór het schema en de SML-zone geplaatst. De oudere CNAME-vorm met een MD5-hash en een voorvoegsel "B-" werd in een opschoning in februari–maart 2026 uit de door de Commissie beheerde SML verwijderd.
2. Los hem op in de SML-zone. De Service Metadata Locator is een DNS-zone die elke gehashte deelnemer koppelt aan de SMP die zijn metadata host. Het NAPTR-antwoord bevat de URL van de SMP.
3. Bevraag de SMP. De Service Metadata Publisher beantwoordt twee REST-aanroepen: GET /{participantId} geeft de documenttypen die de deelnemer kan ontvangen, en GET /{participantId}/services/{documentTypeId} geeft het endpoint voor een daarvan terug — de AS4-URL, de transportprofiel-identifier, het certificaat van de ontvanger en de procesidentifier. De geldende SMP-specificatie is 1.4.0.
4. Lever af. Het verzendende access point versleutelt en ondertekent het bericht voor dat certificaat en post het naar die URL.

De SML is in 2026 verhuisd. OpenPeppol haalde de locator in eigen huis, weg van de eDelivery-infrastructuur van de Commissie: productie verhuisde van edelivery.tech.ec.europa.eu naar api.sml.prod.tech.peppol.org, en de test-SML (voorheen SMK, acc.edelivery.tech.ec.europa.eu) naar api.sml.test.tech.peppol.org. SMP-operatoren moesten hun registraties vóór 31 mei 2026 verhuizen en access points moesten hun DNS-lookups vóór 31 augustus 2026 omschakelen. Deelnemer-lookups worden opgelost onder iso6523-actorid-upis.participant.sml.prod.tech.peppol.org (productie) en …sml.test.tech.peppol.org (test).

Transport: AS4 via een access point

Berichten reizen tussen access points over het Peppol AS4-profiel (versie 2.0.3, geldig vanaf 22 april 2024), een ebMS3/AS4-uitwisseling met ondertekening en versleuteling op basis van certificaten die door de OpenPeppol-PKI worden uitgegeven. Alleen geaccrediteerde access points bezitten die certificaten: om er een te worden, ondertekent een organisatie de Peppol Transport Infrastructure Agreement, doorstaat ze conformiteitstests en opereert ze onder de service-level-regels van OpenPeppol. Daarom gebruiken de meeste softwareleveranciers, KRONENWERK inbegrepen, een aanbieder in plaats van zelf een access point te exploiteren.

Het zakelijke document wordt verpakt in een Peppol Business Message Envelope (SBDH, specificatie 2.0.2, van kracht sinds 2 juli 2026), die verzender, ontvanger, documenttype-identifier, procesidentifier en een instantie-identifier bevat. De envelop is waarop het access point routeert; de UBL erin is wat de software van de ontvanger leest. Wanneer u integreert met de API van een access point-aanbieder, bouwt de aanbieder de envelop meestal op uit enkele parameters en levert u alleen de UBL en de ontvangeridentifier aan.

Validatie en de testomgeving

Een verzendend access point valideert elk document vóór verzending tegen de Peppol-Schematron en wijst mislukkingen af. Valideer eerst aan uw kant met dezelfde artefacten: CEN-EN16931-UBL.sch en PEPPOL-EN16931-UBL.sch, te downloaden uit de BIS Billing 3.0-documentatie, uitgevoerd met een willekeurige Schematron-processor of met het Peppol-scenario van de KoSIT-validator. Regelidentifiers PEPPOL-EN16931-R001 en volgende benoemen de Peppol-specifieke fouten; BR-xx en BR-CO-xx benoemen de kernfouten.

Voor end-to-end-tests exploiteert OpenPeppol een testnetwerk met een eigen SML (de T-SML), een eigen PKI en test-participant-identifiers. Access point-aanbieders stellen het beschikbaar als sandbox: documenten die daarheen worden gestuurd, worden alleen bij testdeelnemers afgeleverd en bereiken nooit een echte ontvanger. Het Peppol-testnetwerk is de juiste plaats om uw identifierverwerking en envelop te bewijzen vóór de eerste productiefactuur; een document dat valideert maar is geadresseerd aan een identifier die de ontvanger nooit heeft geregistreerd, faalt pas bij de lookup, en dat is precies wat het testnetwerk u toont.

Responses: berichtniveau en factuurniveau

Er bestaan twee soorten feedback, en een verzender moet beide afhandelen.

Transportontvangstbevestiging

De ondertekende AS4-receipt van het ontvangende access point bewijst dat het bericht bij hoek 3 is aangekomen. Ze zegt niets over de inhoud.

Message Level Response (MLR, BIS 3.0)

Een UBL-ApplicationResponse die door het ontvangende access point of de ontvanger naar de verzender wordt teruggestuurd en het resultaat van de validatie meldt: AP aanvaard (geen fatale fouten), RE afgewezen (conformiteitsschendingen, verwerking stopt), AB bevestigd zonder validatie. Een ontvanger die fatale fouten vindt, moet via MLR afwijzen, ook als er geen werd gevraagd.

Invoice Response (BIS 3.2)

Een antwoord op bedrijfsniveau van de koper — aanvaard, afgewezen, betaald, voorwaardelijk aanvaard — gebruikt in het profiel "billing with response" (billing:02). Optioneel, en ongelijkmatig ingevoerd.

In de praktijk: behandel een ontbrekende AS4-receipt als niet afgeleverd, een MLR RE als een documentfout die u moet herstellen en opnieuw verzenden, en een Invoice Response als een zakelijke gebeurtenis die u aan een persoon toont.

Hoe KRONENWERK dit abstraheert

MET BEPERKINGEN ONDERSTEUND KRONENWERK genereert bij uitreiking Peppol BIS Billing 3.0 UBL voor Belgische facturen, met de participant-identifier van de klant in het document geschreven en gevalideerd tegen de Peppol- en CEN-Schematron voordat het factuurnummer wordt verbruikt. KRONENWERK is geen Peppol-access point. Het verzendt en ontvangt via Peppol door middel van een geaccrediteerde access point-aanbieder (Storecove) zodra de onderneming is verbonden in Instellingen → Verzending; discovery, envelop, AS4-transport en receipts worden door die aanbieder uitgevoerd, en productieverzending hangt af van dat account en zijn configuratie. Inkomende UBL-facturen die via de aanbieder worden ontvangen, worden ingelezen als inkoopfacturen. KRONENWERK bevat bewust geen eigen DNS- of SMP-client: de SML-migratie van 2026 vereiste niets van KRONENWERK, omdat de lookup nooit zijn taak was.

Via de API maakt een ontwikkelaar het concept aan (POST /invoices/drafts) en leest hij de uitgereikte factuur (GET /invoices/{number}); uitreiking, validatie en verzending gebeuren in het product, en de webhook invoice.issued meldt de uitreiking. Er is geen endpoint dat ruwe UBL indient, een deelnemer opzoekt of een MLR teruggeeft. Wat de API rond Peppol wel en niet kan, wordt beschreven in Peppol-integratie; de bredere context staat op de Peppol-pagina en verzenden en ontvangen, en de Belgische verplichting op de hub België en de landenpagina.