Peppol MLS / MLR

This page contains some general thoughts about the Message Level Status (MLS) and its predecessor, the Message Level Response (MLR). MLS is mandatory for all Peppol Service Providers, whereas MLR is deprecated and will be retired. The transition is governed by the two OpenPeppol plans Peppol MLS Phase-in v1.0.0 and Peppol MLR Deprecation and Phase-out Plan v1.0.0, both published on 2026-07-02.

MLS - Message Level Status

Introduction

The intention of the MLS is to be a message between C2 and C3 instead of a message between C1 and C4 like the MLR. This makes it easier to mandate it, because only Service Providers are forced to support it. As the receiver of an MLS message (C2) it is recommended to forward the information on any specific way to your End User (C1).

The MLS is a regular Peppol document like Invoice or Order and as such needs to be transmitted like any other Peppol document wrapped in an SBDH and send via AS4.
Different to the MLR, the MLS is not optional - every Service Provider that exchanges Peppol Document Types must be able to send and to receive MLS messages.
Sender and receiver of an MLS are identified with the OpenPeppol Service Provider Identification Scheme (SPIS), meaning participant identifier scheme 0242 - no other scheme is allowed.

Relevant specifications

All the documents below are publicly available at https://docs.peppol.eu/edelivery/:

• Peppol MLS Specification v1.1.0 - the primary technical specification governing MLS message structure, process and rules
• Peppol Business Message Envelope (SBDH) v2.0.2 - introduces the MLS Customisation Options MLS_TO and MLS_TYPE and the corresponding reserved SBDH attributes
• Peppol Network Policy (PNP) v1.0.0 - a completely new document that introduces the mandatory MLS rules MLS-1 to MLS-4, the timing milestones M1 to M3 and the Service Level Requirements SLR MLS-1 and SLR MLS-2
• Peppol MLS Phase-in v1.0.0 - defines when things need to happen
• Service Provider Operational Guideline on MLS (SPOG MLS) - defines how things need to be done
• Peppol MLR Deprecation and Phase-out Plan v1.0.0 - the counterpart for retiring the MLR

Obligations from the Peppol Network Policy (PNP) v1.0.0

The PNP is an entirely new document, so every rule in it is a new obligation for Service Providers:

• Rule MLS-1 - every Service Provider offering the exchange of Peppol Document Types MUST support both sending and receiving MLS messages. MLS support is no longer optional.
• Rule MLS-2 - every Service Provider MUST register the MLS receiving capabilities in an SMP using its SPIS Main ID participant identifier (0242:<6-digit-number>). Additional SPIS Use Case ID "MLS" identifiers (e.g. 0242:<6-digit-number>-MLS) MAY be registered.
• Rule MLS-3 - the default MLS usage is FAILURE_ONLY, meaning only negative MLS responses are sent. Positive MLS responses MUST NOT be sent unless the sending Service Provider opted in via MLS_TYPE=ALWAYS_SEND.
• Rule MLS-4 - MLS messages MUST be sent as soon as the status is known. Artificial or intentional delays are not permitted. If the transmission is temporarily impossible, the message must be queued and retried as soon as conditions permit.

Additionally a new timing framework with three milestones is introduced:

• M1 - AS4 Timestamp of the original business document transmission at C2
• M2 - AS4 Timestamp of the MLS message transmission at C3
• M3 - Reception time of the MLS message at C2

Based on these milestones, two Service Level Requirements are defined, both measured monthly and both only applicable to business documents with a Payload Size < 10 MB:

• SLR MLS-1 - 99.5% of the MLS messages must have M2 - M1 ≤ 20 minutes
• SLR MLS-2 - 99.5% of the MLS messages must have M3 - M1 ≤ 25 minutes

Note: the SLRs require that you record all three timestamps and that you are able to relate an incoming MLS message to the matching outgoing business document. So besides the pure sending and receiving, monitoring and alerting are needed as well.

