This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
PEPPOL Message Responses
Invoice message responses — in PEPPOL or otherwise — can potentially solve some big problems.
Most importantly, perhaps, they stop companies from needing to follow-up on clients or customers regarding the status of their invoices.
If you are in some way concerned about this problem, or simply want to improve your invoicing processes, then read on!
PEPPOL Message Responses for Invoices
The age of e-invoicing and digital data exchange is rapidly growing in relevance for businesses.
And PEPPOL is, almost as quickly, establishing itself as the central European invoicing platform. In fact, it might even establish itself as the central global platform at some point.
There are many reasons for PEPPOL’s emergence as such a big player in the e-invoicing world.
But one of these reasons is its up-to-date technical features – some of which, this article will describe.
PEPPOL’s supported message responses are the technical features in question. These responses include: Transport acknowledgements (Ack), message level responses (MLRs), and Business Level Responses (or Invoice Responses).
Commonly Used Invoice Message Responses
PEPPOL supports 3 basic message response types, which each perform different functions:
1. Transport Acknowledgements (Acks)
ACKs are almost always sent by invoice recipients and inform senders of invoices whether or not their document/invoice has been successfully sent.
PEPPOL and Invoice-Portal always process these automatically for userse.
2. Message Level Responses (MLRs)
Inform senders of invoices whether or not their invoice has been structured in the correct way. Correct structure is based on agreed specifications (between the invoice’s sender and receiver). MLRs are often sent, although the German ZRE and OZG-RE portals do not yet process them. However, both ZRE and OZG-RE are planning to process MLRs in 2022!
Similarly, Invoice-Portal will be ready to process them at the same time.
3. Business Level Responses (or Invoice Responses)
Inform senders of invoices about the status of their sent invoice. Status types include: Accepted, Rejected, Validating, or Paid.
BLRs are quite rarely sent by invoice recipients. PEPPOL is programmed to process them, but administrations usually contact invoice senders directly if they have a problem.
Each of the 3 PEPPOL message responses follow specific standards. This is to protect the security and integrity of PEPPOL users’ data.
PEPPOL always implements up-to-date standards and protocols to handle the data of its users responsibly and reliably. And PEPPOL message responses are no exception.
To fully understand the functionality of these message responses, though, it is useful to refresh your understanding of the PEPPOL invoicing process. In particular, it is useful to refresh your understanding of PEPPOL’s ‘Four Corner Model’.
When Message Responses Are Necessary
PEPPOL handles sensitive, and often important data. So it is vitally important that PEPPOL users feel confident about that process.
PEPPOL support message responses for every step of the data exchanging process. These messsage responses can serve to assure and confirm PEPPOL is responsibly handling the data of its users.
The message responses generate and deliver at different times and for different purposes. This visual outlines those times and purposes:
As you can see:
1. Ack messages send after the document sends. And the Ack transports between the invoice sender’s access point and the invoice receiver’s access point.
2. MLR messages sends after the invoice/document sends. But they send BEFORE the document is received by the recipient. The MLR message sends between the sender’s and receiver’s respective messaging systems. These are usually their respective PEPPOL access points; but sometimes integrates into ERP/CRM/EDI systems.
3. BLR messages usually transport between the sender’s and receiver’s access points (or, sometimes, their ERP/CRM/EDI systems). They send at different times, depending on the progress of the invoice’s processing.
PEPPOL’s Message Responses
Here are explanations for each Message Response’s functional and technical features:
1. Ack (Transport acknowledgement) (Corner 3 to Corner 2)
What is an Ack?
An Ack is an automated message response for the sender of a message/document/invoice. PEPPOL supports the sending of these message types, and Invoice-Portal also processes them for its users.
What Does an Ack Do?
An Ack tells invoice senders if their invoice has delivered successfully (or not).
If the invoice sent successfully, the invoice sender will receive an Ack to inform them of that. But if the invoice has failed to send, then ther invoice sender will receive an Ack to inform them of that.
It is kind of similar to how you receive an automatic email from online stores. When you order some product(s) online for delivery, you will get an email confirmation that you have ordered.
But there is a key difference between an online shopping email confirmation and an Ack (of course!).
The difference: information communicated by Acks requires added security. And PEPPOL, aware of this, make sure that security is in place.
It is also worth noting what Acks do NOT do, though:
If you format your invoice incorrectly, Acks won’t inform you of that (see MLRs for this function).
How Does an Ack Send?
PEPPOL’s Ack message responses send using the messaging standard AS4.
What is AS4? AS4 is a widely used and trusted standard for B2B & B2G e-messaging.
PEPPOL’s utlilisation of AS4, then, further evidences PEPPOL’s up-to-date nature.
(Click here for more info on AS4).
AS4 refers to an Ack as a SignalMessage.
There are three types of SignalMessage:
-
- SignalMessage/Receipt
- SignalMessage/Error
- SignalMessage/PullRequest (not used in PEPPOL)
A SignalMessage automatically responds to the success (or failure) of data transmission. That success or failure is tracked by PEPPOL.
But an Ack Is Not An Ordinary Confirmation Message…
Acks, in line with the AS4 protocol, protect and secure users’ data. They assure senders and receivers that their documents are processed without problems.
Nobody can pretend that they sent a document with the existence of Acks. And nobody can claim they didn’t receive documents, either. Acks ensure efficiency in PEPPOL’s digital B2B and B2G messasging processes.
How an Ack Works:
-
- The sender sends their document. The document then receives its own unique ID (automatically by PEPPOL and in the Invoice-Portal).
- A ‘SignalMessage/Receipt‘ automatically sends to the sender IF the document sends successfully…
- OR a ‘SignalMessage/Error‘ automatically sends to the sender if the document sends unsuccessfully.
And that’s it! Quite simple, really.
That simplicity is the beauty of PEPPOL’s Acks. Plus, the security and up-to-date-ness of the AS4 technology guarantees the quality of service.
The use of Acks is just one small reason why PEPPOL is dominating the e-invoicing world.
You could even say that PEPPOL is becoming a key player in the entire, new-look, digital world of 21st Century business!
And that’s it! Quite simple, really.
That simplicity is the beauty of PEPPOL’s Acks. Plus, the security and up-to-date-ness of the AS4 technology guarantees the quality of service.
The use of Acks is just one small reason why PEPPOL is dominating the e-invoicing world.
You could even say that PEPPOL is becoming a key player in the entire, new-look, digital world of 21st Century business!
2. MLR (Message Level Response)
What is an MLR?
MLRs are very important for some PEPPOL users. Some might say they are the most important of all 3 message responses.
MLRs confirm to invoice senders that they formatted the documents correctly … or incorrectly!
What does an MLR do?
MLRs inform invoice senders about their invoice’s structure.
If the sent invoice passes validation, it means the sender correctly structured the invoice.
If the sent invoice fails validation, it means the sender incorrectly structured the invoice.
And that is the basic function of an MLR: to inform invoice senders about the structure of their documents.
Specifically, MLRs tell invoice/document senders that their document either:
-
- Has some errors and therefore failed the validation process.
- Passed the validation process and has no errors.
- Sent successfully, but hasn’t undergone the validation process yet.
MLRs only tell senders of invoices/documents’ that the STRUCTURE of the invoice has been validated.
And correct structure, alone, does not mean your invoice is 100% correct.
MLR confirmations do NOT mean recipients have accepted your document. You will have to wait for your Business Level Response to know about that.
What DOESN’T an MLR do?
MLRs do NOT confirm the correctness of your document’s CONTENTS.
This is because document validators are only capable of analysing the STRUCTURE of your invoice. And MLRs only confirm the validation of your invoice.
So, if you entered the wrong details into an agreed-upon mandatory field of your documents, then the MLR will not tell you.
But if you didn’t enter any information into one of agreed-uopn mandatory fields, then the MLR will inform you of that.
(The mandatory fields of documents are agreed-upon between you and your invoice’s recipient.)
The Scope of an MLR – In Detail
Errors Within The Scope Of an MLR
According to PEPPOL, the following errors can cause an MLR to reject an invoice:
-
-
- Standard Compliance violations
- Validation error of type fatal error
- Validation error of type warning (MLRs don’t rejectdocuments for warnings, but usually report warnings alongside other errors – especially fatal errors)
- Uploaded the wrong version of thedocument.
-
In short: any structural errors, or mandatory fields not completed, will result in an MLR rejecting your invoice.
Errors Outside The Scope Of an MLR
According to PEPPOL, some errors cannot cause an MLR to reject your invoice. Such errors, then, will be informed to you by an Ack or a Business Level Response.
These error types include:
-
-
- Unknown sender (identified by: Transport Acknowledgment/Ack)
- Unknown receiver (identified by: Transport Acknowledgment/Ack)
- Wrong version of envelope (identified by: Transport Acknowledgment/Ack)
- XML schema validation error in envelope (identified by: Transport Acknowledgment/Ack)
- XML not structured or formed well (identified by: Transport Acknowledgment/Ack)
- The encoding used is not supported for this document (identified by: Transport Acknowledgment/Ack)
- Wrong value in reference fields (identified by: Business Level Response).
Reference fields that might have a wrong value include:- Order number used in the invoice
- Project or customer reference used in the invoice
- Contract ID reference used in catalogue.
-
How Is an MLR Sent?
In PEPPOL, MLRs use UBL Application Response 2.1 messages.
For more information about the technical side of UBL Application Response 2.1 messages, click here.
How Does an MLR Work?
- The sender sends their document. The invoice is automatically given its own unique ID by PEPPOL.
- If the structure of the invoice has been successfully validated, then the sender will be informed in their messaging system.
- But if a structural error has been identified by the MLR, then the sender will be informed in their messaging system.
Of course, the only errors that the MLR will inform you of are the errors within the scope of an MLR (as described in this article).
Do ZRE & OZG-RE Process MLRs?
The ZRE and OZG-RE portals will start processing MLRs at some point during 2022.
And, when they do, Invoice-Portal will be programmed to process them too.
3. Business Level Response (or, Invoice Response)
What is a Business Level Response?
This response type is about the current status of the sent document.
Business Level Responses serve to let the sender know how close their invoice is to being fulfilled.
What does a Business Level Response do?
Business Level Responses tell invoice sender the responses of their recipient.
Depending on the actions of the recipient, the invoice sender will receive one of the following status codes:
-
- AB: basic message acknowledgement
- AP: invoice accepted
- RE: invoice rejected
- IP: in progress
- UQ: under query
- CA: conditionally accepted
- PD: paid/completed
When Will I Receive a Business Level Response/Invoice Response?
You must receive a Business Level Response within 3 working days. This is according to PEPPOL BIS invoicing requirements.
However, you might not receive one at all. BLRs are generally not sent by administrations. This is because they aren’t absolutely necessary, so businesses don’t send them.
Also, in the case of an incorrect invoice, administrations often contact invoice sender directly, without the need for a BLR.
Will I Receive Reasons For My Rejected Invoice?
Yes. Rejected invoices require information to be provide by the recipient.
It is vital for recipients to provide reasons invoice rejection. The information should explain to senders what they need to change in the invoice.
Or, in case of a incorrectly rejected invoice, it allows a conversation to be started between the invoice’s two parties.
In any case, providing information moves the invoicing processing along much more smoothly.
How Are Business Level Responses Sent?
Like the MLRs, Business Level Responses are sent using the UBL Application Response 2.1 protocols.
This ensures that the messages follow the universal standards for B2B and B2G data exchange. And, hopefully, those standards will remain in place for the coming decades.
Receive your Message Responses in one place with Invoice-Portal::
In Conclusion
PEPPOL Message Responses keep users informed. They makes sure users know all about the success or failure of their communications.
Without message responses, there might be a lot of confusion. Senders and receivers of invoices might be concerned that they haven’t received an invoice or a confirmation. The message responses let them know exactly what is happening with the invoices. This prevents nasty messages and disagreements between two parties!
So they are clearly an important part of the data exchanging process because they fulfill basic requirements of data exchange.
Moreover, the technology PEPPOL uses for its messaging is up-to -date. AS4 (used for PEPPOL’s Ack messages) is expected to provide interoperability between businesses for decades to come. And UBL 2.1 will hopefully do the same.
What Is AS4?
AS4 messages are an attempt to make digital data exchange easier and more reliable. As a result, more and more businesses are adopting the standard. So much so, in fact, that it may be on course to becoming the common standard for global messaging.
Adopting AS4 now will have you prepared and ready for the future of digital business.
AS4 is a structure for messages regarding data exchange. It is considered a simple, secure, and efficient messaging standard, evidenced by the major organisations that utilise it – Australian Government, the European gas industry, and PEPPOL, to name but a few.
It was designed based on AS1, AS2 (in particular), and AS3 before it, with a view to enable international interoperability between businesses and governments for decades.