Peppol developer guide: BIS Billing, SMP lookup, AS4 and responses

Peppol is a four-corner network: the sender's software (corner 1) hands a document to its access point (corner 2), which discovers the receiver's access point (corner 3) through a DNS and SMP lookup and delivers over AS4; corner 3 passes it to the receiver's software (corner 4). For a developer this means three separate problems — producing a Peppol BIS Billing 3.0 document, addressing it with the right participant identifier, and getting an accredited access point provider to carry it. KRONENWERK solves the first two itself and delegates the third to Storecove, an accredited access point provider.

BIS Billing 3.0 is EN 16931 with Peppol's constraints

Peppol BIS Billing 3.0 is a Core Invoice Usage Specification (CIUS) of EN 16931: every document that conforms to the BIS also conforms to the European standard, and the BIS adds requirements the network needs to route and process an invoice. The current publication at the time of reading is version 3.0.21 (May 2026 release). It binds the semantic model to UBL 2.1 Invoice and CreditNote; CII is not used on Peppol for billing.

The identifiers that make a UBL file a Peppol BIS invoice are fixed strings:

Beyond the core rules, the BIS requires the seller and buyer electronic addresses (cbc:EndpointID with a schemeID), a buyer reference or purchase order reference, payment means with a code, and a handful of formatting constraints. Those are enforced by the Peppol Schematron (PEPPOL-EN16931-UBL.sch) as rules named PEPPOL-EN16931-Rxxx, on top of the CEN rules (CEN-EN16931-UBL.sch). The core rules themselves are explained in the EN 16931 developer guide.

Participant identifiers

A Peppol participant is addressed by a scheme and a value, written scheme:value — for example 0208:0123456789 for a Belgian enterprise number or 0204: followed by a Leitweg-ID for a German public-sector buyer. The scheme codes come from the ISO 6523 International Code Designator list as maintained in OpenPeppol's Policy for use of Identifiers (version 4.4.0, valid from 1 November 2025 at the time of reading). The same identifier appears in three places, and they must agree:

1. In the UBL document, as cac:AccountingCustomerParty/cac:Party/cbc:EndpointID schemeID="0208" (BT-49) and the equivalent for the seller (BT-34).
2. In the envelope (SBDH) as sender and receiver identifiers, using the identifier scheme iso6523-actorid-upis.
3. In the receiver's SMP entry, where the lookup happens.

Which scheme a given business uses depends on its country and on what it registered. Belgium registers under 0208 (enterprise number), Germany's public sector under 0204, and VAT-based schemes such as 9925 (BE:VAT) or 9930 (DE:VAT) exist alongside. Identifier schemes, their formats and how to find a partner's registered identifier are covered in Peppol identifiers; the free Peppol identifier tool checks a value's format.

Discovery: SML, DNS and SMP

Peppol has no central directory a sender queries. The sending access point finds the receiver's endpoint dynamically:

1. Hash the participant identifier. The current SML specification (1.3.0) uses a U-NAPTR record: the identifier value is lower-cased, hashed with SHA-256, Base32-encoded with trailing "=" stripped, and prefixed to the scheme and the SML zone. The older CNAME form with an MD5 hash and a "B-" prefix was removed from the Commission-operated SML in a clean-up in February–March 2026.
2. Resolve it in the SML zone. The Service Metadata Locator is a DNS zone that maps each hashed participant to the SMP hosting its metadata. The NAPTR answer carries the SMP's URL.
3. Query the SMP. The Service Metadata Publisher answers two REST calls: GET /{participantId} lists the document types the participant can receive, and GET /{participantId}/services/{documentTypeId} returns the endpoint for one of them — the AS4 URL, the transport profile identifier, the receiver's certificate and the process identifier. The SMP specification in force is 1.4.0.
4. Deliver. The sending access point encrypts and signs the message for that certificate and posts it to that URL.

