This article is for representatives of the private sector, in charge of sending invoices to belgian governmental entities, or involved in such duties. For instance, billing officers, IT teams supporting financial departments, external IT service providers and/or software supplier, or any other kind of people interested by outbound e-invoicing.
As explained in e-invoicing strategy of the Belgian public sector, the Mercurius platform fulfills the role of central electronic mailroom for the Belgian public sector in the context of B2G e-invoicing.
This article goes one step further by focusing on the different parts of the Mercurius platform seen from the 'private sector' point of view as sender of the e-invoices.
It addresses the main elements that such stakeholders have to be aware of (such as general description, main flows, on boarding procedures...). Uncommon scenarios are explained in detail in separate articles. Also, topics that are common with the public sector, are explained in separate articles (example: Mercurius portal help). References to these related articles and other relevant information are mentioned in this article, at appropriate places...
This article consists of following paragraphs:
Council Directive 2010/45/EU of 13 July 2010 amending Directive 2006/112/EC on the common system of value added tax as regards the rules on invoicing, made electronic invoice equivalent to the paper invoice. These directives were translated in Belgian law. for more info, see following pages: FR - NL. This created the conditions for the wider adoption of e-invoicing.
Directive 2014/55/EU of April 16th, 2014, obliges all European Public sector entities to accept and process electronic invoices that comply with the European Norm EN16931. The translation in Belgian law is in process.
Additionally, Belgian federal and regional councils of ministers already decided to mandate B2G e-invoicing. These decisions are progressively transposed into legal, technical and promotional actions by their respective administrations.
Mercurius is the result of several of these actions. As explained earlier, this centralized electronic mailroom for the public sector, makes it considerably easier for the private sector to reach all their public sector customers consistently and cost-effectively.
The solution of the Belgian Public sector to collect e-invoices from their suppliers, which is based on PEPPOL and Mercurius, was designed to minimize the long-term costs for the senders. In the short term, it is not impossible that senders will face costs due to the lack of competitiveness on the market of solutions, or due to wastes caused by maturity issues rather than real and incompressible costs. Following aspects need to be taken into account:
A Belgian e-Invoicing Experts Group was founded in June 2017. It addresses questions such as "how should an invoice with cash discount be expressed in the BIS format", "what makes an invoice number unique", "how to cope with the multiplicity of identification schemes"... It is a meeting point across various groups, each group having its own perspective and concerns. The confrontation of these view points in a constructive mindset, accelerates the generalization of e-Invoicing.
Business Experts from all horizons of the Belgian invoicing landscape, supported by technical experts, participate in this joint effort. The Federation of Enterprises of Belgium provides the facilities needed by the group (logistic support, extranet, moderation....).
info
Extranet of the Belgian e-Invoicing Business Experts Group (members-only): https://extranet.vbo-feb.be/SitePages/Home.aspx
The article The life cycle of an e-invoice to the Belgian public sector explains the flow and processing of an e-invoice. This section details this description from a private sector (business) view. (* ) It (a) explains data flows connected to exchange services regarding e-invoices and components necessary to make the flow operational, (b) introduces a technical point of view on these components and (c) situates the decisive role of a network of service providers, access points and software editors acting in this context. The major flows are (1) sending an e-invoice (or e-creditnote) and (2) receiving an answer.
(* ) Detailed information on specific aspects concerning public sector can be found at Mercurius for the public sector.
Flow and components | Steps |
Legend: | Preamble: supplier generates an outgoing invoice in his own software solution. Steps:
Remarks: 1a: the supplier not able to send his e-invoice through PEPPOL, can create this invoice through the new invoice form on the Mercurius portal (as long as the invoice is reasonably simple) 1b: the supplier already connected during the pilot phase and not already able to send his e-invoice through PEPPOL, can send his invoice through the pilot interface (temporarily still in place) 3b: the customer is not yet able to collect e-invoices. In this particular case, Mercurius converts the e-invoice in a pdf document and sends it to the customer's address, registered in its configuration. |
Flow and components | Steps |
Preamble: the customer has accepted (or rejected) the invoice in his own administratif system - see also Step 5: the customer processes the invoice. Steps:
Result: response was received by the supplier. Remarks: 3a: not every supplier having send and e-invoice through PEPPOL is capable of also getting the response on the PEPPOL network. In this particular case, Mercurius will send the response by e-mail as described in Step 7: Mercurius sends the response to the supplier. 3b/4b: the supplier on-boarded during the pilot phase, can still receive the responses through this pilot interface (still available only for a limited time). |
Previous section shows the flow of e-documents between correspondents. The present section provides useful explanation about the format requirements that apply to these e-documents. It is very important to be aware, in sufficient details, of how formats affect the exchanges between correspondents.
Typically, electronic document exchange require that the sender and the receiver agree on an exchange format - for each type of document, subject to the exchange. This is a sinequanone condition for the IT systems of both correspondents to understand each other "loud and clear", and be able to work together seamlessly.
A format underlies two basic aspects: (a) semantics: the document is composed of information elements that are described in such a way that excludes interpretation errors; (b) syntactic: these common information elements are translated into a syntax, a data representation, that an IT system can "read" / "write".
In 2011, a limited but representative set of actors coming from different horizons, decided to hold several workshops with the purpose to deliver a set of cross-sector and cross-border formats for most of the procurement documents (catalogue, order, order response, dispatch advice, invoice, credit note...). The CEN BII workshops delivered the CEN Business Interoperability Interface (BII) WorkGroup Agreements (WGA), containing the CEN BII formats.
In the meantime, the CEN BII series were reused by many practical eProcurement solutions, especially (a) the ePRIOR platform developed by the European Commission and (b) the PEPPOL Business Interoperability Specification (BIS). The PEPPOL BIS fulfills the 'common denominator format' role, meaning that if two correspondents fail to identify a common format to exchange documents, then they "fall back" to the use of the PEPPOL BIS.
During a pilot phase (2013-14) reusing the ePRIOR platform, tailored to the Belgian context, the Belgian public sector validated that CEN BII Invoice and Credit Note document types, covered all their specific information needs.
When adopting the PEPPOL interoperability framework, no specific business needs justified the support of any format other than the common denominator format - the BIS.
Although the BIS is not the most sophisticated format available, it is extremely well documented and supported by validation tools. These ancillary products definitely contribute to the quality of exchanges.
For all these reasons, the Belgian public sector decided to support only the BIS invoice and credit note formats, for the time being.
Of course, due to the Directive 2014/55/EU, the Belgian public sector will upgrade their systems to also support the European Norm EN16931 in the near future. Notice that EN 16931 requirements include the necessity to be well aligned with CEN BII. In other words, the EN 16931 design integrates the migration from CEN BII Invoice.
As introduced in the preamble above, the Belgian public sector supports the following formats: PEPPOL BIS Invoice and PEPPOL BIS Credit Note. The following table summarizes the technical information required to prepare documents in a way that guarantees that the Belgian public sector can receive it (but, of course, not necessarily approve it).
DocumentTypeName | syntax (XSD) | semantic | |
1 | Invoice | ||
2 | CreditNote |
The Belgian public sector strictly follows the PEPPOL BIS. All documents meeting the BIS are guaranteed to be received.
Additionally, most entities expect that the invoice contains a valid purchase order number (in the orderReference UBL data element), for it is the key for a correct business processing of the inbound invoice. Failing to mention such information, involves a high risk of invoice business rejection. |
In a properly implemented e-Invoicing business interaction, the customer returns a response to the supplier. The PEPPOL framework does not yet offer a suitable document type, meaning a format that is designed for sending business responses. The Invoice Response format should be available very soon. In the meantime, PEPPOL offers another format, the Message Level Response (MLR). This format is designed for returning technical feedback, but can be used as "work-around" format for returning business responses. The Belgian public sector uses that work-around. Once the Invoice Response format will be available, the Belgian government will set up a friction-less migration scenario.
DocumentTypeName | UBL DocumentTypeCode | syntax (XSD) | semantic | |
1 | Message Level Response | 301 |
Remarks:
One of the main advantages of the PEPPOL interoperability framework, is that it fixes the challenge caused by the legitimate need for multiple formats. Like human beings need many languages, machines need many formats. Indeed, different machines working for different sectors and bound to very different business needs and patterns, will naturally seek optimal format related to their own context. The issue then is that it creates fragmentation between islands of correspondents. The existence of specialized service providers, operating islands of trading parties under a 3-corners model approach, may be the consequence of this, rather than the cause of the isolation. |
The only thing you need to send e-documents on PEPPOL is an Access Point (AP). As illustrated on the section Typical flow of a B2G e-invoice above, sending an e-document on PEPPOL is like "dropping an envelope into a postal mailbox". All you need is access to an AP that acts as postal mailbox.
You can setup your own AP, but for most enterprises, it is more effective to use the services of a specialized company, called an IT service provider. Indeed, most non IT enterprises (a) do not operate their outbound invoicing software - so setting up an internally operated AP will probably not even help, because you still need to "plug" your outbound invoicing software onto it - , and (b) have no IT skills to do this properly / cost-effectively - it is not a complex project but, like in any business domain, it requires some specialized skills to be done properly.
One of the key-aspects of the PEPPOL interoperability framework, is that you don't need to know the technical details of each receiver, to be able to send them e-documents. How is that possible? PEPPOL includes a registry (* ), continuously up and running, where all enterprises receiving e-documents are registered. This registry contains two informations (a) where to send the e-documents - it is actually the address of the receiver's AP ( where the "postal system" must route the e-document) - and (b) what format to use: all receivers must declare all the formats that they can support (and thus read), so that all the senders can see what format can be used. Because all participants must always be able to handle the BIS, it is not possible that two participants don't find at least one common format.
(* ) The exact name of this register is SMP (Service Metadata Publisher). In fact this is not a single big register, rather a set of registers, publishing the same kind or information the same way, so they behave collectively as if they were one single register.
All enterprises implementing inbound e-invoicing, like all Belgian public sector entities, register the e-invoice and e–credit note receiving capability in this registry. The exact description of the receiving capabilities, looks like:
busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0::2.1
busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol4a:ver2.0::2.1
busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:www.cenbii.eu:transaction:biitrns014:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0::2.1
As you can see, and as you could expect in the context of e-invoicing, these records are suited for automatic processing, NOT for discussions between human beings.
All enterprises implementing outbound e-invoicing, like the suppliers of the Belgian public sector entities, are invited to register the appropriate receiving capability in this registry. The exact description of the receiving capabilities, looks like:
busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##urn:www.cenbii.eu:transaction:biitrns071:ver2.0:extended:urn:www.peppol.eu:bis:peppol36a:ver1.0::2.1
The above description corresponds to the PEPPOL BIS 36A Message Level Response.
This section covers several specific business and technical scenarios, and explains how Mercurius handles them.
Any e-invoice deemed compliant with the PEPPOL BIS format but which does not pass the format validation step, is "filtered" by a component installed between the PEPPOL AP and Mercurius. Suppliers (e-invoice senders) and their IT subcontractors must therefore ensure that only e-invoices complying with the PEPPOL BIS format are sent.
This provision stems from the following considerations:
The Response generated by the Belgian public sector, contains a response code, that provides a high-level meaning of the response. It may be useful that the suppliers, or their IT colleagues or IT-suppliers, understand these codes. Here is the table that consolidates this information:
Code | Value | Remark | Remark: legend |
81:1 | Credit Note approved | 1: In case of response code 81:2 or 380:2, the response also contains additional textual description of the rejection, provided by the customer | |
81:2 | Credit Note rejected | 1 | |
81:3 | Credit Note ID already exists | 2 | |
81:4 | Hard business rule violated | 2 | |
380:1 | Invoice approved | 2: codes 81:3, 81:4, 380:3 and 380:4 relate to business preprocessing, performed by Mercurius. see next paragraph for more info | |
380:2 | Invoice disputed | 1 | |
380:3 | Invoice ID already exists | 2 | |
380:4 | Hard business rule violated | 2 |
As explained in the previous section, the supplier will receive the response electronically only if he has registered the PEPPOL MLR Receiving capability. If it is not (yet) the case, then, as the flow 3a in the diagram above illustrates, Mercurius foresees an alternative delivery mode: email. Mercurius will look into the original e-invoice for the email address of the supplier, and will send the Response information contained in the MLR, in a human-readable format, to this email address. The email address is extracted from the following e-invoice UBL Data element:
Invoice/AccountingSupplierParty/Contact/ElectronicMail
If this data element is empty in the original e-invoice, then no email can be sent. Then the only way for the supplier to check the response, is to check on the Mercurius Portal. For more information about the Mercurius Portal, please check the following page: Mercurius portal help page.
The Mercurius platform includes a specific component that validates any document (incoming AND outgoing) from a business point of view. That is, it controls certain characteristics of the contents of the document. If any of these contents violates one of these validation rules, Mercurius rejects the document on behalf of its final recipient. The recipient is not informed of this rejection. The sender receives a response notifying rejection and motivation (the response document).
The checks carried out are as follows:
(* ) This rejection is justified by the accounting obligations to which they are subject to the issue of an invoice in due form.
Suppliers are not supposed to care about this Mercurius service. However, experience shows that many suppliers fail to meet the business rules verified by this validation. Therefore, in practice, many suppliers need to have access to this information.
Note: The Mercurius Portal allows all portal users authorized to access the document, to be informed of this rejection and its motivation. For more information about Mercurius Portal, please refer to the page Mercurius portal help page.
Because generalization of e-Invoicing and e-Procurement is a new topic, there is a legitimate need to perform tests. However, many aspects and parts of the solutions (both in the public and in the private sector) are relatively new, so it often makes tests difficult to organize / delicate to interpret. Therefore, the Government invested heavily in a robust and controlled end-to-end test infrastructure. This makes tests of the b2g e-invoicing easy. Additionally, a lot of the components of this test infrastructure, can be reused by private sector entities, free of charge, to check that their part of the solution is indeed fully compliant.
If your outbound invoicing system has a test environment, or is able to produce invoices for test purposes (meaning they won't be booked for real) and to the test environment of the customers, then you have what it takes to send test invoices to the public sector.
To send test invoices to the test systems of the government:
IT sector representatives can use resources available on the web to validate their systems. There are many online format validation tools. These tools validate the PEPPOL BIS format, not the content. However, it is strongly recommended to validate the capability to produce documents with the valid format, separately from the content aspects.
The IT service providers sector also can use the Mercurius Portal.to track and trace all their traffic with Mercurius, thanks to the eGOV Role "Mercurius_AP". This applies to both the test and production traffic. More information about this is available in the on-boarding procedure described in the section "Access Points " of the official page of the Belgian PEPPOL Authority. This page also contains many useful information for the IT sector related to conducing test activities and other purposes.
Finally, for more detailed instructions to use the Mercurius Portal, please also refer to the Mercurius portal help page.
Mercurius is a public service. It is potentially used by 50.000 suppliers and 5.000 customers, or even at a larger scale, considering the rotation of the suppliers of the public sector. These figures provide the levels of magnitude of the support needs. A very wide range of public and private entities are eligible to use the platform, and to raise support issues. Considering this, it is critical for BOSA DTO to make sure that the support is properly scoped, described, organized and used.
The Government provides assistance to the enterprises and to the public sector entities, about the use of the Mercurius Platform and its Portal.
It also provides information to help familiarize with the PEPPOL interoperability framework. However, this assistance is limited to common knowledge. It is not in the missions of the Government to provide advanced technical support to persons setting up PEPPOL solutions or marketing them.
The Government also provides additional technical support to enterprises from the IT sector, integrating their products with Mercurius through PEPPOL. This includes the consultation and registration of receiving capabilities on smp.belgium.be.
Even though the e-invoice travels electronically, it still is an invoice first of all. You still should contact your procurement representative at the customer, when you have questions about the processing of the invoice. Was it received, was it approved, ... . If there is a technical problem with the e-invoice, unless the invoice did not arrive on Mercurius, your procurement representative will be able to answer your questions.
If the e-invoice did not arrive on Mercurius, then in most situations it is an issue with your IT solution provider or Access point (AP) (internal or external), and it should be discussed with him.
This being clarified, here is a description of the assistance and support facilities delivered by the Government.