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.

As explained in e-invoicing strategy of the Belgian public sector, the Mercurius platform fulfills the role of central electronic mailroom for the Belgian public sector in the context of B2G e-invoicing.

This article goes one step further by focusing on the different parts of the Mercurius platform seen from the 'private sector' point of view as sender of the e-invoices.

It addresses the main elements that such stakeholders have to be aware of (such as general description, main flows, on boarding procedures...). Uncommon scenarios are explained in detail in separate articles. Also, topics that are common with the public sector, are explained in separate articles  (example: Mercurius portal help). References to these related articles and other relevant information are mentioned in this article, at appropriate places...

This article consists of following paragraphs:

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.

Additionally, Belgian federal and regional councils of ministers already decided to mandate B2G e-invoicing. These decisions are progressively transposed into legal, technical and promotional actions by their respective administrations.

Mercurius is the result of several of these actions. As explained earlier, this centralized electronic mailroom for the public sector, makes it considerably easier for the private sector to reach all their public sector customers consistently and cost-effectively.

Financial aspects

The solution of the Belgian Public sector to collect e-invoices from their suppliers, which is based on PEPPOL and Mercurius, was designed to minimize the long-term costs for the senders. In the short term, it is not impossible that senders will face costs due to the lack of competitiveness on the market of solutions, or due to wastes caused by maturity issues rather than real and incompressible costs. Following aspects need to be taken into account:

• the solution offers the possibility to reach all Belgian public sector entities. Today, the Federal government and the Flemish regional government lead the way, but the purpose is clearly to offer a solution that covers also the other regions, the local government level, and all other possible public right entities., in total 16% of the Belgian GDP.
• the solution is designed to be reusable to also reach all Belgian private sector entities. The government is taking many actions to convert this potential into reality, in close cooperation with the representatives of the private sector.
• the solution is also perfectly reusable to reach foreign customers, public and private. Many contacts at European level also take place to turn this into reality.
• the solution completely integrates the new European Norm. In other words, the private sector has the guarantee that there will be no sudden 180° shift when introducing the European Norm into the e-Invoicing strategy.
• the Mercurius Portal offers a solution for suppliers who are not yet able to move to real outbound e-invoicing, whatever their reasons. This solution is fully free of charges and requires no administrative burden for most of the Belgian Small and Medium Enterprises. only larger structures may need to be made aware of the eGOV roles management system, that is not such a big deal to use, but may at first sight sound like an additional formality.

Belgian Business Experts Group

A Belgian e-Invoicing Experts Group was founded in June 2017. It addresses questions such as "how should an invoice with cash discount be expressed in the BIS format", "what makes an invoice number unique", "how to cope with the multiplicity of identification schemes"... It is a meeting point across various groups, each group having its own perspective and concerns. The confrontation of these view points in a constructive mindset, accelerates the generalization of e-Invoicing.

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.

(* ) Detailed information on specific aspects concerning public sector can be found at Mercurius for the public sector.

1. Sending an invoice / a credit note

2. Receiving a response

Document formats

Previous section shows the flow of e-documents between correspondents. The present section provides useful explanation about the format requirements that apply to these e-documents. It is very important to be aware, in sufficient details, of how formats affect the exchanges between correspondents.

Preamble

Typically, electronic document exchange require that the sender and the receiver agree on an exchange format - for each type of document, subject to the exchange. This is a sinequanone condition for the IT systems of both correspondents to understand each other "loud and clear", and be able to work together seamlessly.

A format underlies two basic aspects: (a) semantics: the document is composed of information elements that are described in such a way that excludes interpretation errors; (b) syntactic: these common information elements are translated into a syntax, a data representation, that an IT system can "read" / "write". 

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.

In the meantime, the CEN BII series were reused by many practical eProcurement solutions, especially (a) the ePRIOR platform developed by the European Commission and (b) the PEPPOL Business Interoperability Specification (BIS). The PEPPOL BIS fulfills the 'common denominator format' role, meaning that if two correspondents fail to identify a common format to exchange documents, then they "fall back" to the use of the PEPPOL BIS.

