The PSB is a certified Peppol Access Point and SMP (Service Metadata Publisher). Via the API you configure which document types an organisation can receive, publish company data in the Peppol Directory and manage the SMP registration. This article covers the technical background and the API endpoints you use for this.

Peppol uses a 4-corner model: the sender (C1) sends a document via their Access Point (C2) to the Access Point of the receiver (C3), which forwards it to the receiver (C4). Routing relies on two central components:

• SML (Service Metadata Locator): a central DNS registry that points to the correct SMP of the receiver
• SMP (Service Metadata Publisher): contains the metadata of a receiver, which documents it can receive and via which Access Point

When you send an invoice through the PSB, the PSB automatically performs an SML/SMP lookup to find the correct Access Point of the receiver. As an integrator, you don't need to do this yourself.

The Peppol infrastructure is actively being developed. For integrators using the PSB API this has no impact: the PSB handles SML/SMP lookups automatically. Below are the current developments for your information.

SML insourcing. OpenPeppol is taking over management of the SML from the European Commission (DG DIGIT). The migration window opened on 19 March 2026. Two separate deadlines apply: the deadline for SMP registrations is 31 May 2026, the migration period for AP Lookup (DNS resolution) is extended to 31 August 2026. OpenPeppol is discussing with the European Commission whether the SMP registration deadline can also be extended. For API integrators, nothing changes in terms of endpoints or lookups: the PSB handles the migration internally.

CNAME-to-NAPTR migration. The migration from DNS CNAME records to NAPTR records for SML lookups was completed in March 2026. NAPTR has been mandatory since 1 February 2026. The old CNAME records were removed from the SMK test network (4 March 2026) and the SML production network (11 March 2026). This is an internal DNS change in the Peppol infrastructure. The PSB already uses NAPTR and no adjustments are needed in your integration.

PKI G3 migration. OpenPeppol is preparing the transition from PKI Generation 2 (G2) to Generation 3 (G3) certificates. G3 certificates are used for the mutual communication between Access Points. The Peppol Testbed has supported both G2 and G3 certificates since March 2026, so that Service Providers can test ahead of time. No mandatory transition date has been published yet. For API integrators nothing changes: the PSB handles the certificate renewal internally.

Peppol supports logistics document types in addition to invoices via the Peppol Logistics specification. Version 1.2 has been mandatory since 16 March 2026. Release 1.3 is in member review until 15 April 2026, with publication expected on 18 May 2026.

Supported logistics documents:

• Despatch Advice (packing slip)
• Weight Statement
• Transport Execution Plan
• Waybill

New features in release 1.3:

• ProductTraceID with schemeID for ItemInstance
• DespatchAdviceTypeCode extended with values for use case identification (101, 102, 112, 203-211, 303-311)
• DocumentStatusCode with new value "55 - Notification only" for changes after invoicing
• Waste Declaration Number as AdditionalItemProperty
• New code list ProductTraceIDschemeIDCode

Release 1.3 resolves RFCs LLC-27 through LLC-35, including ItemInstance alignment, non-invoicing updates and sub-treatment codes for waste.

When registering a party in the eConnect SMP, you use capabilities to determine which document types that party can receive. Each capability has three possible states:

The recommended value for new registrations is inherited, unless a party specifically needs to deviate from the default.

Capabilities are configured via the Peppol config endpoint:

PUT /api/v1/peppol/config/party/{partyId}

In the request body, specify the desired state for each capability. An example:

{
  "capabilities": {
    "invoices": "on",
    "selfbilling": "inherited",
    "invoiceResponse": "on",
    "orderOnly": "on",
    "orderAdvanced": "off"
  }
}

The Peppol Directory is the public registry of all Peppol participants. By publishing a businessCard, a party becomes discoverable in the directory. The businessCard contains:

The businessCard is published via the Enrollment endpoint or via the SMP configuration. After publication, the organisation is discoverable at directory.peppol.eu.

The PSB API does not derive any fields from a linked business register. Regardless of the identifier scheme (KvK 0106, VAT 9944, OIN 0190, GLN 0088 or another), both names and an address with country code must be explicitly present in the payload. An example of a correctly configured businessCard:

"businessCard": {
  "names": {
    "value": "eVerbinding, eConnect",
    "state": "on",
    "description": "Business names."
  },
  "address": {
    "value": "Pelmolenlaan 16A, 3447 GW, Woerden, NL",
    "state": "on",
    "description": "Geographic information."
  },
  "emailAddress": {
    "value": "[email protected]",
    "state": "on",
    "description": "Technical contact"
  },
  "state": "on"
}

The country code (in the example above, NL at the end of the address field) must be explicitly included.

This error message is diagnostically unambiguous: the submitted payload is missing names, or the address does not contain a country code. The fix is always to add those fields explicitly to the businessCard payload, not to change anything at another level (party, identifier, SMP capabilities). The message occurs relatively often with GLN integration (0088) in practice, because GLN integration partners less often use a template that includes these fields by default. The PSB does not exhibit different behaviour for GLN compared to other schemes.

Checking upfront whether a recipient is reachable on Peppol is done per document type and via an advanced lookup endpoint:

The response shows the available channels, the selected Access Point and the supported document types. Use these endpoints to validate upfront whether a delivery will succeed. They are unlimited in every plan (proactive route detection/discovery).

Each party in the SMP is identified via an identifier with a schemeID. The most commonly used schemes:

The PSB API accepts both the numeric schemeID and the letter code: 9925:BE0835689642 is equivalent to BE:VAT:BE0835689642. When using external lookup tools (such as SMP lookup), the official numeric schemeIDs must be used.

A party can have multiple identifiers, but each invoice may contain only one EndpointID.

In Belgium, two identifier types are used for Peppol. The enterprise number (KBO, schemeID 0208) is the primary identification number and mandatory for Peppol reception. Registration on VAT number (schemeID 9925) is optional, which means that looking up a Belgian organisation by enterprise number succeeds more often than by VAT number.

The enterprise number can be derived from the VAT number by removing the country code prefix (BE). For example: VAT number BE0835689642 corresponds to enterprise number 0835689642.

When sending a document, the PSB extracts the Peppol ID from the EndpointID element in the XML. This element determines to which receiver the document is routed. If the EndpointID is missing or incorrectly filled in, the document is not valid and receives the status InvoiceSentError.

An incorrect XML is not automatically retried. The correction lies with the source system (the software package generating the invoice), not with the PSB. Check upfront via queryRecipientParty whether the receiver is reachable on the Peppol network.

Want to automate the full registration process? Read the article on the Enrollment API, which lets you configure registration, capabilities and hooks in a single API call.

• Peppol registration via the API (Enrollment)
• Migration to or from eConnect
• Configure multi-channel delivery
• Overview: the Procurement Service Bus (PSB)
• What is Peppol and how does the network work?
• Register on Peppol (platform)