Open

Agenda

Welcome and housekeeping

I. Belgian Service Provider Forum - Improve The Model: recap/close

II. Use of Hermes: recap/close

III. SMP Redirect

IV. Network Quality - focus on network metadata

V. Multiple Receivers under one enterprise number: IBAN as KYC-compliant 2ndary ID?

VI. Add Control On VAT Nr (new topic)

Backlog / AOB / Next forum

Welcome and Housekeeping

1. This meeting is recorded. By attending it you agree with the recording.

2. Presence

• Peppol SPs enrolled with BPA (or in the process), or having transmitted their Annex 3 to the BP
  Non-Belgian SPs: please send urgently your annex 3 (contacts) to peppol@bosa.fgov.be!!!

• Other organizations (such as foreign PAs, business systems, …) on a case by case basis

• persons who have received the invitation directly from BPA
  (do no forward: contact BPA if you wish to add colleagues to the distribution list)

• identified with a personal email address (no group address, no bots)

• who have confirmed participation (by accepting the meeting invitation).
  Please make sure you have done so if you plan to attend the meeting.

Roles

Chair

Minutes taker

Approval of the agenda

Approval of minutes of previous meeting published on Belgian Peppol SP Forum main page

No comments received so far. Proposition: approve the minutes

Review of action items of previous meeting

No open action items

BE SP Forum - Improve The Model: recap/close

• Early 2024 need for reorganizing the BE Peppol SP Forum was identified: b2b mandate, engagement and cooperation, forum members increase. Survey was performed by BPA.

• Outcome:

  • Topics / Topics Owners

  • Topics and owners identification: based on the various interactions + SP proposals

  • Topics are put on Forum plenary meeting agenda in function of progress and priority

  • When appropriate, focus groups are setup to progress on topics. Focus group report back to plenary.

  • BPA provides global secretariat

  • See also “Backlog” (below)

• Proposal: this topic can be closed. Continuous improvement will derive from day to day use, not requiring a specific item on the Forum topics list.

Use of Hermes: recap/close

SMP Redirect - registration interface standardization

Report back from the focus group

Governance aspects. Consultation of the Service Providers

• Proposal submitted:
  add following clause to the BE PASR: all SMP Service Providers active in Belgium must be able to process SMP redirect registration requests, as described in [specification of SMP Redirect registration] , for the Belgian participants for whom they are primary SMP, as of (target date)

• Benefits

  • Creates visibility: all SPs know what they can expect from others and what others can expect from them;

  • Synchronisation of the implementations around a common target date

  • Removes the risk that SPs wait for each other’s (catch-22)

  • More consistent for end-users - they won’t be confronted to different behaviors depending on the SP

  • Official and public, whereby the communication flows between SPs and with end-users is made easier

• Drawbacks

  • More regulation, more administrative burden

  • Less individual freedom and responsibility

  • Makes all SPs offering more similar. losing a differentiation factor

  • From a global perspective, it makes Belgium add new rules / move away from its “peppol-plain vanilla” strategy

• Other considerations:

  • If SMP redirect support is not mandatory then SPs need to foresee a plan B - scenario in their secondary SMP logic implementation, where they get back to their client to sort out the failure with the primary SMP

  • If SMP redirect support is mandatory, the SPs also need to foresee a plan B- scenario in their secondary SMP logic implementation, in case of failure - eg they report the failure to the primary SMP out of band.

  • The choice to add a rule can be motivated by the known limitation in the current set of peppol-specifications, to put this perceived fragmentation in perspective

• Proposed way forward:

  • Each SP Forum participant to review above proposal

  • At plenary meeting, roundtable to collect additional benefits, drawbacks and/or other considerations.

  • After the meeting each SP is invited to communicate their preference (yes of no) to the BPA, no later than COB Thursday Oct 7^th. Only one communication per SP.

  • In function of the results of the consultation round, BPA will either add the clause, or take other actions.

Network Quality - focus on network metadata

