Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
/
Belgian Peppol Service Providers Forum - content area
Belgian Peppol Service Providers Forum - content area
Welcome BOSA, the Belgian Peppol Authority, welcomes you to this collaboration area dedicated to the Belgian jurisdiction. It supports the forums that we are used to organize since 2016 to assist the IT sector in widening the eInvoicing and eProcurement solutions in the Belgian market. → The structure of this area will grow gradually to best fit with the discussions and opportunities that will arise.
Enjoy your visit and let us know! the eInvoicing team @BOSA
This Focus group (FG) originally was established to address missing needs of the Factoring sector. At the same time many other scenarios were reported to BPA, sharing similarities with the needs expressed by the Factoring sector representative. In order to ensure consistency these other third-party scenarios were also submitted to the same FG. Currently the FG handles the following scenarios: Copy-to-Accountant, Agent, German central settlement, Factoring.
The FG also strives to produce results that are directly suitable for global use. OO is actively involved, as well as POAC and eDEC; additionally, an RFC is registered (PEPPOL-18555). Germany, Netherlands and UK also appointed liaisons to the Focus Group.
Status
In order to ensure progress the Focus group decided to address the scenarios progressively. The focus now lies on “copy-to-accountant”.
Last report back of the focus group on the forum plenary session is available here.
Work in Progress
BPA ref EINVC-1143
Add control on VAT number
Topic Owner
WOLTERS KLUWER (Paul)
Other focus group participants
DW SOFT, CW LOGISTICS, BPA
Abstract
In order to prepare for e-Reporting the FG proposes to add a control on the VAT number in the Peppol schematrons. This will reduce the risk of error in the e-reporting flow.
After having gathered a wide range of possible new rules, the FG opted for a two-phases approach. In phase I a first set of largely supported rules was added. in a later phase, the other possible rules will be discussed in all details and either approved or rejected (with motivation).
In the broader context of their role within GENA, NYMUS took contact BPA in April 2025. One of the concerns of NYMUS was the network quality, especially considering the growth of Peppol Access points consecutive to the Belgian e-Invoicing mandate. Additionally, with Mercurius and their role as BPA, BOSA has a long practical experience with the Peppol network and the existing quality issues. BOSA proposed NYMUS to address the global concern of network quality as a topic on the SP Forum. Several specific quality improvement actions are organized in this context:
Peppol Network Data Scanner - Belgian Pilot (BOSA)
Goal: to ensure that the Network data of the Belgian segment of the Peppol Network is of sufficient quality to support the obligation issued by Minister of Finance;
status: error rate decreased from 2,5% to 0,3% - see table below*. now routine process at BPA to broadcast errors to top-25 problematic SMPS
Peppol Network Data Scanner - Global scanner
Goal: moving on from the Belgian Pilot, contribute to the general improvement of the overall network data quality
status: after releasing a Requirements document for such a global scanner, drafted by a PAC taskForce (BE, FI, NK, SE, NG), endorsed by the PAC, and submitted to OO, the FG follows up the setup of the next versions of the scanner in the context of the Peppol Network Analytics project run by OO and involving CIWG.
Goal: consider adding an obligation/possibility to declare/verify that sending-AP is authorized to send on behalf of the sending-EU. Such declaration could be published on EU’s main SMP
Goal: perform a quick assessment of the transmission errors occurring on the network and come with proportional recommendation to resolve them
status: DONE: the FG investigations revealed that the current governance arrangements are sufficient to address this source of trouble. Recommendation is to engage dialogue with the other party (compliance procedure step 1); if such dialogue doesn’t lead to satisfying outcome, then move on to step 2 (report to your PA)
* : Peppol Network Data Scanner - belgian Pilot - outcome after 9 runs - overview
Run:
Error:
1 (10/12/2025)
2 (07/01/2026)
3 (27/01/2026)
4 (26/02/2026)
5 (10/03/2026)
6 (24/03/2026)
7 (24/04/2026)
8 (26/05/2026)
9 (30/06/2026)
10 (30/07/2026
11 (24/08/2026)
Run:
Error:
1 (10/12/2025)
2 (07/01/2026)
3 (27/01/2026)
4 (26/02/2026)
5 (10/03/2026)
6 (24/03/2026)
7 (24/04/2026)
8 (26/05/2026)
9 (30/06/2026)
10 (30/07/2026
11 (24/08/2026)
Primary use of enterprise number
9.365
7.409
6.312
4.344
3.905
3.960
3.005
3.428
3.302
11.072
3.851
Malformed ID {0208; 9925} - Mod97*
2.826
2.783
2.263
1.901
1.435
1.492
882
921
925
1.116
1.110
Malformed ID {0208; 9925} - other
2.472
2.437
2.064
1.741
1.340
1.347
779
808
813
1.036
1.028
no BIS {0208}
14.199
3.307
4.839
3.655
2.217
1.661
1.459
1.992
1.981
4.879
5.063
sub-tot
28.862
15.936
15.478
11.641
8.897
8.460
6.125
7.149
7.021
18.103
11.052
Not in Peppol Directory
42.162
51.506
62.980
63.194
49.342
62.297
43.816
47.723
44.982
48.801
46.490
grand tot
71.024
67.442
78.458
74.835
58.239
70.757
49.941
54.872
52.003
66.904
57.542
records scanned
1.200.000
1.707.728
1.834.317
1.953.000
1.979.333
2.003.240
2.065.152
2.088.863
2.110.331
2.077.605
2.138.241
Error rate 1 (incl Directory)
5,92%
3,95%
4,28%
3,83%
2,94%
3,53%
2,42%
2,63%
2,46%
3.2%
2,69%
Error rate 2 (excl Directory)
2,41%
0,93%
0,84%
0,60%
0,45%
0,42%
0,30%
0,34%
0,33%
0,87%
0,52%
*: malformed IDs details reveal a lot of dummy IDs, possibly test IDs in production.
A consequence of the e-invoicing reform for Belgian VAT-liable entities, is that many small or very small VAT-liables will use different tools - and consequently different access points - for inbound and outbound invoicing. If the outbound solution/AP wants to offer Invoice Response support, then they will need to record SMP redirect records in their customer’s primary SMP (which deals with inbound invoicing). This should cause major uptake of this practice. Such uptake will be constrained by the fact SMP redirect records are manually registered. To elevate such constraint, the Belgian SP forum has set up a Focus group to draft a spec for automating such registration.
Status
During H1-2025 the Focus group drafted and reviewed a first version of the spec. Then (a) the SPs refocused most of their effort in the onboarding of Belgian VAT-liable companies. Additionally, the CIWG 1.0 was established, addressing multiple SP patterns that are similar or connected to the issue we face in Belgium. This context caused the Focus group to pause their activities.
To assess whether the FG can, should or must restart their activities, the FG leader proposed to take a survey. This proposal was endorsed at Plenary 40.
Inform CIWG of the practical and urgent character of this issue on the Belgian market and the need for CIWG to produce a schedule of the definitive solution to the multiple SPs pattern
Francois (BOSA) and Leentje (Nymus) will attend the CIWG sessions to ensure the topic receives the correct priority.
CIWG has promised on Sept 1, 26 to take a decision within the next 2 months
If a Peppol-wide solution is not achieved in a timely matter
A proof of Concept (POC) will be needed in Belgium, involving at 3 to 5 service providers, to validate an SMP-Redirect-based interim plan.
The next step will need to be agreed on the governance option: does the support of the SMP-redirect need to be mandated via the B-PASR.
This focus group explores the challenges and opportunities that this new obligation introduces for Belgian SP Forum members.
Below it publishes resources that can be useful to the other members (useful information, Q&As, Tips, …). It also reports back progress to SP Forum during the plenary meetings.
One key topic of attention is how The openPeppol ISO/IEC27001 certification requirement relates to the NIS2 legal obligation (In Europe).
Public funding
Below, we have published the support measures/subsidies offered by the Regions to assist with the certification process
intro
The three Regions offer subsidies for obtaining ISO 27001 or CyFun certification. The procedures and the rates of financial support vary from one Region to another. However, all three Regions impose the following conditions:
Subsidies may not be used for the purchase of software and/or IT hardware.
The subsidy application must be submitted before the start of the certification process.
Subsidy applications may not cover the certification fees charged by a certification body.
Flanders
What Peppol Service Providers are entitled to : 45% of cybersecurity consultancy costs, max €7,500 per year
ME e-wallet (kmo-portefeuille, VLAIO): since 1 February 2026 the "advice" component is exclusively reserved for cybersecurity — ideal for ISO 27001/NIS2 projects. Rates: 45% for small enterprises, 35% for medium-sized ones, capped at €7,500 per year. Covers gap analysis, ISMS set-up, security policies and mock audits.
Training component: 30% (small) / 20% (medium), also capped at €7,500 per year — includes ISO 27001 Lead Implementer / Lead Auditor and awareness training.
Key conditions: SME or liberal profession with an establishment in the Flemish Region; VLAIO-registered provider required; non-profits (vzw) excluded. ⚠️ Different timing rule: the application must be submitted within 14 calendar days after the start of the services — late applications are systematically refused.
More details in the attached document
Brussels
What Peppol Service Providers are entitled to : up to 70% of consultancy costs, max €10,000 per year
Digitalisation Grant (Prime Digitalisation): base rate 25%, up to 70% depending on starter status and/or recognised environmental or social exemplarity; capped at €10,000 per calendar year; minimum €500 per assignment, maximum 2 assignments per year (max 6 months each). Covers external consultancy (gap analysis, ISMS, security policies), vulnerability audits and mock/pre-audits.
Brussels Training Grant (separate scheme): 40%–80%, up to 10 training courses and €20,000 per calendar year (max €5,000 eligible expenditure per course).
Key conditions: SME with an operating establishment in the Brussels-Capital Region; eligible NACE-BEL sector; responsible digital charter to be signed; approved provider required; certification body fees (Stage 1 & 2 audits) are a grey area — to be confirmed with Brussels Economy and Employment; apply before the start of the assignment.
More details in the attached document
Wallonia
What Peppol Service Providers are entitled to : up to 75% of consultancy costs (the most generous scheme in Belgium)
Cybersecurity Voucher (Chèque Cybersécurité): 75% of consultancy fees (excl. VAT), capped at €60,000 over 3 years — covers risk analysis, cybersecurity policy definition, ISMS implementation support and labelling audits (Keep It Secure / ISO 27001).
Digital Maturity Voucher: 50%, capped at €50,000 over 3 years — digital maturity assessment and implementation plan (note: no accredited providers are currently listed for this scheme).
Digital Training Voucher: 50% — staff training in cybersecurity, including ISO 27001 Lead Implementer / Lead Auditor.
Vouchers can be combined on separate assignments.
Practical advantages: the service provider handles the entire administrative file, and the SP only finances its own share — no pre-financing and reimbursement.
Key conditions: SME or self-employed with main operating establishment in Wallonia (if multi-site: > 50% of FTE in Wallonia); SPW-accredited provider required; the auditor/certification body fee is not covered; non-profits excluded; apply before the start of the assignment.
More details in the attached document
Work in Progress
BPA ref: EINVC-995
Self-Billing
Topic Owner
FPS FINANCE
Other Focus Group participants
DW SOFT, WOLTERS KLUWER
Abstract
Self-Billing is a new specification on the Peppol network, introduced in the context of the Belgian mandate. As any new specification, in order to ensure that it is consistently used and does not cause friction with BIS BILLING, specific action may be required in terms of communication, clarification, coordination, governance and/or at technical level.
Report Back to Plenary
The group broke the topic down into 4 issues:
1 - Lack of awareness that the supplier must register to receive self-bills 2 - Lack of awareness that a bilateral agreement remains necessary 3 - Status reports for self-billing are reportedly not possible 4 - End-user software does not yet support self-billing (to create or process)
Issues 1 and 2 require communication with end-users representatives, via the Business Experts Group (BEG). This has been executed. See also update of the FAQ Is self-billing authorised?
Issue 3 is handled through an RFC – Dirk initiated it – see annex 3. [?WOLTERSKLUWER TO ADD UPDATE?]
Issue 4 is handled through various channels: (1°) call at next SP forum (2°) broadcast to end-user tools notified on website e-invoice.belgium.be; (3°) call at the BEG. This has been executed. An informative e-mail has been sent to end-user tools the 18th of June.
BPA REF EINVC-1083
Dual sending
Topic Owner
DIGITEAL (Cédric)
Other Focus Group participants
40 members of the Forum participated to the FG
Abstract
Some service providers default to sending documents (invoices, credit notes,...) both via Peppol (mandatory) and via email (optional). The issue is that well-organized receivers then process this through both channels leading to double processing. This dual processing incurs costs. DIGITEAL suggested addressing this problem by gathering the expertise of Service Providers in a short-lived focus group to reach a common recommendation.
Recommendation
Following the meeting of 15/06/2026 with about 40 Peppol service providers, the recommendation for sending messages is as follows:
“Dual sending should be avoided. If the recipient can receive it via Peppol, messages should be sent exclusively via Peppol.”
This is a recommendation. Dual sending is not prohibited. SPs may still send copies via other channels even though it is not recommended. ERP systems or invoice issuers can also do this without the Peppol Service Provider handling it.
A consensus on this matter was quickly reached.
The receommendation of the focus group was endorsed by the forum in th eplenary meeting 41, on Sep 8, 2026 .
As proposed by th efocus group, the recommendation was discussed at the PAC meeting 127 on Sep 10, 2026 , proposing to other PAs to relay this recommendation in their own jurisdictions.
BPA REF EINVC- 1263
Backlog
Topic
Comment
BOSA Ref
Topic
Comment
BOSA Ref
GT&Cs
EINVC-1177
Problematic registration of end users
EINVC-1080
Peppol Reporting
EINVC-1007
handling delivery troubles (MLx)
EINVC-1004
KYC (automation)
EINVC-1002
SBDH Country
EINVC-1001
B2C
EINVC-999
CTC
EINVC-998
inventorize SP sending and receiving capabilities (?)
EINVC-996
ISO certification
EINVC-995
Archives
Hermes Access Point Whitelisting - Testplan [archived Dec 17, 2025 ]
Hermes is phased out - only the web portal is maintained live for a timeframe allowing end-users and receivers to check their invoices for several extra months see Hermes | BOSA
Preamble Hermes (hrms) offers the possibility to Service Providers operating a Peppol Access Point (AP), to integrate hrms into their outbound invoicing services. This testplan lets the AP check the behavior of hrms in the different scenarios. APs can familiarize themselves with hrms, including instances when sent invoices fail hrms validations . This testplan is designed to require minimal input, effort and time from the AP. The complete execution takes less than 1 hour. BOSA advises to agree on a joint schedule, but this is up to the AP to decide. 1. Description of the test session The test consists of the following steps. (More details below in section 2) Kick-off
BOSA and AP meet and greet, agree on the setup and exchange the information required to execute the set of round and launch the tests. Initial round
This test set validates the behavior of hrms when the AP is not yet registered on the whitelist. Main round
This test set validates the behavior of hrms when the AP is registered on the whitelist and no email address is recorded. Final round (optional)
This test set validates the behavior of hrms when the AP is registered on the whitelist and a central email address is recorded. Wrap up
BOSA and AP share their findings, observations and conclusions. They sign off the results. This closes the session. 2. More details There are only 2 details worth noting: (a) what information must be exchanged at kick-off and (b) what is the sequence of each test round. (a) what information must be exhanged at kick-off? The AP must provide the following information to BOSA: enterprise number of a sender for which the AP registered MLR Receiving Capabilities email address (4.. Final round) : if the AP wishes to test the scenario where hrms returns negtive feedback by email to a centralized email address : BOSA will hand over the set of (9) invoices (xml’s) to be used through the different runs - tuned to the AP’s context. These 9 xmls cover the different cases that need to be checked. For info, please find here a zip file containing the 9 sample reference xml invoices.
[NB: if, exceptionally, the enterprise communicated by the AP is registered in the hrms senders list, BOSA will remove it for the sake of the test] (b) what is the sequence of each test round? Each round only takes 2 simple steps: AP sends the 9 invoice and informs BOSA once the set is duly sent. BOSA (a) tracks the outcome of each invoice sent (based on the ID of each invoice), (b) modifies the hrms configuration for the next round, and (c) gives the GO to the AP to move to next round. Conclusion The testplan is designed to require minimal input, effort and time from the AP. This is the opportunity for the AP to get first hand, in only a few minutes, a glimpse of the workings of hrms. BOSA invites all APs to take this opportunity.
CBE Identification scheme ID migration (9956>0208) [archived Dec 31, 2022 ]
scheme ID 9956 is deprecated since 2022.
Status Introduction of schemeID 0208 completed : initiated with Peppol BIS schematron summer 2020 release completed at the initiation of the schemeID 9956 removal Removal of schemeID 9956 : Deprecation initiated with the BIS schematron spring 2021 release and completed with the BIS schematron fall 2021 release Removal : scheduled History Background In an initial phase of the use of Peppol, the Belgian enterprise number has been assigned a Peppol schemeID in 2016 (9956). The introduction of the EN 16931 caused the need to replace schemeID 9956 by an ICD-compliant new schemeID. FPS Economy, owner of the enterprise number, proceeded with the due registration of the enterprise number. ICD 0208 was assigned in april 2020, and recorded in EAS in june 2020. Consequently the migration of 9956 to 0208 introduction was necessary. It was coordinated in the present section. Timeline Additional Coordination notes Due to the remaining use of the old BIS (2.0) MLR (aka. "MLRv1") at end of the migration , schemeID 9956 removal could not be scheduled. Deprecation of old BIS MLR was not possible until BIS IMR was duly introduced in B2G invoicing. Use of BIS IMR to return B2G invoice responses was introduced in March 2022; use of old BIS MLR to return B2G invoice responses was interrupted in September 2022. -> schemeID 9956 removal discussions are reprogrammed on the SP forum. At forum it was decided that the minimal scenario will be complemented with regular monitoring by BOSA (see below : share periodic progression data). Progress on the 3 stages will be monitored on the basis of a questionnaire that will be sent out on a monthly basis. The 3 identified stages are : Stage 1 : Stop registering new participants under scheme ID 9956. Stage 2 : Finish migrating 100% of portfolio from scheme ID 9956 to scheme ID 0208. Stage 3 : Exclusive use of Scheme ID 0208 for all existing and new participants. At forum there was no clear preference for any migration support discipline. Consequently the only official migration scenario is the minimal one, where each SP is solely responsible of meeting the schedule and the possible negative impact of missing milestone B. BE PA will nevertheless reassess options and at least gather and share periodic progression data.
Decommissioning old BIS Billing (2.0) [archived Jun 28, 2020 ]
decommissioning of old BIS billing (2.0) was made complete by Jun 28, 2020 thanks to the hereby described enforcement action - incl. old BIS decommissioning enforcement on smp.belgium.be
Since smp.belgium.be throws a BELMA-306 error code upon attempt to register a non-BIS (3.0) document type prior to registering the equivalent BIS. The Belgian Government took measures to phase out all non-BIS (3.0) traffic reaching it. old BIS (2.0) BILLING receiving capability of Government entities was removed (a) from the test environment on and (b) from production on . NB: Although this is not supposed to happen, technically speaking, smp.belgium.be does not reject new registration based on old BIS (2.0), provided that BIS (3.0) equivalent receiving capability is already registered, no explicit cleanup of old BIS-based receiving capabilities has been executed yet on smp.belgium.be . Until the removal of the related identifier is decided, it is the responsibility of each service provider to duly assist their end users in properly de-registering deprecated receiving capabilities.
Hsmp migration token collection interface [archived Dec 17, 2025 ]
Hermes is phased out - only the web portal is maintained live for a timeframe allowing end-users and receivers to check their invoices for several extra months see Hermes | BOSA
Abstract As a result of the Hermes initiative, all active Belgian enterprises are registered on Peppol. 98% of them are registered on HermeSMP and ready for migration onto another solution ( + smp). No Belgian enterprise can be registered “from scratch” anymore. In order to speed up the migration of Belgian enterprises out of Hermes (hrms) towards a suitable e-invoicing tool, BOSA decided to (1) initiate migration for all hrms participants and (2) let HermeSMP (hsmp) expose a (secure) Migration Token Collection Interface (mtci). The interface specifications were submitted to a review round to the Belgian SP/AP forum members in June 2020. The first stable version of the specs were posted below on . The interface is ready for tests as of The testing window closed on . No specific bug were reported during the testing window. Consequently, BOSA has initiated the acceptance and go-live phase of hsmp mtci. The specs and other useful documentation are maintained below. Specifications Swagger: compliant with the applicable standards, this API is subject to one single and comprehensive, machine- and human-readable specification file: hsmp_migration_key.yaml
NB: human-readable rendering can be made more convenient by using specific editors, such as Test Plan: compliant with applicable standards, the following resource is made available to enable any (future or current) API-user to perform local tests during its development cyccle: HSMP_migration_key.postman_collection.json (Postman) NB: above specifications include all possible cases/scenarios, including exceptions/errors. Additionally, during the API development cycle the list of response codes was gradually elaborated and discussed using the table 1 below. This information is still available for tracking purposes only. Online User-Testing data - practical aspects The API is available in a test environment to support online user-tests at the end of the user development cycle. This section explains how online tests are organized. how does it work We prepared 20 datasets. Each tester gets his own dataset so he can perform his own test without risk of clash with any other tester. Upon request to BOSA, each tester will get an own test dataset assigned. Test data will be recycled daily. Below you find a matching of the test data with the scenarios to be tested. matching test data - test scenario: (a) Preamble: each dataset is subdivided in types of participants, each participant of a given type is suitable for a given test scenario. bullet (b) below lists the types , and bullet (c) below lists the matching of the types with the datasets (b) Types of participants:
Type 1: Participants registered in HSMP but not registered in SMK. These are not valid KBO enterprises and therefore cannot be used to migrate to Belgium SMP. (Can be used for load testing, black listing...)
Type 2: Participants flagged as migrated in HSMP but not registered in SMK.
Type 3: Participants flagged as deleted in HSMP but not registered in SMK.
Type 4: Invalid participants.
Type 5: Participants registered in HSMP and in SMK. These are valid KBO enterprises and therefore can be used to migrate to Belgium SMP. (c) Matching with test cases (cf Postman documentation)
Case 2.1 : Type 1, Type 5
Case 2.2 : Any
Case 2.3 : Type 4
Case 2.4 : Type 1, Type 5
Case 2.5 : Type 4
Case 2.6 : Type 2
Case 2.7 : Type 3
Case 2.8 : Type 1, Type 5 Case 3.1 : Type 1, Type 5
Case 3.2 : Type 4
Case 3.3 : Type 2
Case 3.4 : Type 4
Case 3.5 : Any Case 4.1 : Type 5
Case 4.2 : Type 5 Blacklisting : Type 1
Additional information: https://documenter.getpostman.com/view/11381713/T17FCUqp?version=latest Blacklisting: This service allows a maximum of 1000 collections per day. The system will blacklist any user exceeding this level. The affected user will have to contact BOSA (service owner) to request reactivation. As an alternative, the user planning to exceed 1000 collections a day, can contact BOSA to schedule the operation. He will then be temporarily authorized to exceed the limit mentioned above. Schedule and progress: see table 2 below. Version history This section will track the publication of updates of the documentation. Initial draft published for review purpose. First stable version published along with initiation of development work. ready for acceptance testing. Resources HSMP_migration_key.postman_collection.json, hsmp_migration_key.yaml and https://documenter.getpostman.com/view/11381713/T17FCUqp?version=latest updated. Overview error codes added. planning updated. (1°) Testing phase schedule adapted. (2°) Test datasets descriptions posted and practical details info updated (in line with our discussions on and the availability of one dataset per tester). publication of test results and move to acceptance / go-live phase. Table 1 - Responses Scenario Request Response : http response code - detailed response positive valid and not yet migrated enterprise number 200 - OK - the pair enterprise number & migration token security 1 certificate missing 401 - HSMP-802: no certificate supplied with the request security 2 error while parsing certificate 401 - HSMP-803: error while parsing client certificate security 3 certificate expired or not yet valid 401 - HSMP-804: client certificate expired or not yet valid security 4 added : not trusted 401 - HSMP-805 :Certificate cannot be trusted by Peppol trustStore security 5 added : Test/Prod mismatch 401 - HSMP-806 : Certificate environment does not match with requested environment (test or prod) security 6 added : not a Peppol AP 401 - HSMP-808: Certificate is not a Peppol ACCESS POINT certificate error 1 the enterprise number does not correspond to an existing enterprise (or is garbage) 404 - HSMP-001: invalid or non-existing enterprise number + id error 2 the enterprise number was deleted (in the context of the monthly processing of the CBE dump or the admin removal function) 404 - HSMP-012: inactive enterprise number + id error 3 the enterprise number that was already migrated to another smp 404 - HSMP-013: already migrated + id error 4 any request of a user that exceeded the blacklisting limit and was not yet reactivated 403 - you have been blacklisted please contact BOSA error 5 added : any request of a user that broke a network global limit, and was not yet reactivated 403 - HSMP-812 : Global limit reached. Please contact BOSA error 6 added : any request of a user that broke an IP-specific limit, and was not yet reactivated 403 - HSMP-813 : Limit reached for IP. Please contact BOSA error z internal server error 500 - HSMP-999: The service encountered an internal error Table 2-Schedule and progress Phase Timing Description status / comment Design JUNE AP forum: discuss the interface specifications, practicalities then post a draft proposal to collect comments (2weeks) then publish (initial) documentation package ( swagger + Test plan + read-me ) and schedule on agreed repository DONE: initiated → open for comments until → review closed → first stable version of specs published Development and Tradeshift test JULY - AUGUST Includes update of the documentation package at end of dev phase. DONE User testing SEPTEMBER Includes collection of test results, fixing, updating the documentation package and teh code if needed Sub phase 1: early bird testing with close support by Tradeshift : - Sub phase 2: wide-scale testing with any volunteer with BOSA support (Tradeshift in L2): - DONE - results summary available in table 3 below BOSA acceptance OCTOBER Verify that the outcomes of the previous phases meet the expectations. DONE - validation based on user testing results Table 3 - Summary of testing phase results Abstract: All SPs ave been given the opportunity to test hsmp mtci. at , 6 datasets were distributed. Positive test results were received from 4 testers. No negative feedback was received. Dataset ID SP Feedbacks? supporting evidence 1 BILLIT OK 2.10 I did some basic tests and was able to migrate an active participant and register it to Belgium SMP and then register it for the wanted DocumentTypes.
This all went very smooth.
I also tested some of the other paths and everything seems in order with the documentation.
These tests were not very extensive, I was not yet able to test the all the cases and was not yet able to do some load tests. 2 IXOR OK 23.9 I ran the collection file once per type. At first sight everything seems to be ok.
Please find in attachment the exported results from postman runner.
Mathieu's reaction: I am glad that your first tests were successful.
Did you get a chance to perform a second round of testing? Do you need any help or clarification from us? Don't hesitate to call me if you have any questions. 3 Inaras via Wim Maerevoet 23.9 No information upon start. No feedback on tests. 4 codabox Started 6.10 - question raised, ticket open at TS, answer given We started the testing and noticed there is a connection issue with the Hermes SMP. Could you confirm we can start using the Hermes SMP with our Peppol AP certificates for the test network?
When we try to reach the smp-test.belgium.be with the certificates everything if working as expected, but when trying to reach spm.acc-hermes-belgium.be we receive no response (see attached image).
Could you have a look what happened and how we should connect?
answer from Tradeshift: The root cause of the issue is simply the TLS certificate that is not the final one for smp.acc-hermes-belgium.be (fyi, was misspell in the support request) .
Is it possible to simply ignore the TLS error for the moment until we have the proper certificate in place? 5 via Walter Vander Goten(7.10) No information upon start. No feedback on tests. 6 netropolix via Jeroen Cuppens (12.10), feedback 12.10 Thanks for the test dataset.
Since we only have a small amount of customers using Peppol, we currently do all registrations with Postman.
So we were able to do all required testing by using the provided Postman collection of the confluence page.
All API calls worked as expected. 7 B2B Router via Oriol Bausà Peris (13.10) No information upon start. No feedback on tests.
Hermes agreement framework [archived Dec 17, 2025 ]
Hermes is phased out - only the web portal is maintained live for a timeframe allowing end-users and receivers to check their invoices for several extra months see Hermes | BOSA
Hermes helps leveraging B2G e-invoicing adoption on B2B e-invoicing adoption in Belgium. It makes it possible to Belgian Peppol invoice senders, to reach all their Belgian customers on Peppol. For juridical reasons, its use requires a specific agreement between the sender and the Belgian government (represented by BOSA), in addition to the Peppol agreements. Service providers are invited to support this and integrate Hermes in their service offering. Access to Hermes is free of charge for the Service Provider. BOSA designed agreements that fulfill these purposes. The Belgian SP/AP forum members reviewed the initial agreements (minimal viable product) in June 2020, and the updated agreement (improved version) in Q3 2022. In this latest version, the agreement as such provides the terms and conditions that specifically apply to the integrator, while other terms and conditions are listed in annexes listed at the end of the agreement. It is the case of (a) generic terms and conditions, (b) terms and conditions that apply to the sender, in his quality of user of Hermes, and the receiver in his quality of end-user (ultimate beneficiary) of Hermes, and (c) technical, functional and security guidelines. The Hermes integrator agreement template can be found at the following address: French : Hermes - Convention Intégrateur (belgium.be) Dutch: Hermes - Integrateur Overeenkomst (belgium.be)
Answers to questions posted by SPs during 8th edition of the forum (23/06/2020) [archived Dec 17, 2025 ]
Hermes is phased out - only the web portal is maintained live for a timeframe allowing end-users and receivers to check their invoices for several extra months see Hermes | BOSA
Question Answer Will we be informed when Babelway is ready and when we can start testing ? Will we get an update on the interface spec? Yes. BOSA will keep using the BE AP forum page to publish updates in the documentation and project progress, and members will be informed by email. An update will be published soon. This update closes the design phase: the specifications are considered stable enough to move to development. Do sender and AP need to sign agreement or is one enough? The SP needs to sign the integrator’s agreement. The sender needs to sign the sender’s agreement. However, to accommodate the SP’s processes, the formalism is up to the AP, as long as it can be audited that the sender has indeed formally agreed the convention. It does not necessarily need to be a “good old written signature on paper”, but it must be opposable and auditable. The agreement should be signed with all the Service Providers in Peppol, not only with Belgian ones, isn't it? The Belgian restriction applies to senders and receivers, not to SPs. At this stage the convention is only available in the official Belgian languages but foreign APs operating in Belgium can sign it. Was the Hermes proposed process submitted to approval of OpenPeppol ? Of course OpenPeppol is informed in detail about the Hermes project. The receivers are then in Peppol, and reachable from Peppol everywhere. Michel's point on mixing the reliable Peppol delivery with the mail is really relevant. It is not only about what is relevant, but also about what is the most relevant. Indeed emails are less reliable but today the sender has no choice anyway. By reconciling both models (as much as possible), we expect to boost the uptake of end-to-end e-invoicing, opening a boulevard for the industry. The risk of losing a few invoices in the process, a risk which exists today anyway, is really minor compared to the benefits. Why does the HermeSmp not register all the Belgian entities with a customized version of the bis3 invoice that has a mandatory email address? This would resolve the issue of enforcing it no? As answered by another forum participant, BIS is mandatory. Hence, even if you register the Hermes receiver with this customized format they still have to receive the BIS V3. See also Hermes - ...- clarification, point “email address” If there is a change in the behaviour of Peppol, my understanding is that it should be approved by the impacted parties. As an AP, I request this to be put to a formal approval There is no such change I support Michel that having a standard and efficient way to differentiate receivers in Peppol lookup/directory that are reachable via BIS3 via Peppol to pdf via email delivery from the standard einvoice receivers in Peppol. This maybe achieved by a national process/profile etc. It is very easy to differentiate a Hermes receiver from others: the Hermes receivers are not published on Peppol Directory. In other words, any Belgian enterprise (identified by his enterprise number) that is not on the Peppol Directory, is a Hermes receiver.
Another way to look up this information, that is cleaner from a technical perspective (but may be harder for a lambda user), is to query hsmp directly.
Hermes – possible confusion with some Peppol principles – clarification (published 15/06/2020) [archived Dec 17, 2025 ]
Hermes is phased out - only the web portal is maintained live for a timeframe allowing end-users and receivers to check their invoices for several extra months see Hermes | BOSA
Context With Hermes, BOSA SD implements the mandate formulated by the Minister of Digital Agenda in his policy note 2018, in respect of the solution described in the tender “BOSA 2018/M1087”, also approved by the Minister. The policy goal is to help the suppliers to get a faster payback for their initial efforts to comply with Government requirement to use Peppol. The proposed solution is to (a) publish Peppol BIS Billing receiving capabilities for all Belgian enterprises (except the ones already publishing such capabilities), and (b) build a system that converts Peppol BIS invoices into equivalent PDF and forwards these by email to the receiver. This brings all Belgian enterprises within the reach of the Peppol senders - and their service providers. In addition to the pay-back effect for the senders, the use of Hermes offers 4 strategic advantages: It reduces the friction between the senders and the receivers. By converting Peppol BIS into PDF, Hermes gives more freedom to each party in the management of his e-invoicing transformation. For senders, it removes the need to maintain multiple channels (at least for domestic traffic). It provides a communication channel to Belgian enterprises: in addition to the invoice, the email sent by Hermes also provides information to the enterprises about the available solutions on the market, thereby speeding up the adoption. Moreover, the enterprises receive the information along with the invoices. This is the moment where they are supposed to be most sensibilized. It generates a significant growth of the volume of invoices that can be processed automatically. This will turn into a better/broader sharing of the costs of technology and boost the development of new tools. Consequently, it will help the IT sector to grow, and the Belgian enterprises to find suitable solutions at affordable prices. It will also benefit to B2G adoption: Directive 2014/55 obliges the public sector to receive e-Invoices, but it doesn’t oblige the private sector to send them. This creates a risk that the public sector does not receive sufficient invoices to compensate the investments made to meet the obligation. Hermes provides an additional motivation to the senders, and thus reduces the risk described above. Hermes is only a temporary solution. In the Peppol terminology, all Hermes receivers are ready to migrate from day one. As soon as such receiver finds a suitable and affordable tool to automate the inbound invoice processing, he/she migrates onto it. Once a sufficient adoption of interoperable e-invoicing is achieved, Hermes will retire. The sooner the better. Purpose of this paper To use Hermes, Peppol senders must meet three conditions: (1°) be a Belgian enterprise, (2°) accept the conditions of use of Hermes and (3°) communicate the email address of their client. The degree of alignment of some of these conditions with the Peppol principles, seems to cause confusion to some stakeholders. The purpose of the present paper is to clarify how these conditions relate to the Peppol specifications. Be a Belgian enterprise BOSA SD is a Belgian Federal public service. It can only provide service to Belgian enterprises. Consequently Hermes can only handle invoices sent by Belgian enterprises. If Hermes would also handle invoices sent by foreign enterprises, it would clearly fall outside the scope of action of BOSA. BOSA cannot afford to take this risk. This condition does not seem to be the subject of a discussion, hence it does not require any additional clarification. Accept conditions of use Description Hermes is an intermediate component between the sender and the receiver. It cannot operate without a clear mandate from one of the two parties. Obviously it is not feasible to receive such a mandate from every Belgian enterprise. Therefore it must be mandated by the sender. Clarification In the first place, this formality is not related to Peppol. No entity, private nor public, can act as an intermediate without having an agreement with at least one of the parties. It is also needed to clearly delineate the boundaries of the service, such as the domestic coverage (previous condition). Therefore, in the current design of Hermes, this aspect is handled outside of any Peppol-related consideration, before even considering Peppol. Peppol comes into play in many other aspects of Hermes, but not in this one. More specifically, Hermes must not be confused with a receiving Access Point (C3). It is situated in the business layer (C1 – C4). In C1, Hermes offers a solution to the sender to capitalize on their existing interoperable outbound invoicing systems. In C4, it is a gateway that takes care of the last mile, after the Peppol transmission. It is based on a non-ambiguous identification of the suppliers and customers coming from the authoritative source of Belgian enterprises. Such a construction indeed is difficult to map in the Peppol model. The Hermes reasoning supersedes the Peppol reasoning, it does not contradict it. Email address Description By design, all invoices sent to Hermes must be converted to human readable format and forwarded by email to the final destination. Therefore the correct email address of the receiver is required. As this email address can depend on many factors (even for the same receiver), the supplier (sender of the invoice) must provide the correct address. The only other way to handle this need would be to store a suitable email address for every Belgian company in the Hermes configuration data. During design, this option was judged excessively complex and disproportionate. Clarification Requiring extra information on top of the BIS is not uncommon. Most if not all invoices exchanged over Peppol contain information that is not mandatory but nevertheless indispensable in the specific business scenario of the invoice. For instance, the Flemish government requires a Purchase Order number. The need for an email address is considered to be proportional to the scenario addressed by Hermes. Conclusion On the basis of the political mandate, the legal checks and the clarifications above, BOSA is confident that the Hermes construction cannot reasonably be judged to be in contradiction with the Peppol principles. On the contrary, deep down the fundamental principles of Peppol we can find the core principle of inclusiveness. Hermes increases alignment of Peppol with this core principle. Additionally, BOSA explores possibilities to improve the alignment between Peppol and Hermes. The most likely option would be to define a national use case. This is the subject of an upcoming effort and is driven by additional factors and constraints.
Hermes documents review round 202006 [archived Jun 30, 2020 ]
Abstract This section shares information with the Belgian Service providers about Hermes in the context of a draft review round. Timewise, this round started with a presentation during the 7th Belgian AP forum on . closes on . Review participants are invited to provide their comments by email to peppol@bosa.fgov.be. Following documents are in the scope of this review round: the conditions of use for senders and its technico-functional annex, the integrators agreement, the migration token collection interface specification. Documents title abstract link 1.a. Hermes conditions of use Contractual description of the Hermes service features and boundaries.
The enterprise wishing to use Hermes in his outbound invoicing must accept these conditions NL: Hermes Gebruiksvoorwaarden FR: Hermes conditions d’utilisation 1.b. annex to Hermes conditions of use The conditions of use incorporate a technico-functional appendix that lays out in more detail all the scenarios handled by Hermes and their technical details NL: Hermes Gebruiksvoorwaarden bijlage FR: Hermes conditions d’utilisation annexe Hermes Integrators agreement In addition to the convention of use, DT offers the possibility to integrators to incorporate Hermes in their service offering, and the collection of the senders' agreement with the conditions of use in their own service subscription process. For this the integrator must sign a convention of integration, that describes the responsibilities that the integrator is expected to take to insure smooth operations NL: Hermes overeenkomst integrator FR: Hermes convention intégrateur HermeSMP (hsmp) migration token collection interface offers the Peppol APs the possibility to automate the collection of the Hermes participants migration tokens. It is a REST service with the same security as smp.belgium.be. This interface specification consists in (a) a swagger; (b) a Test Plan , and (c) additional info if needed (a) swagger: hsmp_migration_key.yaml
(b) Test plan: see test plan section
(c) additional info: see additional info section (hsmp) migration token collection interface - Test Plan Introduction Currently only the Table of Contents of the text plan is available. However ,once it is reviewed, the Test plan will be elaborated and packaged as a Postman Project that suits for the testing of the interface. The graphical representation of the high-level description is also provided. notice however that an inconsistency was found when comparing the TOC and the viusal - the error 3 seems to overlap hsmp801. This is under investigation High-Level Description / “table of contents” scenario request response :: http - detail positive valid and not yet migrated enterprise number 200 - the pair enterprise number & migration token security 1 certificate missing 401 - no certificate provided with the request security 2 error while parsing certificate 401 - error while parsing client certificate security 3 certificate expired or not yet valid 401 - client certificate expired or not yet valid error 1 the enterprise number does not correspond to an existing enterprise (or is garbage) 404 - invalid or non-existing enterprise number + id error 2 the enterprise number was deleted (in the context of the monthly processing of the CBE dump or the admin removal function) 404 - inactive enterprise number + id error 3 the enterprise number that was already migrated to another smp 404 - already migrated + id error 4 any request of a used that exceeded the blacklisting limit and was not yet reactivated 429 403 - you have been blacklisted please contact BOSA error 5 internal server error 500 - internal server error Visual (hsmp) migration token collection interface - Additional info Proposed schedule Phase Time What Design JUNE AP forum: discuss the interface specifications, practicalities. Then post a draft proposal to collect comments (2 weeks). Then publish (initial) documentation package ( swagger + Test plan + read-me ) and schedule on agreed repository. Development and Babelway test JULY Includes update of the documentation package at end of dev phase. User testing AUGUST Includes collection of test results, fixing, updating the documentation package. BOSA acceptance SEPTEMBER Verify that the outcomes of the previous phases meet the expectations. Currently, no need for such an additional piece of documentation is identified. During the specifications review round, review participants are invited to describe the additional documentation they would need, if any.
Multiple Receivers under one CBE [archived May 12, 2026 ]
Lead: EXACT (Remko)
Conclusion
During Plenary 40 the Forum endorsed the proposal of the Focus Group (FG) to close this topic. Investigating this scenario, the FG came to the conclusion that the Belgian PASR Rule over the use of identifiers leaves sufficient room to the market to address the scenario. The PASR Rule states that each Belgian Participant must be able to use their Enterprise Number (SchemeID 0208). In other words, the Enterprise Number (Legal Identifier of enterprises registered in Belgium) is the primary ID. Participants who have particular needs are free to use one or several secondary IDs to meet this needs, provided that this does not affect the capacity of other participants to identify them with their primary ID. For example, a participant that wants to keep using one or several other IDs for internal routing purposes because he has done so for years in the past, is free to do this, but he has to make sure that that the other parties/participants agree and are capable to use these secondary IDs. It is his responsibility to ensure this, and not the responsibility of the other parties/participants.
