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

Overview

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

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

High-level steps:

1. the invoicing system, used by the supplier to handle his/her outbound invoices, prepares the e-invoice
2. the system drops the e-invoice into his own PEPPOL Access Point (AP). Like the picture above suggests, PEPPOL APs are the electronic equivalent to the real-world red mailboxes: the sender drops his mail into a mailbox of his choice - let us call it his mailbox-out, and the receiver gets his mail into his mailbox-in. a discussion of the available options to setup a new or select an existing AP, fall outside of the scope of current article. Please consult following article: Access points servicing Belgian companies
3. the PEPPOL AP sends the e-invoice to the PEPPOL AP of the customer, using the transmission methods consistently applied by all PEPPOL APs.

alternate flow: Mercurius Portal

The Mercurius Portal fulfills 2 functions:

1. it allows any supplier, (public) customer and their service providers, to track and trace their relevant B2G e-invoices traffic in appropriate detail (business and technical), and
2. it compensates the possible lack of e-invoicing software solutions available on the market, due to the fact that e-invoicing is not yet sufficiently generalized. This especially applies to small and medium-size enterprises (SME). This gap is expected to be temporary: the uptake of B2G e-invoicing will help fill it in, creating the conditions for generalization of B2B and B2C e-invoicing. 

For more information about the Mercurius Portal, please read Mercurius portal help.

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

main flow

1. Mercurius is connected to an Access Point on the PEPPOL network. It receives the invoice through this Access Point.
2. Mercurius checks the following set of elementary content requirements:
   1. it is the first time it receives this invoice number from this supplier;
   2. the issue date is in the past;
   3. the invoice number is less than 250 characters long and does not contain exotic characters (that would alter the processing by the customer's system).
3. the document becomes visible on the Mercurius Portal - only for the portal users related with the sending or the destination entity - for additional explanations on this subject,  please read [ADD LINK TO PORTAL GDP]

alternate flows

• (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 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:

1. extracts it out of the invoice,
2. creates a separate document containing the attachment and related to the original invoice, and
3. puts it in the customer's in-tray.

Step 4: at his own pace, the customer picks up his mail in his in-tray

At its own pace, the system associated to the customer, collects the invoices that arrived in his in-tray. this involves 3 types of operations:

1. inbox consultation: the system receives the list of new documents arrived (including attachments)
2. document retrieval: the system effectively picks up the document
3. mark as read: the system flags the document out of the list of new documents arrived. This operation is also the technical acknowledgement that the document was collected.

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

In this step, the customer approves or rejects the e-invoice, based on appropriate business verification.

This step involves no interaction with Mercurius. It is performed by the customer, using its own inbound invoices (and e-invoices) validation system, checking specific business conditions applicable to the document.

When e-invoicing is fully adopted, this processing step is automated, which involves that the vast majority of invoices are processed with no delay. Yet, depending on (a) the customer's context, maturity and business processes and (b) the characteristics of the involved document, this step may take some time.

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": https://overheid.vlaanderen.be/e-invoicing-voor-leveranciers.

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 and the interface with the customer systems, aiming at eliminating this conversion step, is in development.

Step 7: Mercurius sends the response to the supplier

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

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

Invoice/AccountingSupplierParty/Contact/ElectronicMail