Two additional rules that are easily forgotten: all XML documents including MLS messages must use the UTF-8 character set (PNP rule XML-1), and an MLS message must never be sent in response to another MLS or MLR message (rule OP-MLS-03). Positive MLS messages (Response Code AP or AB) MUST NOT be sent before the delivery of the original business document to C4 was attempted (rule OP-MLS-12).

SBDH v2.0.2 - MLS_TO and MLS_TYPE

The Peppol Business Message Envelope (SBDH) v2.0.2 introduces two new optional fields in the SBDH of the business document, that influence how C3 has to respond with an MLS. Both keys are reserved SBDH attribute keys and MUST NOT be used for any other purpose.

• MLS_TO - allows C2 to specify an alternative participant identifier for receiving the MLS responses. If present and valid, C3 MUST honour it. The value must correlate to the SPIS Main ID of C2 from the Peppol AP Certificate - redirecting the MLS to a different Service Provider is not allowed. This is meant for Service Providers running multiple Access Points or Access Point instances.
• MLS_TYPE - allows C2 to request ALWAYS_SEND or FAILURE_ONLY. If the field is absent or invalid, the default FAILURE_ONLY from the PNP applies.

As C3 you need to parse and validate both fields from the incoming SBDH and apply the respective fallback chains defined in the SPOG MLS sections 5.1 and 5.2. As C2 you may optionally fill these fields in your outgoing SBDH.

Changes in the MLS specification v1.1.0

The phase-in is based on MLS specification v1.1.0. The relevant changes compared to v1.0.0 are:

• The SPIS scheme was standardised to 0242 - all MLS sender and receiver identifiers must use this scheme, no other Participant Identifier Scheme is permitted. So verify that all your MLS related SMP registrations use scheme 0242.
• The rejection reason list is now exhaustive - the list of situations in which C3 may issue a rejection MLS (Response Code RE) is a closed list. C3 MUST NOT reject documents for reasons outside of this list.
• Schematron updates - the participant identifier comparison is now case insensitive (rules SCH-MLS-09 and SCH-MLS-14) and the usage of scheme 0242 is enforced (rules SCH-MLS-11 and SCH-MLS-16).

The MLS phase-in plan

The phase-in plan defines three milestones and two phases:

• T1 - 2026-07-01 - start point; the specifications are effective and the phase-in clock starts
• T2 - 2027-02-28 - end of Phase 1 (8 months). The MLS receiving capability MUST be in production. The MLS sending activation window opens.
• T3 - 2027-03-31 - end of Phase 2 (1 month). MLS sending is mandatory and the SLRs are enforceable.

Phase 1 (T1 to T2) - be ready to send and receive MLS messages and have the SMP capabilities registered. MLS sending is not required in this phase, but MAY be activated early.

• Implement the parsing of MLS_TO and MLS_TYPE from the SBDH of incoming business documents, including the fallback logic
• Implement the MLS document creation and the AS4 transmission logic
• Implement the SML/DNS lookup and the SMP lookup for the effective MLS receiver participant identifier, to be performed prior to each MLS transmission
• Implement the MLS queuing and the retry with exponential backoff
• Deploy an MLS receiving endpoint that is reachable via AS4 and validate received MLS messages against the XML Schema and the MLS Schematron rules
• Implement the relation of an incoming MLS message to the matching outgoing business document
• Instrument the systems to record the timing milestones M1, M2 and M3
• Register the MLS receiving capabilities in an SMP for the SPIS Main ID participant identifier, using the exact Document Type Identifier and Process Identifier from the MLS specification chapter 9.1 - that is what "activating MLS receiving" means
• Test end-to-end in the Peppol Test Network and pass the mandatory Peppol Testbed MLS Test Suite

To finalise Phase 1, all Service Providers MUST have the MLS receiving capability registered in an SMP and operational, and MUST have passed the Peppol Testbed MLS Test Suite. Whoever did not complete Phase 1 by T2 is in breach of the PNP rules MLS-1 and MLS-2.

