Versions Compared

Key

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

This article is for representatives of the private sector, in charge of sending invoices to belgian governmental entities, or involved in such duties. For instance, billing officers, IT teams supporting financial departments, external IT service providers and/or software supplier, or any other kind of people interested by outbound e-invoicing.

...

Table of Contents
maxLevel1
absoluteUrltrue

Legal background

Council Directive 2010/45/EU of 13 July 2010 amending Directive 2006/112/EC on the common system of value added tax as regards the rules on invoicing, made electronic invoice equivalent to the paper invoice. These directives were translated in Belgian law. for more info, see following pages: FR - NL.  This created the conditions for the wider adoption of e-invoicing.

Directive 2014/55/EU of April 16th, 2014, obliges all European Public sector entities to accept and process electronic invoices that comply with the European Norm EN16931. The translation in Belgian law is in process.

...

Business Experts from all horizons of the Belgian invoicing landscape, supported by technical experts, participate in this joint effort. The Federation of Enterprises of Belgium provides the facilities needed by the group (logistic support, extranet, moderation....).
info

Extranet of the Belgian e-Invoicing Business Experts Group (members-only): https://extranet.vbo-feb.be/SitePages/Home.aspx 

Flow and components

The article The life cycle of an e-invoice to the Belgian public sector explains the flow and processing of an e-invoice. This section details this description from a private sector (business) view. (* )   It (a) explains data flows connected to exchange services regarding e-invoices and components necessary to make the flow operational, (b) introduces a technical point of view on these components and (c) situates the decisive role of a network of service providers, access points and software editors acting in this context. The major flows are (1)  sending an e-invoice (or e-creditnote) and (2) receiving an answer.

...

Flow and components

Steps

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

Preamble: supplier generates an outgoing invoice in his own software solution.

Steps:

  1. supplier sends out the e-invoice by means of the PEPPOL network.
    See also Step 1: the supplier sends his invoice to the customer.
  2. Mercurius collects the e-invoice and puts it in the customer's in-tray.
    See also Step 2: Mercurius receives the invoice (on behalf of the customer).
  3. the customer calls the Mercurius service, made available by his integrator, to collect all incoming e-documents.
    See also Step 4: at his own pace, the customer picks up his mail in his in-tray.
  4. the integrator connects to Mercurius and gets the e-invoice in the name of the customer and sends it to the latter.


Result: the e-invoice has been sent to the customer. It gets retrieved from the in-tray in Mercurius. It is still visible on the Mercurius portal.

Remarks:
5: at every moment, the supplier, the customer and all intermediate parties concerned in the exchange, can check the progression on the exchange through the Mercurius portal.

1a: the supplier not able to send his e-invoice through PEPPOL, can create this invoice through the new invoice form on the Mercurius portal (as long as the invoice is reasonably simple)

1b: the supplier already connected during the pilot phase and not already able to send his e-invoice through PEPPOL, can send his invoice through the pilot interface (temporarily still in place)

3b: the customer is not yet able to collect e-invoices. In this particular case, Mercurius converts the e-invoice in a pdf document and sends it to the customer's address, registered in its configuration.
The retrieving of the messages in the in-tray through the Mercurius services require 3 operations (inbox request, retrieve document, mark document). see also later

...

Flow and components

Steps

Preamble: the customer has accepted (or rejected) the invoice in his own administratif system - see also Step 5: the customer processes the invoice.

Steps:

  1. the customer connects to the Mercurius service made available by his integrator, and sends his response to the supplier.
    See also Step 6: the customer prepares a response to the invoice and passes it to Mercurius.
  2. the integrator connects to Mercurius and transmits the customer response.
  3. Mercurius sends the customer response through the PEPPOL network.
    See also Step 7: Mercurius sends the response to the supplier.
  4. the supplier collects the response from his Access Point (AP). If the AP is operated by a separate party (e.g. a service provider), then a technico-commercial agreement determines the terms and conditions of this collection process.

Result: response was received by the supplier.

Remarks:
5: The status of the invoice (retrieved, accepted or rejected) and the details on the status (motivation), are available to be consulted on the Mercurius portal. At every moment, the supplier, the customer and all intermediate parties concerned in the exchange, can check the progression on the exchange through the Mercurius portal.

3a: not every supplier having send and e-invoice through PEPPOL is capable of also getting the response on the PEPPOL network. In this particular case, Mercurius will send the response by e-mail as described in Step 7: Mercurius sends the response to the supplier.

3b/4b: the supplier on-boarded during the pilot phase, can still receive the responses through this pilot interface (still available only for a limited time).

...

In 2011, a limited but representative set of actors coming from different horizons, decided to hold several workshops with the purpose to deliver a set of cross-sector and cross-border formats for most of the procurement documents (catalogue, order, order response, dispatch advice, invoice, credit note...). The CEN BII workshops delivered the CEN Business Interoperability Interface (BII) WorkGroup Agreements (WGA), containing the CEN BII formats.

...

For all these reasons, the Belgian public sector decided to support only the BIS invoice and credit note formats, for the time being.

Of course, due to the Directive 2014/55/EU, the Belgian public sector will upgrade their systems to also support the European Norm EN16931 in the near future. Notice that EN 16931 requirements include the necessity to be well aligned with CEN BII. In other words, the EN 16931 design integrates the migration from CEN BII Invoice.

...


DocumentTypeName

syntax (XSD)

semantic

1

Invoice

UBL-Invoice-2.1.xsd

