...

WORK IN PROGRESS - Some links may not work properly - Thank you for your comprehension.

...

Mercurius for the public sector (G)

The present article is intended for the representatives of the public sector entities, faced with the implementation of inbound e-invoicing procurement officers, technical departments tasked with implementing the systems, or any other parties interested in the matter.
As explained in e-invoicing strategy of the Belgian public sector, the Mercurius platform fulfils the role of a centralised electronic mailroom service for the entire Belgian public sector, in the context of B2G e-invoicing.
This article goes one step further in the description of the Mercurius platform, seen from the perspective of the public sector, as the recipient of these invoices.
The article confines itself to the main elements (general description, main flows, on-boarding procedure, etc.) and those specific to the public sector entities. More specific issues are discussed in separate articles. Moreover, the aspects specific to the private sector, or aspects in common with the latter, are also discussed separately (e.g. the use of the Mercurius Portal). References to these related articles, as well as other relevant sources of information are included in the present article where applicable.
The article consists of the following sections:

...

Legal framework and cooperation agreements

e-invoicing

Council Directive 2010/45/EU of 13 July 2010 amending Directive 2006/112/EU on the common system of value added tax as regards the rules of invoicing, made e-invoices equivalent to paper invoices in a legal sense, thereby creating the basic conditions for the wider adoption of e-invoicing. These directives were translated in Belgian law. For more information, see following pages: FR - NL.
Directive 2014/55/EU of 16 April 2014, requires all European public sector entities to accept and process inbound e-invoices that comply with European standard EN16931, from 19 April 2019 forward (local authorities may be granted an extra year).   This measure is consistent with the e-invoicing strategy of the Belgian public sector. The underlying strategy is clearly aimed at using the procuring State as a lever to drive the development of the offering of solutions, and the kitting out of the exchange partners, both public and private. In doing so, it is important to ensure that the solutions that allow for the invoices to be dispatched to the administrations can be reused for e-invoicing private customers.
This directive is currently being transposed into Belgian law.

...

The data exchanges between public sector entities are governed by various statutory provisions (Act of 15 August 2012, Royal Decree of 7 October 2013). These provisions apply to the internal data flows within the public sector, and resulting from the rollout of e-invoicing across the public sector.

...

Flows and components

The article entitled the life cycle of an e-invoice to the Belgian public sector outlines the processing stages of an e-invoice. This section goes on to elaborate on this description, from the public sector's viewpoint . It (a) details the data flows associated with the transmission service of B2G e-invoices, as well as the components required to operate these flows, (b) introduces a technical perspective of these components, and (c) situates the role of the network of  service integrators, who play a key part in this. These flows are: (1) receipt of an invoice (or of a credit note) and (2) sending out a response
the detailed presentation of the aspects specific to the private sector is discussed on the Mercurius for the private sector (B) page

1. Receipt of a document (e-invoice, e-credit note, attached document)

...

...

As illustrated in the section above, Mercurius provides a service that enables the contracting authorities to receive their invoices (and credit notes and attached documents) fully electronically, and to send the results of the approbation of these documents.
This section describes the features of this service. In practice, this service is made available by the integrators. This aspect is discussed in greater detail in the "Integrators" section.
Lastly, this service is completed by a Portal, which allows the representatives of the customer (and of the supplier) to monitor the progress of the transmissions and the technical processing steps. This aspect is discussed in a separate page

Protocol:

SOAP ( XML over HTTPS ) + WS-Security
The applicable additional technical specifications may vary from one integrator to the next, and are consequently available from the latter. See also the "Integrators" section.
                 

...

Using Mercurius the conventional way, the customer is therefore to program a sequence of these operations at regular intervals: (1°) consult the list of these new documents, (2°) for each new document, (a) retrieve the document and (b) confirm receipt and authorisation to delete the document from the list of the pending documents.
The currently supported document types are:

...

Comments
Syntax: UBL 2.0
(**) Further clarification:

• This type of document enables the user to retrieve the documents attached to the invoices and the credit notes (record of receipt, general terms and conditions, etc.) in the form of separate file that is not necessarily structured (PDF, Excel or any other file format).
• For historical reasons, Mercurius extracts these files from the PEPPOL BIS document in which they were included (Base64Encoding), then dispatches them by linking them to separate XML (AttachedDocument- type) documents, stating the ID of the parent document. For more information, please consult (a) the xsd of this document type and the FAQ on AttachedDocuments.
• The transmission of the actual files uses the SOAP protocol with Attachment. 

(***) The senders dispatch documents that comply with these format specifications. This specification uses the UBL2.1 syntax. For historical reasons, Mercurius converts them into UBL2.0. Other than this conversion, Mercurius does not perform any conversions. As such, these format specification documents duly define the respective semantics of these documents. Further information on the PEPPOL interoperability framework is available on the following page: official page of the Belgian PEPPOL Authority (available in English only).

b. Sending a response

This action requires just one operation: SubmitApplicationResponse
Just one type of documents is currently supported:

...

Comment 
For historical reasons, the preparation of the response is subject to an internal specification, not the PEPPOL BIS specification, as is the case for the inbound flows. Mercurius converts the response transmitted by the customer into a document which complies with the applicable PEPPOL specification, i.e. PEPPOL BIS 36A Message Level Response (EN). This is explained in more detail on the page intended for the private sector.

Specific scenarios

This section explores various specific situations and explains how they are supported by Mercurius

...

Mercurius has a component that validates all documents (inbound AND outbound) from a business perspective. That is to say, it verifies certain features of the document's contents. If one of these contents breaches one of these validation rules, Mercurius rejects the document in the name of its final recipient. The recipient is not informed of this rejection. The sender on the other hand is sent a reply notifying him of the rejection and the reason for this rejection (whereby the response document is generated in observance of the arrangements and procedures outlined in paragraph "b. Sending a Response" in the Mercurius Web Service section.
The verifications performed are:

...

this rejection derives from accounting rules applicable to invoices.
Comment: the Mercurius Portal enables all portal users authorised to access the document, to establish this rejection and to find out the reasons for doing so. For further information on the Mercurius Portal, please refer to the Mercurius Portal help page. 

PDF Converter

Mercurius has a component that converts an e-invoice into a PDF document and sends it out by e-mail to a preconfigured address.  This component has been added to serve two purposes:

...

If the customer wants to reactivate the document, he can send a request to the Mercurius Support Team using the assistance request form (See below, "Support" section)
Comment: in addition to the mail alert, the Mercurius Portal enables all portal users who are authorised to access the document, to establish the expiry of the document. For further information on the Mercurius Portal, please see the Mercurius Portal help page.

Retention

The Mercurius platform stores the document received and all messages associated with these documents for a 24-month period. After, the trails are deleted. However, by express request the user can still access the audit trails in case of a dispute occurring beyond 24 months.

...

To receive e-invoices on Mercurius, users need to register as a customer on Mercurius ahead of time. This registration acts to create an individual "in-tray". Registration also requires the use of a login. Save for exceptional cases, the customer is to identify himself using his registration number with the Crossroads Bank of Enterprises. Example: Federal Public Service Policy and Support: 0671.516.647.
Customers who do not have an enterprise number of their own can identify themselves using a different login. Currently, the GLN (Global Location Number) is used to this end. Obtaining this identifier is the customer's responsibility.

...

Mercurius' operations revolve around two types of activities: (a) day-to-day support and (b) assisting customers with their e-invoicing project
In both cases, and except special circumstances, requests for support must be sent in using the assistance form, available from the landing page of the Mercurius Portal (direct link: assistance request).

Day-to-day support

The support is organised as follows:

1. First of all, consult the information published in these pages. BOSA DTO has invested a lot of time to gather, structure, organise and translate this information base. It is very likely that your query is dealt with somewhere.
2. If you have been unable to find the answer, fill in an assistance request. We strongly advise you to identify yourselves as this enables the system to prefill certain details, which (1) makes your job easier, and (2) provides us with the details necessary to deliver efficient quality support.
3. Our Service Desk receives your request. Our Service Desk only deals with frequently asked questions. If you have duly read the online documentation, it is not very likely that the Service Desk's call agents will be able to assist you. In that case they will forward your request to the Mercurius Support Team.
4. On the strength of its specific know-how and its contacts with all e-invoicing stakeholders, the Mercurius Support Team will process your query / your request, regardless of nature.

...