During a pilot phase (2013-14) reusing the ePRIOR platform, tailored to the Belgian context, the Belgian public sector validated that CEN BII Invoice and Credit Note document types, covered all their specific information needs.

When adopting the PEPPOL interoperability framework, no specific business needs justified the support of any format other than the common denominator format - the BIS.

Although the BIS is not the most sophisticated format available, it is extremely well documented and supported by validation tools. These ancillary products definitely contribute to the quality of exchanges.

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.

Format specifications

Outgoing documents (invoice, credit note)

As introduced in the preamble above, the Belgian public sector supports the following formats: PEPPOL BIS Invoice and PEPPOL BIS Credit Note. The following table summarizes the technical information required to prepare documents in a way that guarantees that the Belgian public sector can receive it (but, of course, not necessarily approve it).

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

incoming documents (business response)

In a properly implemented e-Invoicing business interaction, the customer returns a response to the supplier. The PEPPOL framework does not yet offer a suitable document type, meaning a format that is designed for sending business responses. The Invoice Response format should be available very soon. In the meantime, PEPPOL offers another format, the Message Level Response (MLR). This format is designed for returning technical feedback, but can be used as "work-around" format for returning business responses. The Belgian public sector uses that work-around. Once the Invoice Response format will be available, the Belgian government will set up a friction-less migration scenario.

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.

Sending / receiving e-documents - important information

Sending e-documents

The only thing you need to send e-documents on PEPPOL is an Access Point (AP). As illustrated on the section Typical flow of a B2G e-invoice above, sending an e-document on PEPPOL is like "dropping an envelope into a postal mailbox". All you need is access to an AP that acts as postal mailbox.

You can setup your own AP, but for most enterprises, it is more effective to use the services of a specialized company, called an IT service provider. Indeed, most non IT enterprises  (a) do not operate their outbound invoicing software - so setting up an internally operated AP will probably not even help, because you still need to "plug" your outbound invoicing software onto it - , and (b) have no IT skills to do this properly / cost-effectively - it is not a complex project but, like in any business domain, it requires some specialized skills to be done properly.

Receiving e-Documents

One of the key-aspects of the PEPPOL interoperability framework, is that you don't need to know the technical details of each receiver, to be able to send them e-documents. How is that possible?  PEPPOL includes a registry (* ), continuously up and running, where all enterprises receiving e-documents are registered. This registry contains two informations (a) where to send the e-documents - it is actually the address of the receiver's AP ( where the "postal system" must route the e-document) - and (b) what format to use: all receivers must declare all the formats that they can support (and thus read), so that all the senders can see what format can be used. Because all participants must always be able to handle the BIS, it is not possible that two participants don't find at least one common format.

(* ) The exact name of this register is SMP (Service Metadata Publisher). In fact this is not a single big register, rather a set of registers, publishing the same kind or information the same way, so they behave collectively as if they were one single register.

Customers receive e-invoice and e-credit note

All enterprises implementing inbound e-invoicing, like all Belgian public sector entities, register the e-invoice and e–credit note receiving capability in this registry. The exact description of the receiving capabilities, looks like:

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0::2.1

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol4a:ver2.0::2.1

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:www.cenbii.eu:transaction:biitrns014:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0::2.1

As you can see, and as you could expect in the context of e-invoicing, these records are suited for automatic processing, NOT for discussions between human beings.

Suppliers receive response

All enterprises implementing outbound e-invoicing, like the suppliers of the Belgian public sector entities, are invited to register the appropriate receiving capability in this registry. The exact description of the receiving capabilities, looks like: 

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##urn:www.cenbii.eu:transaction:biitrns071:ver2.0:extended:urn:www.peppol.eu:bis:peppol36a:ver1.0::2.1

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.

Non-compliance with the PEPPOL BIS format

Any e-invoice deemed compliant 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. Suppliers (e-invoice senders) and their IT subcontractors must therefore ensure that only e-invoices complying with the PEPPOL BIS format are sent.

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.

Business Response: contents of the MLR