Multiple Receivers Under 1 CBE: IBAN as KYC-compliant 2ndary ID?

Add Control On VAT Nr

Backlog / AOB / Next forum

Backlog:

Any Other Business

• Announcements – candidates for discussion in SP forum

  • CA migration (G3)

  • TestBed Upgrade

• Self-Billing Flow - supporting tools – progress

• G.T&Cs - embedding in invoice: legal constraints and best practices in e-invoices

Announcements:

Below copy of recent announcements sent by Open Peppol central bodies, that may justify discussion in our forum. Please let us know if you need to discuss these announcements in the Forum.

1. Certificate Authority Migration:

-----Original Message-----
From: edec-members-bounces@peppol.eu <edec-members-bounces@peppol.eu> On Behalf Of OpenPeppol AISBL |Sent: maandag 11 augustus 2025 13:15 |To: edec-members@peppol.eu; sp@peppol.eu; pa@peppol.eu |Subject: [EXT] : [eDEC-Members] Peppol PKI 2025 - Certificate Authority Migration Plan v1.0_PUBLISHED 2025.08.11.pdf

Dear Service Providers,Dear Peppol Authorities, 

The eDEC Change Management Board has approved the final Peppol PKI Migration Plan for release. 

The PKI Migration Plan is attached to this email and is also accessible via Confluence at: Peppol PKI 2025 - Certificate Authority Migration Plan - 1. OpenPEPPOL Members Area - Confluence

The new PKI CA chains are documented and available for download at: Peppol PKI 2025 - Certificate Authorities - 1. OpenPEPPOL Members Area - Confluence

 The issuing and enrolment process for the new PKI is documented at: Peppol PKI 2025 - Issuing and Enrolment Process - 1. OpenPEPPOL Members Area - Confluence 

OpenPeppol will also publish a set of implementation neutral guides that complement this migration plan. These documents will explain how to execute critical steps while keeping normative what and when in the PKI Migration Plan:Peppol PKI 2025 - Dedicated Migration Guideline - 1. OpenPEPPOL Members Area - Confluence

Kind regards,

OpenPeppol AISBL

2. Test bed upgrade:

From: <peppol-all-bounces@peppol.eu> on behalf of OpenPeppol AISBL | openpeppol@peppol.eu |Sent on: Thursday, July 31, 2025 7:27:48 PM | To: peppol-all@peppol.eu | Subject: [Openpeppol] Peppol Testbed upgrade

Dear OpenPeppol Members,
 
We are pleased to announce that the Peppol Testbed has been upgraded with new capabilities and improvements.
 
A. New Functionality and upgrades
 
1. Offline XML Validator
As of 31^st July 2025, we have introduced a new Offline XML validator service to support document validation without needing to enroll in a test suite. The service is ideal for quick checks and ad-hoc validation outside the structured test cases
 
Getting started:
·       Select “Enter XML Validation Tool” from the Testbed’s landing page
·       Upload your XML document using the provided interface
·       Choose the specification to validate against
·       Review the validation results, which indicate conformance with the selected specification
 
2. PINT AE test suites upgraded to version 1.0.1 and MLS support  
[…]
 
3. PINT MY test suite upgrade
[…] 
4. PINT AUNZ test suites upgrade
[…]

 
B. Documentation
 
To assist Service Providers with the tests, the following documents are available:
 
·       The Environment Description documents provide a more detailed description of the available test cases.

·       The User Guide documents provide a guide on how to use each test suite user interface, as well as the key steps in carrying out the various test cases.

These documents are available in each test suite under the tab ‘Documentation’.

C. Access and Usage
The Testbed suites and Offline XML Validator service are accessible via https://www.testbed.peppol.org

To use the Testbed suites, Service Providers must be authenticated using PKI client authentication. This requires obtaining a Peppol AP certificate and importing into your browser’s keystore.

Any further questions in regard to the Testbed may be submitted via the Peppol Service Desk at: https://openpeppol.atlassian.net/servicedesk/customer/portals