1. Understanding the data flows, the kind of operations these flows enable, and aligning this with your own invoice receipt system.
2. Setting afoot the developments that will enable your accounting system to be aligned with Mercurius.
3. In parallel,
   1. Configuration of the integrator's alignment environment: contacting your integrator and getting access to the test / alignment environment of Mercurius. See also "Integrators" section
   2. Configuration in the Mercurius test environment  of a (or several) customer(s): the person in charge is to send in a request using the assistance request form, specifying (1°) the company number(s) and exact designation(s) and (2°) the Common Name (CN) of the certificate of the system which will connect to the FSB. (include a comment for the other integrators as this does not mean anything to their customers)
4. Once the developments have sufficiently progressed, and the aforesaid configurations are up and running, the online tests can be carried out.
   1. Further details regarding the test environment and the test tools are available
      1. How to send test invoices (via Mercurius)?
      2. How can I check the validity of my test invoice, before sending it?
      3. How do I check that my test invoice has been duly delivered (to Mercurius and beyond)?
   2. Mercurius is equipped in such a way that the users are able to conduct tests on a highly self-reliant basis, including the end-to-end tests with the pilot suppliers. This is why no specific activities on the part of DTO are planned in this phase. Obviously the Mercurius Support Team is on hand to respond to the support requests sent in in this context. BOSA DTO is also available to get involved with perfecting these activities if necessary, for instance to explain the operation of the tools.
5. Once the results of the online tests are satisfactory, you are ready to GO LIVE. Generally speaking, this implies (a) a configuration of the integrator's production environment and (b) a configuration of the Mercurius production environment. These two configurations are performed pursuant to the model set out under steps 3a and 3b above.

...

After the institution has integrated its system with Mercurius, extension and optimisation phases will be planned as new needs and opportunities arise. Based on the new needs identified, BOSA DTO will plan and perform the relevant modifications to Mercurius that address these new requirements. These improvements are subsequently made available to the institutions.
The Reflection Group (See also above: User groups, reflection groups) serves as the platform for gathering the needs and requirements of the institutions, for prioritising the requests, and as the communication tool of the roadmap of the onward development of Mercurius.

...

As the diagram shows, the Federal service bus (FSB) serves a dual role: (1°) on the one hand, it connects Mercurius' IT system to the network of the integrators. In this context, if serves a series of key functions in the areas of security and performance; (2°) it makes the Mercurius service available to the Federal contracting authorities and the integrators of third party services. Only the second role is explained in more detail as part of this article.
The FSBs general provisions (the signing of a user agreement, start of the flows, use of a certificate, reporting, alignment environment, support, etc.) also apply to the Mercurius service delivery.
The FSB publishes a general description of its assignments, services, procedures, FAQs and the arrangements and procedures on how it delivers support on the following page:

Administrative arrangements and procedures

...

1. Generation of a certificate: this step requires the use of a certificate generation tool (to be attended to by the requester's technical department). From an administrative perspective, a traditional administrative procedure is to be observed, which allows the system to link the certificate beyond doubt to the entity which will be using that certificate for the purpose of authentication. This procedure is documented at: I request an FSB consumer certificate
2. Access request:
   1. Prior comments:
      1. To request access a Technical Connection Request Form must be used
      2. As stated, no Administrative Authorisation (AARF) is required
      3. The name of the service is  e-InvoicingServices/CustomerService V2.00
      4. Obviously, your access request is also about the INTEGRATION environment, as you will first need to go through a development and test cycle.
      5. Data connection: not applicable: the service is synchronous.
      6. Certificate: as soon as the certificates (integration and production) have been generated, send the Common Name (CN) in the TCRF. 
   2. Link to the procedure: I request access to an existing FSB web service

b) other contracting authorities

...

For the Flemish Region / Community, the MAGDA platform (MAximale GegevensDeling tussen Administraties) serves as the Regional integrator.
The following information is available on the Magda site:

• Main page (NL)
• Enrolment process MAGDA services (also used to enrol for Mercurius) (NL)
• Contact form MAGDA – general queries (NL)
• Technical documentation (Magda- general) (NL)

Brussels Region

In the Brussels Region, ISR/FIDUS assumes the role of Regional integrator. For full details regarding access to Mercurius at this level of governance, please consult the following page: FIDUS homepage (FR)      FIDUS homepage (NL)

Walloon Region and Wallonia-Brussels Federation

In the Walloon Region, BCED serves as the Regional integrator. For now, BCED is not delivering any Mercurius services Please contact your intermediary at BCED, or your IT department as applicable.