Versions Compared

Key

  • 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

...

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:

Step by step

Step 1: the supplier sends his invoice to the customer

main flow: PEPPOL

  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 [ADD LINK TO PORTAL GDP]

...

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

...

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

...