Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

the life cycle of an e-invoice to the Belgian public sector

As discussed in the section 4 of the article "e-invoicing strategy of the Belgian public sector", the handling of an e-invoice to the government, takes 7 key-steps. The present article presents each step in more detail. Where appropriate, it also provides more information about the variants, the upcoming improvements, ....


The following graphs displays the flow of the invoice among the components:Image Removed

Image AddedGraphical representation of the B2G  flow and its components, compatible with an "any-to-any" exchange model 

High-level steps:


Table of Contents

Step by step

Step 1: the supplier sends his invoice to the customer


For more information about the Mercurius Portal, please read [ADD LINK TO PORTAL GDP] Mercurius portal help.

Step 2: Mercurius receives the invoice (on behalf of the customer)


  • (1a) the e-Invoice does not meet the expected format specifications. In this case the e-invoice is dropped. for more information about this scenario, please consult the sections "Specific scenarios", on the page "mercurius Mercurius for the private sector".
  • (2a) any of the conditions specified in step 2 is not met: Mercurius then prepares a response, on behalf of the destination entity, rejecting the invoice and explaining why. See also step "Mercurius sends the response to the supplier".

Step 3: Mercurius puts the invoice in the customer in-tray

Each public sector entity (here, the customer) has his own in-tray in the Mercurius electronic mail-room. It is only accessible by the IT system associated to the customer. Mercurius puts all incoming valid invoices in this in-tray.

If the invoice contains attachments, then for each attachment, Mercurius:


From then on, the document is removed from the customer's in-tray. If, for some or other reason, the customer must re-load it, he must contact Mercurius support to get the document back into his in-tray (re-submit).
More technical description related to the documents collection process by customers, is available at about the status of my invoice.

Step 5: the customer processes the invoice


Customers usually communicate their own common conditions for approving invoices. The Flemish Government published their common business requirement on the following page , under the section   "Stap 3. Het toepassen van de Business Requirements": {+}

Step 6: the customer prepares a response to the invoice and passes it to Mercurius

This step is optional. However, it is more and more common practice that the customer performs it, for obvious consistency reasons.

The customer communicates the result of the invoice processing to the supplier, by letting his system (a) prepare a response document and (b) send it to  the Mercurius electronic mail-room.

Next step describes how Mercurius handles this electronic communication flow.

Due to historical reasons, the format currently used by the customer system to communicate the result of the invoice processing, slightly differs from the format used by Mercurius to communicate with the supplier system. This involves a conversion operation (see next step). This conversion unnecessarily complicates the exchanges. Therefore, a modification of mercurius Mercurius and the interface with the customer systems, aiming at eliminating this conversion step, is in development.


  1. Upon reception of such a response from a Customer, Mercurius correlates the response with the original invoice, and adapts the invoice status accordingly. This update is visible on the Mercurius Portal. For more details about the invoice status on the Mercurius Portal, see Was my invoice duly received by the customer? What is the status?
  2. Mercurius converts the customer response document into the PEPPOL format specifications suitable for the response - currently, it uses the Message Level Response (MLR) format.
  3. Mercurius checks that the supplier has the capability to receive the MLR on the PEPPOL transport infrastructure.
    1. If it is the case, Mercurius transmits the MLR
    2. If it is not the case, Mercurius looks into the original document for a contact e-mail address (star) (* ) for the supplier. If this information is available, then Mercurius converts the response in a human readable format and sends it by e-mail.
    3. Otherwise the response is not transmitted. In this case, the response is still visible on the Mercurius portal.

The MLR format is not exactly designed to communicate business approval or rejection. It is used by Mercurius due to historical reasons. In the near future, a new format, named Invoice Message Response (IMR), will be available on the PEPPOL transport infrastructure. This new format will be used instead of the current MLR. This format change will be introduced smoothly.(star)

(* ) The exact source of the suppliers contact email is the following (UBL) Data Element  in the original invoice: