People may be confused by the invoice status information (* ). FAQ "Was my invoice duly received by the customer? What is the status?" provides key-info about this subject. Current FAQ adds some useful insights how the status changes and who to get in touch with, if needed.
- The initial status of any invoice received by Mercurius its "received".
- Then the customer must approve the invoice. Consequently, there are 2 options:
- option 1: he approves the invoice (meaning: the invoice is related to a valid order, the delivery is confirmed, the amount is correct...). Then the status changes to "processed" (or approved/accepted).
- option 2: he rejects the invoice (for instance, because there is information lacking, such as the order number; or because the amount is not correct...). then the status changes to "rejected".
- The status changes only if the customer notifies the decision. Several customers do not yet do so. In this case, the status does not change, it stays "received".
- In very exceptional situations, such as a duplicate invoice, Mercurius intercepts the invoice (meaning: he does not transfer it to the customer), and rejects it automatically.
- In case you need more details about he invoice status, contact your purchasing responsible at the customer. Notice that he/she has access to the same information as you on the Mercurius Portal - provided he/she took the necessary administrative steps within his/her own organisation. So don't hesitate to use the Portal to share invoice information and help resolve misunderstandings or disputes.
(* ) The same applies to credit notes.
All invoices sent to the public sector are received by Mercurius. This allows suppliers to track the status of all the invoices they send to all public-sector entities on the Mercurius Portal (NB: this offers customers similar track-and-trace functions).
When an invoice is initially received by Mercurius, it gets the status "received".
From then on, the invoice is transmitted to the customer. The customer must process the invoice, in order to pay the supplier. This processing involves an approval cycle. During this approval cycle, the invoice will be either approved or rejected. Usually, the customer communicates the result of the approval to the supplier: He transmits a response message to Mercurius, and Mercurius forwards this message to the supplier. At the same time, Mercurius also updates the status of the invoice on the portal: "processed" (for approved invoices) or "rejected" (for rejected invoices). In case the invoice is rejected, the response message is expected to contain the description of the reason of the rejection. The supplier can correct his/her invoice accordingly.
Mercurius uses a standardized message type to forward the response to the supplier. A supplier who sends his invoices electronically (using the PEPPOL interoperability framework), can receive this standardized message directly in his computer system for automatic processing. This depends on the computer system of the supplier. Suppliers are invited to consider this machine-to-machine integration opportunity, because machine-to-machine integration is the condition for the realization of the benefits of e-invoicing. They should contact their IT supplier or responsible, who will either know how this works from a technical perspective, or have to acquire this knowledge.
Currently, Mercurius uses a PEPPOL BIS Message Level Response (MLR). Notice that, in the near future, it will upgrade to a new, more specific type of message, the "invoice response", as soon as it is available for use over the PEPPOL network.
Exception 1: the supplier is not (yet) able to receive the response
As long as this kind of integration is not generalized, Mercurius uses the following "second way" to forward the customer response to the supplier: It extracts the supplier email contact data from the original invoice, and sends the response to this mail address. This happens only if the supplier does not yet support the fully electronic flow described above. If the supplier hasn't provided an email contact data in his/her invoice, then the only way for him to know the status, is to log into the Mercurius Portal.
Exception 2: the customer is not (yet) able to send a response
Several customers are not yet able to send the response. In this case, the invoice status that is visible on Mercurius Portal, will stay on "received", although the invoice can be rejected, approved, or paid. And, of course, Mercurius won't be able to send the response to the supplier.
Exception 3: the invoice contains incorrect/unprocessable data
Before forwarding the invoice to the customer, Mercurius checks that it does not fall in the following list of exceptions:
- it is a duplicate of a previously sent invoice
- it has an issue date that is in the future
- the invoice number is longer than 250 characters
- the invoice number uses special characters (technically: contains characters that are not in the ASCII-7bits table)
If the invoice falls in one of these categories, Mercurius is programmed to
- stop the invoice - it is not forwarded to the customer,
- rejects the invoice, and
- send a response, using the mechanisms described above, to notify the supplier.
For suppliers who need more information
In case you need more details about the invoice status, please contact the purchasing responsible of your customer. You can identify this person on the tendering documents (unless the invoice relates to a more simplified procedure, in which case you, or one of your colleagues, probably know the purchasing responsible directly).
Notice that he/she has the possibility to access the same information as you on the Mercurius Portal. He/she can get access at the cost of administrative steps within his/her own organization, like you probably did (for more details, see FAQ How get access to Mercurius portal?). So don't hesitate to use the Portal to share invoice information and help resolve misunderstandings or disputes.
For technical persons who need more information
Get more technical info about how the message looks like at Responses from the public sector (Message Level Response - MLR).