Phase 2 (T2 to T3) - start actively sending MLS messages. Sending MAY be activated before T2 once the Phase 1 implementation is complete and tested, and MUST be active for all Service Providers by T3. The 1-month window is explicitly meant as a transition buffer and not as a grace period for a delayed implementation. Whoever activated the sending must comply with the PNP rules MLS-3 and MLS-4 from the moment of the activation. The SLR measurement begins at T3, so the time before can be used to baseline the own SLR performance.

A note for Peppol Authorities that offer a Centralised SMP solution: they MAY mandate the registration of the SPID participants for local Service Providers, but they MUST NOT mandate it for foreign Service Providers, as many - especially international - Service Providers run their own SMP. If you are using a Centralised SMP, clarify with your Peppol Authority whether the MLS participant registration is handled centrally or whether you need to do it yourself.

Open Source software

My peppol-commons project offers the sub-module peppol-mls to deal with MLS messages. It allows to read and create the MLS payload in a consistent way. For the SMP lookup the same project has a peppol-smp-client module. Wrapping the MLS in SBDH and sending the message can be done with any compliant Peppol AS4 solution like phase4.

MLR - Message Level Response (deprecated)

Introduction

The MLR is a message between End Users (C1 and C4) executed by Service Providers (C2 and C3). The official specification can be found at https://docs.peppol.eu/poacc/upgrade-3/profiles/36-mlr/.
The MLR is a regular Peppol document like Invoice or Order and as such needs to be transmitted like any other Peppol document wrapped in an SBDH and send via AS4.
The MLR is an optional document and is NOT mandatory. So not every sender of a business document supports the reception of MLRs. To check if MLR reception is supported, an SMP lookup is needed.
Please note that the usage of C1, C2, C3 and C4 should be reversed to be precise but in this document, the usage of C1, C2, C3 and C4 always refers to the role for the transmission of the source document to avoid confusion.
Please note, that an MLR message can be send as a response to any business document as long as its reception is supported.

Scope

The scope in which the MLR MAY be used is clearly defined in the specification chapter 2.2. As the sender is obliged to only send valid (=validated) content, validation on receiver side is an optional task. And don't mix MLR with BLR (Business Level Response - e.g. Invoice Response) because they have different meanings.

Proposed technical process

The following process description shows a best practice process proposal. The assumption is, that receiver side validation was performed and the response should be transmitted back to C1. Note: as soon as MLS sending is activated, this process is superseded by MLS, because one business document MUST only be responded with either MLR or MLS, and MLS has priority (SPOG MLS chapter 3.2).

