The Peppol MLR deprecation means Peppol Service Providers must replace Message Level Response with Message Level Status and stop using MLR under the published 2027 transition timetable. Most businesses will not rebuild their invoice process, but they must confirm that their provider, software connector, status workflows, and exception handling are ready for MLS.
The business risk is not usually invoice creation. It is losing visibility when delivery, rejection, or failed-forwarding events are mapped incorrectly between the Peppol Access Point, accounting software, ERP, helpdesk, and finance dashboard. A technically successful provider migration can still create operational failure if finance users cannot see which invoices need correction, resubmission, or investigation. Businesses should therefore treat the change as a controlled integration update, not merely a background network upgrade.
What the Peppol MLR Deprecation Changes for E-Invoicing Users and What Remains the Same
The change replaces the Peppol Message Level Response with the more capable Peppol Message Level Status. It does not replace the invoice itself, rewrite local tax rules, or automatically require every business to change its ERP.
OpenPeppol’s published phase-out plan sets three operational milestones: MLS sending activation opens on 1 March 2027, MLS sending becomes mandatory for Service Providers on 1 April 2027, and MLR is fully retired on 1 May 2027. Once a provider activates MLS sending, it must stop sending MLR for documents handled through MLS. Between 1 April and 1 May, MLR is permitted only as a narrow fallback where the sending provider cannot find the receiving provider’s MLS capability in the Service Metadata Publisher.
For a typical SME using cloud accounting software, the provider may complete most of the technical work without changing the user interface. For an enterprise receiving raw status payloads through middleware, the change can affect integration mappings, monitoring rules, incident alerts, and audit records.
One distinction matters: a status response is not the same as the buyer approving an invoice for payment. AP, AB, or RE describes message processing or delivery outcomes. Commercial acceptance, dispute handling, matching, approval, and payment remain separate finance processes.
Treating “delivered” as “approved” is a control weakness, regardless of whether the status arrives through MLR or MLS. Finance teams should maintain separate statuses for network delivery, invoice validation, buyer approval, payment authorization, and settlement.
How the MLR to MLS Transition Works Across Peppol Access Points and ERP Workflows
The MLR to MLS transition happens mainly between Peppol Service Providers, but its status data may flow into business systems. A company must understand whether its Access Point normalizes those events or exposes MLR-specific fields directly to the ERP.
The official Peppol MLS specification describes MLS as a message sent from the receiving Service Provider, C3, to the sending Service Provider, C2, about processing and delivery toward the recipient, C4. MLS retains the familiar AP, AB, and RE outcomes while adding support for permanent delivery failure, structured reason codes, more prescriptive issue details, receiver-directed routing, response preferences, and service-level requirements.
In a well-designed setup, the flow looks like this:
- The ERP or accounting system creates a structured invoice.
- Internal validation checks tax fields, identifiers, totals, references, and required business data.
- The Peppol Access Point validates and routes the document.
- The receiving provider returns an MLS event.
- Middleware converts the event into a business-readable status.
- Finance users see the outcome in an invoice queue, dashboard, or case-management workflow.
The main integration decision is whether to preserve provider-neutral statuses or bind internal logic to the raw message format. Provider-neutral events such as “delivered with confirmation,” “delivered without confirmation,” “rejected,” and “delivery failed” reduce future change costs. Hard-coded checks for MLR document types, XML paths, or message identifiers create brittle dependencies.
Security also matters. Status events should use authenticated interfaces, role-based access, traceable timestamps, controlled retry logic, and logs that connect the original invoice, transmission identifier, response, correction, and resubmission. Without that chain, invoice automation may be fast but not audit-ready.
How SMEs, Accounting Firms, and Enterprises Should Interpret the Peppol MLR Retirement
Different businesses face different migration work because their exposure depends on system complexity, invoice volume, and how status messages are consumed. Company size alone does not determine readiness.
An SME using one accounting package and a managed Peppol connection may only need written confirmation that its connector and provider will support MLS before activation. The real test is practical: can a user still identify a rejected invoice, understand the reason, correct the data, and resend it without logging into several systems?
An accounting firm has a different problem. It may support many clients with different identifiers, ledgers, approval rules, and software versions. A single connector update is not enough if status messages are attached to the wrong client, legal entity, or invoice record. Multi-tenant mapping and access controls matter more than raw technical capability.
An enterprise with SAP, Oracle, Microsoft Dynamics, or a mixed ERP landscape should review integration middleware, event schemas, monitoring rules, and shared-service procedures. One business unit may consume normalized API events while another archives raw Peppol responses. The second unit has more migration exposure.
Retail and distribution businesses need dependable high-volume exception handling. A small percentage of unmapped MLS events can create a large backlog when invoices are generated in batches. Professional services firms may have lower volumes but more dependence on purchase-order references, project codes, and customer-specific routing.
Multi-entity and multi-country organizations should separate two questions. The Peppol MLR retirement is a network-level change, while invoice content, reporting, retention, and mandate scope depend on the applicable country requirements. Combining both into one “global compliance” checklist usually hides local gaps.
How Finance and IT Teams Should Prepare for the Peppol MLR End of Support
Businesses should prepare by tracing the full invoice-status journey and testing the exceptions, not by asking only whether their provider “supports MLS.” Readiness means the right people can detect, interpret, correct, and evidence every important outcome after cutover.
Start with a focused assessment:
- Identify every provider, Access Point, connector, API, middleware flow, archive, and dashboard that sends or receives Peppol status data.
- Search integration rules for MLR document identifiers, XML paths, endpoint assumptions, or custom response mappings.
- Confirm how AP, AB, RE, and failed-delivery outcomes will appear in the ERP or accounting system.
- Clean supplier, customer, and entity identifiers where incorrect routing could create avoidable failures.
- Test invoice rejection, delivery failure, correction, resubmission, duplicate prevention, and manual escalation.
- Define who owns unresolved exceptions across finance, IT, customer service, and the provider.
The strongest migration test is not a successful invoice. It is a controlled failure. Submit a document with a known validation issue in a test environment, confirm that the rejection reaches the correct queue, verify that the reason is understandable, correct the source data, and prove that the resubmission is linked to the original attempt.
Businesses should also agree on cutover evidence. This may include provider confirmation, test results, interface versions, updated process documents, training records, and a temporary period of enhanced monitoring.
Manual spreadsheet tracking may be acceptable for a very small invoice population, but it becomes risky when teams cannot reconcile invoice IDs, timestamps, status events, and corrective actions consistently. Automated status capture becomes more valuable as invoice volume, entity count, and system complexity increase.
How to Decide Whether Your Peppol Provider Is Ready for the MLS Transition
A provider is ready when it can explain the technical cutover, customer impact, status mapping, fallback behavior, testing process, and support model in operational terms. A generic statement that “MLS is supported” is not enough.
Ask the provider:
- When will MLS receiving and sending be activated?
- Will existing APIs, webhooks, portals, or file interfaces change?
- Are raw MLR payloads exposed to customers today?
- How will delivery failure be distinguished from validation rejection?
- What happens to in-flight messages during cutover?
- How will status history remain available for audit and support?
- Which customer tests are required, and who signs off?
- How will the provider communicate incidents or unresolved exceptions?
Cost should be assessed against operational exposure. A low-cost connector may be reasonable for an SME with one ledger, low volume, and simple approvals. A multi-entity enterprise may need stronger API governance, monitoring, service management, security controls, and country-specific validation support.
Paying less for connectivity while creating manual exception work is not a saving. The total operating cost includes failed-invoice investigation, user time, integration maintenance, trading-partner support, audit reconstruction, and delayed payment resolution.
AassureComply is worth considering when the business needs more than a basic send-and-receive connection, particularly where Peppol connectivity must align with accounting systems, ERP workflows, invoice validation, operational support, and audit evidence. The decision should still be based on documented requirements, integration fit, implementation ownership, and measurable test acceptance.
Which MLR Phase-Out Mistakes Create Avoidable Invoice and Compliance Risk
The biggest mistakes come from assuming the provider will handle everything and that no internal process depends on MLR. That assumption fails when custom integrations, dashboards, archives, or support procedures use MLR-specific data.
Common failure patterns include:
- Waiting until April 2027 to discover that a middleware rule recognizes MLR but not MLS.
- Treating accounting software compatibility as proof that the complete Peppol workflow is ready.
- Ignoring customer and supplier identifiers that affect discovery and routing.
- Mapping every RE event to “invoice validation error” even though MLS can also report failed delivery.
- Closing an invoice case when the document is delivered, even though business approval is still pending.
- Choosing a provider without clear integration testing, event history, or exception support.
- Assuming all countries, trading partners, and entity systems use identical invoice formats and workflows.
An important edge case is the fallback period between mandatory MLS sending and full MLR retirement. Businesses should not build a long-term process around that temporary exception. It exists for a narrow capability-discovery failure and closes when MLR is retired.
Another edge case is historical evidence. Removing MLR processing should not make old response records unreadable. Archives, audit tools, and support teams may still need to interpret previous MLR events after live sending has ended.
The same principle applies to open disputes and support tickets. A case created before cutover may contain MLR terminology while later events use MLS. Support teams need enough context to understand both without misclassifying the invoice state.
What E-Invoicing Users Should Do Before MLR Is Fully Retired
The practical decision is straightforward: confirm provider readiness, identify internal MLR dependencies, test MLS status handling, and document the cutover before 1 May 2027. Most businesses will not replace their ERP solely because of this change, but organizations with custom Peppol integrations should not assume the migration is invisible.
Finance and IT teams should focus on status visibility, exception ownership, audit continuity, and the difference between technical delivery and commercial approval. A successful transition is one where invoices continue to move, failures reach the right team, reasons remain understandable, and evidence remains traceable.
Businesses that need connected Peppol e-invoicing across accounting software, ERP systems, validation workflows, and multiple entities can evaluate AassureComply as part of their migration planning. The next step is to map the current invoice-status flow and identify exactly where MLR-specific logic exists.
Frequently Asked Questions
What is replacing the Peppol Message Level Response?
Peppol Message Level Status is replacing MLR. MLS covers the acceptance, acknowledgement, and rejection outcomes supported by MLR, while adding permanent delivery-failure reporting, structured reason codes, improved issue details, routing options, and service-level requirements. The change mainly affects Peppol Service Providers, but businesses should verify how MLS events will appear in their accounting, ERP, portal, or support workflows.
When does the Peppol MLR phase-out take effect?
The transition begins on 1 March 2027 when MLS sending activation opens. MLS sending becomes mandatory for Service Providers on 1 April 2027, with MLR limited to a narrow fallback case. MLR is fully retired on 1 May 2027, after which Service Providers must not send or receive it. Businesses should complete integration testing before their provider’s activation date.
Will businesses need to replace their accounting software because of the MLR retirement?
Usually not. Businesses can often keep existing accounting software when the Peppol provider or connector converts MLS events into the statuses already used by finance teams. Changes are more likely where software consumes raw MLR files, XML elements, document identifiers, or custom webhooks. The correct approach is to inspect the integration rather than assume either replacement or zero impact.
How does MLS affect ERP e-invoicing integration?
MLS can affect event mappings, exception queues, dashboards, alerts, middleware schemas, and audit logs. ERP-connected teams should confirm that rejection and delivery-failure events remain distinct, timestamps are retained, and resubmissions link to the original invoice. Testing should include controlled failures, not just successful transmission, because exception handling reveals whether the operational workflow is genuinely ready.
Does an AP or AB status mean the customer approved the invoice?
No. AP and AB describe message delivery outcomes, not commercial approval, three-way matching, dispute resolution, or payment authorization. A finance workflow should keep technical delivery status separate from business acceptance. Otherwise, an invoice can appear complete even when the buyer has not approved it, a purchase-order mismatch remains unresolved, or payment is still blocked.
How should a business choose a provider for the MLR to MLS transition?
Choose a provider that can document activation dates, interface changes, status mapping, testing, security controls, audit history, exception support, and cutover ownership. The provider should explain how MLS events reach the business system, not merely confirm technical network support. Multi-entity and high-volume organizations should also assess monitoring, API governance, access controls, and support escalation across countries and ERP platforms.