On July 2, 2026, OpenPeppol published a wave of updates that will reshape how every Access Point (AP) in the Peppol network handles delivery confirmation. At the center of it is Message Level Status (MLS) v1.1.0, alongside a brand-new Service Provider Operational Guideline on MLS v1.0.0, an updated Peppol Envelope specification (v2.0.2), the first version of the Peppol Network Policy, and a refreshed code list (v9.7). OpenPeppol has been running dedicated sessions — Open Dialogs, MLS Basics, and “MLS impact on existing APs and SMPs” — to walk Service Providers through the change, a clear signal of how significant this update is for the network.
Here’s a practical breakdown of what’s changing, why it matters, and what Service Providers need to do about it.
What MLS Actually Is
Peppol distinguishes between three layers of status information as a message moves through the network:
- Protocol Status — confirms Peppol eDelivery and PKI compliance (e.g., the AS4 signal message).
- Messaging Status (MLS) — confirms compliance with the Peppol Architectural Framework itself.
- Business Status — confirms compliance with local business rules (e.g., a Peppol BIS Invoice Response).
MLS sits in the middle layer. It’s the mechanism by which the receiving AP (C3) tells the sending AP (C2) whether an incoming message was successfully processed and forwarded — independent of whether the underlying business document was ultimately valid. In short: a positive AS4 acknowledgment only proves the message arrived at C3. MLS is what confirms C3 could actually do something useful with it.
The Migration Timeline
OpenPeppol has laid out a three-milestone migration plan, and the dates are worth putting on the calendar now:
- T1 – July 1, 2026: Specifications take effect; the phase-in clock starts.
- T2 – February 28, 2027: End of Phase 1. MLS receiving capability must be live in production, and the window to activate MLS sending opens.
- T3 – March 31, 2027: End of Phase 2. MLS sending becomes mandatory, and the associated Service Level Requirements become enforceable.
During Phase 1 (T1 to T2, roughly 8 months), Service Providers are expected to:
- Build MLS sending infrastructure
- Implement MLS queuing and retry logic
- Build MLS receiving infrastructure
- Parse and evaluate SBDH MLS fields
- Register MLS-receiving capability in the SMP
That’s a meaningful engineering lift, and the 8-month window is tighter than it looks once queuing, retry, and SMP registration are factored in.
New Service Level Requirements
Two new SLRs anchor the operational side of MLS:
- SLR MLS-1 (Sending): 99.5% of MLS messages for business documents under 10MB must be sent within a maximum of 20 minutes.
- SLR MLS-2 (Reception): 99.5% of MLS messages for business documents under 10MB must be received within a maximum of 25 minutes.
Importantly, these are statistical thresholds over a monthly measurement period — not a per-message guarantee. The specification is explicit that a single missing MLS inside the 25-minute window should not be treated as definitive proof of delivery failure, especially given that a positive AS4 acknowledgment already establishes that C3 took responsibility for the message. Receiving APs are told not to resend the original business document just because an MLS didn’t arrive in time.
The escalation path only kicks in after 24 hours: if no MLS has arrived by then (and one was requested unconditionally), C2 should contact C3’s support — via a known contact point, the SMP endpoint information, or, as a last resort, the contact info on peppol.org — and coordinate next steps with C3 directly. Non-receipt events should be logged for operational monitoring and compliance evidence.
A Few Rules Worth Knowing
A handful of details in the spec are easy to miss but operationally important:
- One response per document. Each received business document must be responded to with zero or one MLS message. If more than one valid MLS is somehow received for the same transmission, only the first valid one counts — subsequent ones must be ignored by C2. (Duplicate detection at the AS4/transmission layer is assumed to already be in place.)
- The “Failure of Delivery” (FD) rejection code is special. It may only be used when the incoming message is architecturally correct, cannot be permanently forwarded to C4, and the rejection is for non-business reasons. Even then, responsibility for fixing the underlying issue stays with C3, even though the business document itself is handed back to C2.
- Reporting implications. MLS messages count as Peppol Dataset exchanges and must be included in Transaction Statistics Reporting (TSR), using a distinct Document Type Identifier. But they must not appear in End User Statistics Reporting (EUSR), since MLS is purely a Service-Provider-to-Service-Provider exchange with no end-user involvement.
- MLR is being phased out. A separate July 15, 2026 update points to a dedicated “Peppol MLR Phase-Out v1.0.0” document — a related change worth tracking alongside MLS itself.
Why It Matters
MLS moves Peppol from “the transport succeeded” to “the network actually knows what happened to the message” — closing a long-standing visibility gap between AS4-level acknowledgment and true message-level confirmation. For Access Points and their customers, that means better failure diagnosis, fewer silent drops, and a network-wide expectation of measurable reliability once the SLRs become enforceable in March 2027.
The runway is reasonable, but not long. Any Access Point that hasn’t already scoped MLS sending/receiving, queuing and retry logic, and SMP capability registration should treat Q4 2026 as the real deadline — not March 2027.
Sources: OpenPeppol Message Level Status v1.1.0, Peppol Service Provider Operational Guideline on MLS v1.0.0, OpenPeppol eDEC Specifications Change Log (2026-07-02 and 2026-07-15 updates).