1. You validate synchronously (that's important) and found at least one error
2. You synchronously check if the sender of the business document (C1) supports MLR or not via an SMP query
3. Case 1 - Sender supports MLR:
   1. Send back a positive AS4 Receipt
   2. Create the MLR and trigger an explicit AS4 transmission of the MLR
      Note: make sure the AS4 Receipt is received by the sender BEFORE the MLR is send (asynchronous processing required)
   Case 2 - Sender does not support MLR:
   1. Send back a synchronous AS4 Error with the error details
   2. Note: do not use SOAP Faults but an AS4 SignalMessage with an Error element inside

The MLR phase-out plan

The phase-out is driven by one rule from the SPOG MLS chapter 3.2:

One business document MUST only be responded with either MLR or MLS. If a receiver can handle both MLR and MLS, the usage of MLS MUST have priority.

The direct consequence is, that the phase-out does not start at T3 but already at T2: as soon as a Service Provider activates the MLS sending, that Service Provider MUST stop sending MLR.

Phase 2 (T2 to T3):

• Whoever activates the MLS sending MUST immediately cease sending MLR for the business documents that are now responded to via MLS - the two obligations are mutually exclusive
• Whoever did not yet activate the MLS sending MAY still send MLR, but SHOULD prepare to stop
• By T3 all MLR document type registrations in the SMP should be removed, because keeping them after MLS is active creates potential for compliance ambiguity. Keep the ability to accept and process inbound MLR messages only for selected counterpart Service Providers that have not yet completed their transition.

Phase 3 (T3 to T4):

• From T3 all Service Providers MUST be sending MLS
• The only remaining permitted use of MLR is a last-resort fallback, limited strictly to the case that C2 has no MLS receiving capability registered in an SMP. As the MLS receiving capability is mandatory from T2, this case must be treated as exceptional and extremely rare.
• C3 MUST verify via SMP lookup before falling back to MLR
• MLR receiving capabilities may be started to be removed
• The eDEC Code List entry for MLR is marked as "deprecated"

From T4 onwards the MLR is fully retired: all MLR sending is prohibited without exception and no Service Provider is allowed to receive MLR messages. The eDEC Code List entry for MLR is marked as "removed" and the OpenPeppol Operating Office formally retires the MLR specification.

Open Source software

My peppol-commons project offers the sub-module peppol-mlr to deal with MLR messages. It allows to read and create the MLR payload in a consistent way. For the SMP lookup the same project has a peppol-smp-client module. Wrapping the MLR in SBDH and sending the message can be done with any compliant Peppol AS4 solution like phase4.

MLR vs. MLS

MLS provides the complete functional coverage of MLR - every situation that MLR handles is handled by MLS using the same Response Codes (RE for rejection, AP for acceptance and AB for acknowledgement), so no functional capability is lost in the transition. On top of that, MLS adds the following:

• Delivery failure towards C4 - MLR is limited to reporting the conformance validation result. MLS additionally covers the case that C3 is permanently unable to forward the document to C4, regardless of whether the document is technically valid. This is reported with Response Code RE and Status Reason Code FD (Failed Delivery) and is entirely outside the scope of MLR.
• Exhaustive rejection reason list - MLR has an open ended list of rejection reasons, MLS defines a closed list of Status Reason Codes (SV, BV, BW, FD), which improves the predictability for C2.
• Structured line level detail - both support line level error reporting, but MLS makes an issue location, an issue description and a Status Reason Code mandatory for each issue (rules OP-MLS-27 to OP-MLS-30).
• C2 as target receiver - MLS allows C2 to be targeted as the document receiver, MLR has no equivalent.
• Receiver directed routing via MLS_TO - MLR has no equivalent.
• Sender controlled response type via MLS_TYPE - with MLR the decision to send rests entirely with C3.
• Mandatory behaviour with SLRs - MLR sending is optional and has no timing requirements at all.
• Issue time with time zone - MLS requires an issue date (without time zone) and an issue time including time zone information (rules OP-MLS-17 and OP-MLS-18), MLR requires only a date.

The structural differences are equally relevant: MLR uses cac:SenderParty/cbc:EndpointID and cac:ReceiverParty/cbc:EndpointID with any Electronic Address Scheme (EAS) identifier and is exchanged between C1 and C4, whereas MLS uses the SPIS scheme 0242 exclusively and is strictly a C2 to C3 communication. And MLR does not require a dedicated SMP registration for the receiving capabilities, whereas MLS does - which is exactly what makes the "MLS has priority" rule technically enforceable, because C3 can determine via SMP lookup whether C2 has MLS receiving capabilities or not.

Overall timeline

Both plans share the same milestones, so this is the combined view:

Note: the two documents name the milestones T2 and T3 with slightly different dates. The MLS Phase-in plan uses "February 28th, 2027" (T2) and "March 31st, 2027" (T3), whereas the MLR Phase-out plan refers to the very same milestones as "March 1st, 2027" and "April 1st, 2027". Practically both denote the same points in time - the end of February 2027 and the end of March 2027. T4 is defined as a maximum of one month after T3.