Kind regards

OpenPeppol

Self-Billing Flow - supporting tools – progress

Reminder and status request by and on request of FPS Finance. Presented by Wouter Bollaert.

General Terms &Conditions - embedding in invoice: legal constraints and best practices in e-invoices

Possible SP Forum Topic proposed by Walter Vander Goten (Soluz.io)

Next forum

Proposed date: Tuesday Dec 9, 2025, 13:30 – 15:00

Annex 1: Proposal for APIs to automate the management of Peppol SMP Redirects

Draft Version as of 2025-07-02

Introduction

The document defines the 3 mandatory APIs for SMP Redirect management:

• Create Redirect for Peppol Participant ID and Document Type ID

• Update Redirect for Peppol Participant ID and Document Type ID

• Delete Redirect for Peppol Participant ID and Document Type ID

General Technical Considerations

All APIs described in this document follow these rules:

• Payload MUST use the application/xml Content-Type

• Applicable only on a secure network layer using mutual TLS (mTLS) with Peppol SMP Certificates as the client certificates

• https-only communication (allowed in Peppol from November 1st, 2025 – see the “CNAME to NAPTR migration document”)

• All APIs must respond synchronously

Redirect APIs

For increased simplicity it was decided to merge “Create” and “Update” APIs into a single technical API to limit the implementation effort.

All URLs provided in this section are relative to the base URL used by the SMP to register itself in the SML.

The URLs suggested in this document were chosen in a way that OpenPeppol can later take over the specification and will not create conflicts with eventually generalized APIs.

Create or Update Redirect

This API lets the Secondary SMP create or update a Redirect from the Primary SMP to the Secondary SMP. This API must be implemented synchronously. The call should only return with a success code, if the Redirect was actually created or updated.

Input parameters needed for this API:

• Peppol Participant ID

• Peppol Document Type ID

• Full URL to the SignedServiceMetaData as created by the Secondary SMP

• The Peppol SMP certificate of the Secondary SMP - part of the authorization

Client: Secondary SMP

Server: Primary SMP

API definition:

• HTTP Method: PUT

• URL: /be-redirect/

• Payload:

  • XML - XML Schema required

  • Example:

<Redirect xmlns=”urn:peppol:belgium:smp:redirect:v1”>
<ParticipantID schemeID=”iso6523-actorid-upis” >0208:1234567890</ParticipantID>
<DocumentTypeID schemeID=”busdox-docid-qns” >urn:oasis….:2.1</DocumentTypeID>
<RedirectURL>https://secondary.smp/peppol/iso6523-actorid-upis%3A%3A0208%3A1234567890/services/urn%3Aoasis%3A….%3A2.1</RedirectURL>
</Redirect>

Content-Type: application/xml

• Mandatory synchronous response codes:

  • 200 OK

    • if the redirect was successfully updated - no response content

  • 201 Created

    • If the redirect was initially created - no response content

  • 400 Bad Request (may contain an error text using text/plain Content-Type)

    • If the payload XML is missing

    • If the payload XML is not XML

    • If the payload XML is not XML Schema compliant

    • If the payload XML contains values not following the Peppol specifications (document type ID with syntax error)

  • 401 Unauthorized (may contain an error text using text/plain Content-Type)

    • The provided client certificate is not a valid Peppol SMP certificate

  • 403 Forbidden (may contain an error text using text/plain Content-Type)

    • The Primary SMP already has a redirect for another Secondary SMP on the specific Participant Identifier and Document Type Identifier

  • 404 Not Found (may contain an error text using text/plain Content-Type)

    • If the receiving SMP is not the primary owner of the passed Participant ID in the payload

  • 500 Internal Server Error (may contain an error text using text/plain Content-Type)

    • If something went wrong internally - this error must make sure, that the activity is NOT performed (e.g. DB rollback)

Mandatory checks on the receiver side:

• mTLS must have been used