The Response generated by the Belgian public sector, contains a response code, that provides a high-level meaning of the response. It may be useful that the suppliers, or their IT colleagues or IT-suppliers, understand these codes. Here is the table that consolidates this information:

Business response: the supplier does not support the PEPPOL BIS MLR - see diagram, sequence 3a

As explained in the previous section, the supplier will receive the response electronically only if he has registered the PEPPOL MLR Receiving capability. If it is not (yet) the case, then, as the flow 3a in the diagram above illustrates, Mercurius foresees an alternative delivery mode: email. Mercurius will look into the original e-invoice for the email address of the supplier, and will send the Response information contained in the MLR, in a human-readable format, to this email address. The email address is extracted from the following e-invoice UBL Data element:

Invoice/AccountingSupplierParty/Contact/ElectronicMail

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

The Mercurius platform includes a specific component that validates any document (incoming AND outgoing) from a business point of view. That is, it controls certain characteristics of the contents of the document. If any of these contents violates one of these validation rules, Mercurius rejects the document on behalf of its final recipient. The recipient is not informed of this rejection. The sender receives a response notifying rejection and motivation (the response document).

The checks carried out are as follows:     

• duplicate: if Mercurius has already received the same combination DocumentID-DocTypeID-SenderID-ReceiverID, it considers it a duplicate and rejects it. It issues a response code 380:3 (or 81:3 for credit notes) (* ). The original document can still be retrieved.     
• date of issue in the future. It issues a response code 380:4 (or 81:4 for credit notes)(* )
• the DocumentID is longer than 250 characters. It issues a response code 380:4 (or 81:4 for credit notes)
• the DocumentID contains exotic characters (that is, not in the 7-bit ASCII table.  It issues a response code 380:4 (or 81:4 for credit notes)

(* ) This rejection is justified by the accounting obligations to which they are subject to the issue of an invoice in due form.

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.

Performing tests

Because generalization of e-Invoicing and e-Procurement is a new topic, there is a legitimate need to perform tests. However, many aspects and parts of the solutions (both in the public and in the private sector) are relatively new, so it often makes tests difficult to organize  / delicate to interpret. Therefore, the Government invested heavily in a robust and controlled end-to-end test infrastructure. This makes tests of the b2g e-invoicing easy. Additionally, a lot of the components of this test infrastructure, can be reused by private sector entities, free of charge, to check that their part of the solution is indeed fully compliant.

Information for suppliers

If your outbound invoicing system has a test environment, or is able to produce invoices for test purposes (meaning they won't be booked for real) and to the test environment of the customers, then you have what it takes to send test invoices to the public sector.

To send test invoices to the test systems of the government:

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

Additional Information for the IT sector

IT sector representatives can use resources available on the web to validate their systems. There are many online format validation tools. These tools validate the PEPPOL BIS format, not the content. However, it is strongly recommended to validate the capability to produce documents with the valid format, separately from the content aspects.

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.

User assistance and support

Mercurius is a public service. It is potentially used by 50.000 suppliers and 5.000  customers, or even at a larger scale, considering the rotation of the suppliers of the public sector. These figures provide the levels of magnitude of the support needs. A very wide range of public and private entities are eligible to use the platform, and to raise support issues. Considering this, it is critical for BOSA DTO to make sure that the support is properly scoped, described, organized and used.

Scope

The Government provides assistance to the enterprises and to the public sector entities, about the use of the Mercurius Platform and its Portal.

It also provides information to help familiarize with the PEPPOL interoperability framework. However, this assistance is limited to common knowledge. It is not in the missions of the Government to provide advanced technical support to persons setting up PEPPOL solutions or marketing them.

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

Even though the e-invoice travels electronically, it still is an invoice first of all. You still should contact your procurement representative at the customer, when you have questions about the processing of the invoice. Was it received, was it approved, ... .  If there is a technical problem with the e-invoice, unless the invoice did not arrive on Mercurius, your procurement representative will be able to answer your questions.

If the e-invoice did not arrive on Mercurius, then in most situations it is an issue with your IT solution provider or Access point (AP) (internal or external), and it should be discussed with him.

This being clarified, here is a description of the assistance and support facilities delivered by the Government.

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.