The SML moved in 2026. OpenPeppol took the locator in-house from the Commission's eDelivery infrastructure: production moved from edelivery.tech.ec.europa.eu to api.sml.prod.tech.peppol.org, and the test SML (formerly SMK, acc.edelivery.tech.ec.europa.eu) to api.sml.test.tech.peppol.org. SMP operators had to move their registrations by 31 May 2026 and access points had to switch DNS lookups by 31 August 2026. Participant lookups resolve under iso6523-actorid-upis.participant.sml.prod.tech.peppol.org (production) and …sml.test.tech.peppol.org (test).

Transport: AS4 through an access point

Messages travel between access points over the Peppol AS4 profile (version 2.0.3, valid from 22 April 2024), an ebMS3/AS4 exchange with signing and encryption based on certificates issued by the OpenPeppol PKI. Only accredited access points hold those certificates: to become one, an organisation signs the Peppol Transport Infrastructure Agreement, passes conformance testing, and operates under OpenPeppol's service-level rules. That is why most software vendors, KRONENWERK included, use a provider rather than running an access point.

The business document is wrapped in a Peppol Business Message Envelope (SBDH, specification 2.0.2, in force from 2 July 2026), which carries sender, receiver, document type identifier, process identifier and an instance identifier. The envelope is what the access point routes on; the UBL inside is what the receiver's software reads. When you integrate with an access point provider's API, the provider usually builds the envelope from a few parameters and you supply only the UBL and the receiver identifier.

Validation and the test environment

A sending access point validates every document against the Peppol Schematron before transmission and rejects failures. Validate on your side first with the same artefacts: CEN-EN16931-UBL.sch and PEPPOL-EN16931-UBL.sch, downloadable from the BIS Billing 3.0 documentation, run with any Schematron processor or with the KoSIT validator's Peppol scenario. Rule identifiers PEPPOL-EN16931-R001 and following name the Peppol-specific failures; BR-xx and BR-CO-xx name the core ones.

For end-to-end tests, OpenPeppol operates a test network with its own SML (the T-SML), its own PKI and test participant identifiers. Access point providers expose it as a sandbox: documents sent there are delivered to test participants only and never reach a real receiver. The Peppol test network is the right place to prove your identifier handling and envelope before the first production invoice; a document that validates but is addressed to an identifier the receiver never registered fails only at lookup time, which is what the test network shows you.

Responses: message level and invoice level

Two kinds of feedback exist, and a sender should handle both.

Transport receipt

The AS4 signed receipt from the receiving access point proves the message arrived at corner 3. It says nothing about the content.

Message Level Response (MLR, BIS 3.0)

A UBL ApplicationResponse sent by the receiving access point or receiver back to the sender, reporting the result of validation: AP accepted (no fatal errors), RE rejected (conformance violations, processing stops), AB acknowledged without validation. A receiver that finds fatal errors should reject via MLR even if none was requested.

Invoice Response (BIS 3.2)

A business-level answer from the buyer — accepted, rejected, paid, conditionally accepted — used in the "billing with response" profile (billing:02). Optional, and adopted unevenly.

In practice: treat a missing AS4 receipt as not delivered, an MLR RE as a document defect to fix and resend, and an Invoice Response as a business event to show a person.

How KRONENWERK abstracts this

SUPPORTED WITH LIMITATIONS KRONENWERK generates Peppol BIS Billing 3.0 UBL at issuance for Belgian invoices, with the customer's participant identifier written into the document and validated against the Peppol and CEN Schematron before the invoice number is spent. KRONENWERK is not a Peppol access point. It sends and receives over Peppol through an accredited access point provider (Storecove) once the company is connected in Settings → Delivery; discovery, envelope, AS4 transport and receipts are performed by that provider, and production sending depends on that account and its configuration. Incoming UBL invoices received through the provider are read into bills. KRONENWERK contains no DNS or SMP client of its own, by design: the SML migration of 2026 required nothing of KRONENWERK because the lookup was never its job.

Over the API, a developer creates the draft (POST /invoices/drafts) and reads the issued invoice (GET /invoices/{number}); issuing, validation and dispatch happen in the product, and the invoice.issued webhook reports the issuance. There is no endpoint that submits raw UBL, looks up a participant or returns an MLR. What the API can and cannot do around Peppol is described in Peppol integration; the wider context is on the Peppol page and sending and receiving, and the Belgian mandate on the Belgium hub and country page.