• A mTLS client certificate must be provided

• The mTLS client certificate must be a valid Peppol SMP Certificate (certificate issuer check):

  • A SMP operating in the Peppol Production Network must only accept Peppol Production SMP certificates

  • A SMP operating in the Peppol Test Network must only accept Peppol Test SMP certificates

• The mTLS client certificate must be valid per the date and time of request

• The mTLS client certificate must not be revoked (as per CRL or OCSP check)

• The https connection must follow the Peppol Policy for Transport Security (see https://docs.peppol.eu/edelivery) (like the rest of the SMP)

• The provided payload must be validated

  • A payload must be present

  • The payload must be well formed XML

  • The payload must be checked against the XML Schema

  • The provided Peppol Participant ID must follow the rules from the Peppol Policy for use of Identifiers (in its current version)

  • The provided Peppol Document Type ID must follow the rules from the Peppol Policy for use of Identifiers (in its current version) - this implies that the Document Type ID must be listed in the eDEC Code Lists

  • The provided full URL must be a syntactically correct URL

  • The provided full URL must use the https scheme

  • The provided full URL must be checked for existence and accessibility via a HTTP GET call

    • Note: external API

  • The provided full URL must contain the Participant Identifier as well as the Document Type Identifier in it, according to the Peppol SMP specification (attention: full URL might use URL encoding - so URL decode before checking)

    • Per today the full URL would be sufficient, but to be extensible in the future and support SMP base URLs outside of the root path, providing Participant ID and Document Type ID separately has benefits)

Actions needed to be performed by the Primary SMP:

• Check request parameters as defined above

• Create or update Redirect in local data structures

  • Take the URL from the XML payload

  • Use the Peppol SMP Certificate subject from the mTLS client certificate as the “CertificateUID” field

    • If a Redirect for that Participant ID and Document Type ID is present, but with a different Certificate UID field, the request must be rejected (HTTP 403)

• Return success or error response via API

Delete Redirect

This API lets the Secondary SMP delete a Redirect from the Primary SMP to the Secondary SMP. This API must be implemented synchronously. The call should only return with a success code, if the Redirect was actually deleted.

Input parameters needed for this API:

• Peppol Participant ID

• Peppol Document Type ID

• The Peppol SMP certificate of the Secondary SMP - part of the authorization

Client: Secondary SMP

Server: Primary SMP

API definition:

• HTTP Method: DELETE

• URL: /be-redirect/{ppID}/{docTypeID}

  • {ppID} – placeholder for the Peppol Participant ID

  • {docTypeID} – placeholder for the Peppol Document Type ID

  • Note: Participant ID and Document Type ID should be URL encoded

• Payload: none

• Mandatory synchronous response codes:

  • 200 OK

    • if the redirect was successfully deleted - no response content

  • 400 Bad Request (may contain an error text using text/plain Content-Type)

    • If the provided Peppol Participant ID does not follow the rules from the Peppol Policy for use of Identifiers (in its current version)

    • If the provided Peppol Document Type ID does not follow the rules from the Peppol Policy for use of Identifiers (in its current version)

  • 401 Unauthorized (may contain an error text using text/plain Content-Type)

    • The provided client certificate is not a valid Peppol SMP certificate

  • 403 Forbidden (may contain an error text using text/plain Content-Type)

    • The Primary SMP has a redirect available but for a different Secondary SMP (based on the “Certificate UID” being part of the redirect)

  • 404 Not Found (may contain an error text using text/plain Content-Type)

    • If the receiving SMP does not have a Redirect for the provided combination of Participant ID and Document Type ID

  • 500 Internal Server Error (may contain an error text using text/plain Content-Type)

    • If something went wrong internally - this error must make sure, that the activity is NOT performed (e.g. DB rollback)

Actions needed to be performed by the Primary SMP:

• Check request parameters as defined above

• Delete Redirect in local data structures

• Return success or error response via API

Estimated Impact

• SMP implementations