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.

...

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.

...

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.

...

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.

...

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

...

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.

...

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

...

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.

...

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.

...

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.

...

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.

...

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.

...

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

...

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

...