Key takeaways
- The Peppol MLR (Message Level Response) is the acknowledgement through which the recipient reports on the technical validation of a received document.
- It is expressed in the UBL ApplicationResponse 2.1 format and travels the Peppol network like an invoice or an order.
- It carries three main statuses: acknowledgement (AB), accepted (AP) and rejected (RE), with a rejection required to state the reason.
- The MLR is neither a transport acknowledgement nor a business response: it only concerns the message's compliance.
An invoice sent over Peppol does not vanish into an opaque pipe. The network provides a return path to tell the sender what became of its document on arrival: that is the role of the Peppol MLR, or Message Level Response. Understanding this message means knowing how to read what your software shows you after a send, and telling a plain "received" apart from a "validated" or a "rejected, here is why".
The topic becomes concrete with the B2B e-invoicing mandate in Belgium, in force since 1 January 2026: once invoices travel through Peppol, the acknowledgement stops being a technical detail and becomes the proof that the document arrived and passed the checks. This article describes what the MLR contains, what it does not say, and where it sits among the network's other returns.
What a Message Level Response is
The Message Level Response is a Peppol document in its own right. It is defined by the Peppol BIS Message Level Response 3.0 profile published by OpenPeppol, under transaction identifier Trdm071. Its function fits in one sentence: it lets the recipient of a business document report the result of its validations to the sender.
Technically, the MLR does not invent a format: it is built on the UBL ApplicationResponse 2.1 document, a standard XML structure designed precisely to carry a response to a received message. It travels the network like any other Peppol document, wrapped in an envelope and transmitted over the AS4 protocol between access points. The sender and recipient of the MLR are simply reversed compared with the original invoice: the party that received the invoice issues the MLR, and the party that sent it receives it.
The three levels of return on Peppol
The most common confusion mixes up three different returns that answer three distinct questions. The table below places them.
| Transport acknowledgement | MLR | Business response | |
|---|---|---|---|
| Confirms delivery to the access point | |||
| Reports on the document's technical validation | |||
| Expresses a business decision (agreement, dispute) | |||
| Carried by a UBL ApplicationResponse document |
The transport acknowledgement is produced by the AS4 protocol itself: it is the signed receipt confirming that one access point handed the message to the next. It says nothing about the content. The MLR sits one level up: the document has been opened, read and run through the validation rules. Finally, the business response, a separate document called the Invoice Response, carries a decision on the merits: is the invoice accepted for payment, disputed, tied to an expired contract? The MLR never deals with that dimension.
What an MLR carries: the status codes
The core of the MLR is its status code. The Peppol profile keeps three main codes, taken from a standardised code list, each answering a specific state of the processing.
The statuses of a Message Level Response
AB: acknowledgement
The message has been received and identified, but not yet validated on the merits. A plain confirmation that it arrived.
AP: accepted
The document passed validation with no fatal error. It complies with the UBL syntax and the Peppol rules.
RE: rejected
The document contains one or more fatal errors that prevent processing. The reason for the rejection must then be given.
The rule on rejection is worth stressing: when an MLR returns the RE status, the error description is mandatory. The recipient cannot simply refuse; it must state what went wrong: an XML schema error, a Peppol rule not met, an incorrect document version. That is what makes a rejection actionable: the sender knows what to fix before resending.
Conversely, a mere warning does not cause a rejection on its own. The document stays accepted, with the warning flagged for information only. Only a fatal error flips the status to RE.
When the MLR comes into play
The MLR is not instantaneous: it belongs to the document's life cycle, after delivery and once the recipient has run its validation. The typical sequence is as follows.
- 1
Issuing the invoice
Step 1Your software produces the invoice in the Peppol BIS Billing 3.0 profile and hands it to your access point.
- 2
Routing and transport acknowledgement
Step 2The network routes the document to the recipient's access point; the AS4 protocol confirms delivery.
- 3
Validation at the recipient
Step 3The received document is checked: UBL syntax, Peppol rules, conformance consistency.
- 4
Issuing the MLR
Step 4The recipient returns a Message Level Response with the AB, AP or RE status, and the reason on a rejection.
This place in the chain explains why the MLR is useful even when everything goes well: it closes the loop. Without it, the sender only knows the document was delivered, not that it was accepted. With it, a rejection is caught early and fixed, instead of being discovered weeks later through a missing payment.
Send your Peppol invoices and track their acknowledgements without touching XML
YouInv generates your compliant invoices, sends them over the Peppol network and interprets the Message Level Responses for you, in plain terms.
What the MLR changes for your business
As with the rest of Peppol, you do not have to handle the MLR by hand. Compliant software generates the acknowledgement when you receive a document, sends it, and interprets the ones you receive. What you see is a readable result: invoice accepted, or rejected with the reason. The UBL ApplicationResponse file stays under the hood.
What matters, in practice, is picking a tool that handles this return, and not only the send. Software that ships invoices without being able to read a rejection MLR leaves you in the dark: you believe you have invoiced, when the document was refused over an error no one saw. The ability to receive, display and trace Message Level Responses is therefore a concrete criterion when choosing or upgrading your solution.
One shift is worth noting, finally: OpenPeppol has defined a Message Level Status (MLS), built on the same foundations as the MLR but broadened to also cover delivery towards the final recipient, and exchanged between service providers. It is the direction the network is moving in; the principle stays the same, reporting on the fate of a message, but the scope extends beyond conformance validation alone.
Further reading
- Peppol BIS Billing 3.0: what the format contains: the invoice profile that the MLR acknowledges.
- Peppol access point: what it is for and how to connect: the link that carries invoices and acknowledgements.
- Understanding the Peppol network in 5 minutes: the four-corner model and the role of access points.
The reference source prevails: the Peppol BIS Message Level Response 3.0 specification published by OpenPeppol.
What is the Peppol MLR (Message Level Response)?
The Message Level Response (MLR) is a Peppol document through which the recipient of an invoice or order tells the sender the result of the technical validation of the received message. It is an acknowledgement expressed in the UBL ApplicationResponse 2.1 format, carried over the Peppol network like any other document.
Which status codes can the MLR return?
The MLR mainly carries three codes: AB (acknowledgement, message received but not yet validated), AP (accepted, the document passed validation with no fatal error) and RE (rejected, the document contains fatal errors). On a rejection, the error description is mandatory.
Is the MLR the same as a transport acknowledgement?
No. The transport acknowledgement (the AS4 receipt) only confirms that the message reached the recipient's access point. The MLR goes further: it reports on the validation of the document's content, that is, its compliance with the UBL syntax and the Peppol rules.
Is the MLR a business response to the invoice?
No. The MLR does not say whether the invoice is accepted on the merits (agreement on the amount, dispute, expired contract). It reports only on technical and conformance validation. A response on the merits is a different document, the business response (Invoice Response).
Do I have to handle the MLR myself to invoice with Peppol?
No. Compliant invoicing software generates, sends and interprets MLRs for you through an access point. You see the result in a readable form (invoice accepted, or rejected with the reason), without reading the UBL ApplicationResponse file.