PEPPOL Peppol BIS 4A Invoice

2

CreditNote

UBL-CreditNote-2.1.xsd

PEPPOL Peppol BIS 5A BillingCredit Note


The Belgian public sector strictly follows the PEPPOL BIS. All documents meeting the BIS are guaranteed to be received.

...


DocumentTypeName

UBL DocumentTypeCode

syntax (XSD)

semantic

1

Message Level Response

301

UBL-ApplicationResponse-2.1.xsd

PEPPOL BIS 36A Message Level Response

Remarks:

  • To receive the business response as explained above, the invoice sender must have declared the MLR receiving capabilities in the PEPPOL Transport Infrastructure. see next section.
  • The Message Level Response (MLR) is not mandatory. The section "specific scenarios" also contains additional useful detailed information about the contents of the MLR.

...

The above description corresponds to the PEPPOL BIS 36A Message Level Response.

Specific scenarios

This section covers several specific business and technical scenarios, and explains how Mercurius handles them.

...

This provision stems from the following considerations:

  • The Document formats section allows suppliers (or their IT subcontractors) to know the document format requirements that governments can handle.
  • In a context of widespread e-invoicing, compliance with these requirements is essential.
  • The PEPPOL framework, which forms the main technical reference for our e-invoicing generalisation program, advocates a proven approach leading to the implementation of high-quality, format-based flows. In particular,
    • the PEPPOL BIS format, which is the format supported by the Belgian public sector, is equipped with validation tools based on a widely used technology (schematron), making it possible to automate the format compliance controls.
    • standard contracts that bind operators, prohibit the transmission of non-compliant documents in the format that they are deemed to respect. Nothing obliges the addressee to read such documents.
  • Therefore, any e-invoice deemed to comply with the PEPPOL BIS format but which does not pass the format validation step, is "filtered" by a component installed between the PEPPOL AP and Mercurius.
  • Senders (or their IT subcontractors) can fully automate the validation of their e-invoices BEFORE shipping them, using the same validation tools as the above filter, as these tools are distributed publicly and free of charge.
  • Finally, the Mercurius Portal is equipped with an online test message lookup tool: the sender (or his IT sub-contractor) can transmit the e-invoice via PEPPOL in the test environment, then check online. if the message has arrived and is not tainted by error. This tool avoids spreading errors in the actual billing flows.

...

If this data element is empty in the original e-invoice, then no email can be sent. Then the only way for the supplier to check the response, is to check on the Mercurius Portal. For more information about the Mercurius Portal, please check the following page: Mercurius portal help page.

Mercurius Business Pre-Processing

...

Suppliers are not supposed to care about this Mercurius service. However, experience shows that many suppliers fail to meet the business rules verified by this validation. Therefore, in practice, many suppliers need to have access to this information.

Note: The Mercurius Portal allows all portal users authorized to access the document, to be informed of this rejection and its motivation. For more information about Mercurius Portal, please refer to the page Mercurius portal help page.

...

  • the sending AP must lookup for the receiving capabilities of the receiver using the SMK instead of the SML.
    • the SML is the Service Metadata Locator. It is the central system that reroutes APs looking up for receivers capabilities to the receivers SMP (see also "Sending / receiving e-documents - important information" above)
    • the SMK is the alter ego of the SML, in the test infrastructure.
    • all public sector entities are identified with exactly the same identifiers in the Real environment (Production) and in the test environment. This is to minimize the risk of confusing identification numbers.
  • to quickly control the status of the transmission in the test environment, the following on-line tool is available: Test document lookup.
  • at all times, you can also check all received traffic, in test as in production, using the Mercurius Portal. For more detailed instructions to use the Mercurius Portal, please refer to the Mercurius portal help page.

...

The IT service providers sector also can use the Mercurius Portal.to track and trace all their traffic with Mercurius, thanks to the eGOV Role "Mercurius_AP". This applies to both the test and production traffic. More information about this is available in the on-boarding procedure described in the section "Access Points " of the official page of the Belgian PEPPOL Authority. This page also contains many useful information for the IT sector related to conducing test activities and other purposes.

Finally, for more detailed instructions to use the Mercurius Portal, please also refer to the Mercurius portal help page.

...

The Government also provides additional technical support to enterprises from the IT sector, integrating their products with Mercurius through PEPPOL. This includes the consultation and registration of receiving capabilities on smp.belgium.be.

Organization

Preliminary remark for suppliers

...

  1. Read the available information first. BOSA DTO has invested many hours to collect, structure, organize and translate the knowledge base. Your question should be there somewhere.
  2. If you can not find an answer on your question, fill in the support request.
    1. It is also available on the homepage of the Mercurius Portal.
    2. We encourage identifying yourself on that page, so that precious information can be collected to (1) make it easier for you and (2) makes it possible to collect essential information on role management to facilitate support and bring this support to a higher level.
    3. If you would not be sure how to use the support request form, then have a look at the following page, that guides you through the sections of the page: How to use the Mercurius support request form?
    4. Our central service desk will make sure that the support request is properly identified in the support follow up tool, and handle your request as soon as possible. However, they are only responsible for handling frequently asked questions. If you did not find what you were looking for in our large knowledge base, it probably they won't be able to help you. In this case they will pass your request to the Mercurius support team.
  3. The Mercurius support team will answer your question and handle your problem The Mercurius Support Team owns all the remaining support requests. They further analyse the case, validate that it is in the scope of the service, and make sure that the case is timely addressed and resolved, involving whatever internal or external team as appropriate.