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 fulfills the role of a centralized 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:

History

In December 2012, the Belgian Government Cabinet decided (a) to support the European strategy to impose electronic invoicing as the most widespread billing method in Europe by 2020, and (b) in this context, to task the Federal Public Service Budget and Management Control, the Agency for Administrative Simplification, Fedict and the Federal Public Service Finance to jointly set up a B2G e-invoicing and e-scanning pilot phase. Fedict handled the implementation of the Mercurius exchange platform, harmonizing the interface between the private sector and the public sector to avoid that suppliers (and the public sector entities) face excessive disparities between parties.

At the time, Mercurius was solely based on a solution developed by ePRIOR, the European Commission's IT department.

At the end of the pilot phase, Mercurius was brought into line with PEPPOL, the interoperability framework. The absence of such an interoperability framework inhibited the administrations (and their suppliers) in their party-to-party negotiations and hampered the exchange conditions, which ruled out the large-scale implementation of e-invoicing. PEPPOL resolved this issue for e-invoicing and more broadly speaking for e-procurement among the public sector entities and within the private sector.  

Mercurius is being redesigned, to widen the scope of document exchanges of the public sector entities with the private sector, and to facilitate the alignment of the Belgian public sector entities with the European standard. The interface with the public sector entities, which has not been modified since the pilot phase, is now adapted so as to enable to meet the new needs.

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.

Integrators

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.

User groups, reflection groups.

The adoption of e-invoicing and its widespread roll-out across the country is not a one-stage process. It is much more an ensemble of various changes and processes. Comparing notes and exchanging views on a regular basis allows for common and consistent approaches to be put in place. Against this background, a reflection group was set up at the impetus of the Flemish public administration. This body enables the stakeholders to share experiences and to make sure that the key information is properly passed on. Presently, the reflection group is sufficient to fulfil this role, but it is likely that as e-invoicing becomes more widespread, a more robust body will be necessary.

Financial aspects

Running Mercurius involves two expenditures: the services of the sub-contractor who has been contracted to handle the platform's operation and the government staff supervising the sub-contractor. 

The services of the sub-contractor were contracted subject to the terms of a call for tenders through the central procurement agency. This formula enables the operations to be co-funded. To date, the Federal Public Service Policy & Support - Digital Transformation Office (abbreviated as BOSA DTO below) has been paying all operating costs. In the more or less short term, these costs will be shared between the institutions that benefit from the service delivery, in accordance with the allocation formula based on the respective volumes. The details of this allocation remain to be defined.

BOSA DTO charges the supervision of the services delivered by the sub-contractor to its own budgets (staff payroll and specific assignments, e.g. intrusion and exfiltration tests).

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 page.

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

Flow and components

Sequence

Legend: FAS Federal Authentication Service (to authenticate people when accessing  Mercurius)

Beforehand: the supplier has raised an outbound invoice in his own accounting system Steps: The supplier sends out the e-invoice through PEPPOL. See also Step 1: the supplier sends out his invoice to the customer. Mercurius collects the e-invoice and puts in the customer's "in-tray". See also Step 2: Mercurius receives the invoice (on behalf of the customer). The customer connects to the Mercurius service made available by his integrator to collect his inbound e-documents. See also Step 4: the customer picks up his e-mail at his own pace. The integrator accesses Mercurius, picks up the e-invoice in the name of the customer, and forwards it to the latter. Result: the e-invoice has been sent to the customer. It is retrieved from the customer's in-tray in Mercurius. It remains visible on the Mercurius Portal. Comments: 5: The supplier, the customer and all intermediate parties involved in the exchange can check the progress of the transmission through the Mercurius Portal at any time. 1a: The supplier who is unable to send his e-invoice through PEPPOL can create this invoice on the Mercurius Portal (as long as this is a reasonably simple invoice). 1b: The supplier who was already connected to the system during the pilot phase and who as yet is unable to send his e-invoice through PEPPOL can send his invoice through the pilot interface (temporarily still in place). 3c: The customer is unable to receive e-invoices yet. In this particular case, Mercurius converts the e-invoice into a PDF document and sends it to the customer's address as previously registered in the configuration. See below (PDF Converter). The collection of inbound mail through the Mercurius service involves 3 operations (inbox request, retrieve document, mark document).  See below.

2. Returning a response

Mercurius Web Service

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.
                 

How Mercurius supports the interactions of its customers

Every customer has an "in-tray" on Mercurius, where the system drops all e-invoices, e-credit notes and attachments relating to these documents, as and when they come in. To receive e-invoices on Mercurius, the customer will first need to register on Mercurius, by creating an "in-tray". The "User assistance and support" section explains how new customers are to be registered on Mercurius. As soon as the customer is registered, he can start using the service. The service allows for (a) inbound mail to be picked up and (b) the  responses to be sent out after the e-invoices and e-credit notes have been processed.

a. Retrieval of inbound mail

This retrieval involves 3 operations:

• SubmitInboxRequest: enables the user to consult the list of new documents pending their retrieval
• RetrieveDocument: enables the user to pick up a document
• MarkDocument: enables the user to confirm the document has been retrieved.

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
(* ) 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.

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 Business Pre-Processing

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:

• Duplication: if Mercurius has already received the same DocumentID-DocTypeID-SenderID-ReceiverID combination, it will consider this to be a duplicate and reject it (* ). The original document can be retrieved at all times.
• Future issue date (* )
• The DocumentID exceeds 250 characters
• The DocumentID  uses exotic characters (namely, that are not included in the ASCII 7 bits table)

(* ) this rejection derives from accounting rules applicable to invoices.

Comment: the Mercurius Portal enables all portal users authorized 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:

• to facilitate the communication of the public services: it is very difficult to explain to the suppliers that institution A is ready, institution B will be ready in 3 months, institution B will be ready in 6 months' time, etc. Thanks to the PDF Converter, a whole batch of institutions - ideally the entire public sector - should be able to adopt the reception of e-invoices in a single step. Finally, each institution can successfully implement its own IT project, and can rest safe in the knowledge it will be receiving e-invoices from the first day.
• to avoid the senders from being penalized: all suppliers who have made the effort of observing the recommendations of the administration, hope to be able to make the most of their investment in a reasonable time span. Thanks to the PDF Converter, they can immediately start using their new system to send out invoices to a wide number of partners. This approach transforms the current vicious circle which sees everybody biding their time before making their decision, into a virtuous circle, which prompts everybody to adopt e-invoicing.

Expired documents

In the event where a document was not retrieved by its recipient after 30 calendar days, the Mercurius platform:

• considers the document as expired
• removes the document from the recipient's in-tray
• Sends a mail alert to a service address (configurable according to the customer's wishes) notifying the customer of the expiry of the document.

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 authorized 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.

Customer identification: enterprise number

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.

User assistance and support

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 organized as follows:

1. First of all, consult the information published in these pages. BOSA DTO has invested a lot of time to gather, structure, organize 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 form. 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.

Customer support with their e-invoicing project

The procurement officer and/or the IT teams involved in the adoption of e-invoicing can call on project support. This support may cover various aspects: 

• strategic challenges of the project, assistance with the basic (technical and other) decisions
• the actual technical alignment with the Mercurius platform
• monitoring and evolving maintenance

Support can therefore start before the technical integration phase, and will generally continue afterwards.

Strategic challenges:

The adoption of e-invoicing is not just an ad hoc technical project. It should rather be considered as a deep and long-term transformation, involving various stages. BOSA DTO is conducting an awareness campaign among the public sector entities facing this issue. BOSA DTO is available for meetings to jointly examine the context of the institution (or group of institutions), and to get involved in establishing the institution's strategy or action plan. Of course, the institution remains sovereign in its analysis and decision-making. Nevertheless, it is crucial that the institution is properly informed. The effect of the overall low level of maturity of e-invoicing is that the information is not easily available, often contradictory, and ultimately unsatisfactory. In particular, the contribution of the PEPPOL framework is largely misunderstood. The same applies to certain functions of the Mercurius platform which are sometimes poorly exploited due to this lack of understanding. This documentation aims to remedy this situation, in complement to the meetings within the public sector entities.

Lastly, the purpose of these meetings is for the institution to come away with a clear view of the challenges, of the solutions available adapted to its scope, and is able to establish an action plan. 

As an example, the following questions should be answered:

• What are the main stages of my project
• How does the solution put forward simplify the raising and receipt of e-documents (→ cost reduction)
• Do I need to use the PDF Converter? When?
• Which steps should I undertake vis-à-vis my suppliers for them too to adopt e-invoicing?
• ...

Technical alignment with the Mercurius platform

Once the decision has been taken to link up with the Mercurius platform, the technical project gets under way.

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. Additional information about the test environment and test tools is available on demand via the support request form.
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.

In parallel with the technical project, and in order to ensure the cost-effectiveness of the efforts, it is crucial that the institution conducts an awareness campaign aimed at its suppliers regarding the dispatch of electronic invoices. Currently, no sufficiently generic and reusable communication model exists that could be sent to the institutions for the purpose reuse for this step. BOSA DTO is at the beck and call of the institutions to support them in their communication activities.

Comments:

• In the situation where the institution calls on the services of a sub-contractor for the development and/or the technical activities, BOSA DTO is on hand to assist the sub-contractor directly with the technical aspects and the procedure.
• In the situation where the integrator is as yet unable to deliver the Mercurius service, institutions can call on the Federal integrator (FSB) on a temporary basis.
• Where the institution is already being sent e-invoices whereby the PDF Converter is used, the institution is invited to specify the configuration of Mercurius (test/production) in its requests.

Technology watch and evolving maintenance

After the institution has integrated its system with Mercurius, extension and optimization 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 prioritizing the requests, and as the communication tool of the roadmap of the onward development of Mercurius.

Tests

The existence of the Mercurius test environment facilitates the alignment of new institutions and of new economic operators (suppliers), and the development of new features. Available 24/7, this environment is wholly compliant with the production environment (including the user logins and the data access authorizations). This enables the correspondents to prepare the upgrade of their respective systems upgrade in the safest and most controlled way. The communication of the practical details in respect of the test environment, is included in the support delivered to the institutions during their Mercurius integration projects.

Integrators

The customers' systems have access to the Mercurius service through the ministrations of the service integrators. In compliance with the provisions that govern the data exchanges within the public sector entities, the Mercurius services are provided by the Federal and Regional service integrators, in line with their respective levels of governance.

a) Federal contracting authorities

Generalities

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

In this context, and given the fact that the Mercurius service provides access to the invoices of the party concerned, the only administrative verification required to access the service through the FSB is to ensure that the requester effectively is a legal entity under Belgian public law operating at Federal level

Technical arrangements and procedures:

In order to be able to access all services delivered on the FSB, two technical-administrative formalities need to performed: (1°) the generation and dispatch of a certificate and (2°) the application for access to the service(s) in question

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 Authorization (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

• Brussels Region and associated local authorities: ISR/FIDUS
• Flemish Community and associated local authorities:  MAGDA/VSB
• Walloon Region, Wallonia-Brussels Federation and associated local authorities: BCED

Flemish Community

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.