What is the Peppol Message Level Response (MLR)?
A Message Level Response (MLR) is a Peppol business document (profile Trdm071) used by the BusinessDocumentReceiver to inform the BusinessDocumentSender about the result of its validations. When a document is received, the receiver can validate it against XML schemas and business rules. An MLR reports one of three outcomes:
Key Concepts and Functions of MLR
The MLR is a response message sent back to the sender and contains information about whether the document passed validation, whether it was accepted, or if it was rejected due to errors in the document’s structure or business rules.
The main goal of MLR is to inform the sender about the status of the document, including whether it meets the required standards. MLR is not just a structure check, but it involves a full validation process, which includes:
- Check for all mandatory fields
- Verify the document complies with agreed standards and schemas (e.g., Peppol BIS, UBL)
- Ensure the correct format and version of the document
Types of Messages in Peppol
In the Peppol network, there are several types of messages ensuring transparency in the document exchange process:
MLS (Message Level Status): A simple message that informs the sender whether the document has been accepted for further processing.
MLR (Message Level Response): A more detailed response, providing information on whether the document meets the required structure and is ready for further processing. It also informs the sender about validation failures, including details about errors and reasons for rejection if applicable. The response will be sent with status codes like “AP” (Accepted), “AB” (Acknowledged), or “RE” (Rejected).
BLR (Business Level Response): The final response that informs the sender of the document’s acceptance, rejection, or further processing.
When is MLR Used?
MLR is used when a document has been transmitted through the Peppol network, and its structural validity needs to be verified. This is especially important at the initial stage, when the document is still not fully accepted for processing or approval.
Optional: Sending an MLR is optional. It is only sent if the sender of the original business document has requested an MLR or if validation fails with fatal errors
✓ Requested MLR: If requested, the receiver sends an MLR with AP (accepted), AB (acknowledged) or RE (rejected) depending on the outcome.
✗ Not requested: If the sender did not request an MLR, the receiver should only send an MLR when fatal validation errors are found (response code RE).
Structure and Format of MLR
MLR in Peppol is transmitted as a structured message in the UBL Application Response 2.1 format. This is a standard format used to describe the structure of messages transmitted over the Peppol network.
The MLR message may contain the following elements:
Status Code — a code indicating the result of the processing (e.g., “Accepted”, “Rejected”, “Error”)
Status Description — a description that clarifies the status code
Error details — details about errors if the document failed validation
Scope of Validations
An MLR covers validation of the received document’s XML schema and business rules. The following situations trigger rejection:
Fatal errors in the document’s structure.
Standard compliance violations.
Wrong document versions.
Issues such as unknown sender, unknown receiver, or incorrect envelope are handled by Transport Acknowledgements (Ack) and are outside the scope of MLR.
Parties Involved
-
BusinessDocumentSender / MLRReceiver: The organisation sending the original document and receiving the MLR.
-
BusinessDocumentReceiver / MLRSender: The organisation receiving the document and sending the MLR.
The MLR is exchanged directly between end-users via their service providers (C2 and C3). It should not be confused with the Message Level Status (MLS), which is exchanged only between service providers.
Message Structure and Examples
Below are examples of MLR messages in XML format:
Example: Accepted document
<ApplicationResponse xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2">
<cac:DocumentResponse>
<cac:Response>
<cbc:ResponseCode>AP</cbc:ResponseCode>
<cbc:Description>The document was validated successfully and will be processed.</cbc:Description>
</cac:Response>
<cac:DocumentReference>
<cbc:ID>EnvelopeID-12456789</cbc:ID>
</cac:DocumentReference>
</cac:DocumentResponse>
</ApplicationResponse>Example: Rejected document
<ApplicationResponse xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2">
<cac:DocumentResponse>
<cac:Response>
<cbc:ResponseCode>RE</cbc:ResponseCode>
<cbc:Description>The document was rejected because the mandatory field 'InvoiceNumber' is missing.</cbc:Description>
</cac:Response>
<cac:DocumentReference>
<cbc:ID>EnvelopeID-12456789</cbc:ID>
</cac:DocumentReference>
</cac:DocumentResponse>
</ApplicationResponse>
Interaction of MLR with Other Peppol Messages
MLR is an integral part of the entire document exchange process in Peppol, used for pre-validation before full acceptance. Here’s how it works:
1Transport Acknowledgement (Ack): When a document is sent via the Peppol network, the sender first receives an Ack message confirming that the document was received by the system.
2Message Level Response (MLR): The next step is the MLR, which informs the sender about the status of the document. If structurally correct, MLR confirms it. If there are errors, MLR provides details.
3Invoice Response (BLR): After the document has been fully processed, the sender receives the final status: accepted, rejected, or still under processing.
Importance of MLR for Business
The Peppol Message Level Response plays a crucial role in automating and optimizing electronic invoice and document handling processes. With MLR:
Conclusion
Peppol Message Level Response (MLR) is a crucial element in ensuring the reliability and correctness of document exchanges in the Peppol network. It helps ensure that both the sender and the receiver are aligned regarding the document’s status, allowing for quick corrections and minimizing delays in the invoicing process.
