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’s Message Responses
Here are explanations for each Message Response’s functional and technical features:
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.
Receive your Message Responses in one place with Invoice-Portal::
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.