Peppol Status Messages Explained: Why MLS Is Not the Same as a Business-Level Response

• OpenPeppol released version 1.1.0 of its Message Level Status specification in July 2026, strengthening technical feedback between the sending and receiving Peppol Service Providers. MLS confirms whether an electronic invoice or other business document has been successfully processed and forwarded—or whether technical delivery has failed. It does not confirm that the buyer has accepted the invoice. [docs.peppol.eu], [docs.peppol.eu]
• Business-level feedback belongs to a separate layer. The correct Peppol terminology is normally Business Level Response—or BLR—rather than BLS. For invoices, this may be communicated through the Peppol Invoice Response, covering statuses such as accepted, conditionally accepted, rejected or under query. [docs.peppol.eu], [docs.peppol.eu]
• The distinction is particularly important in France and Belgium. France requires an extensive national invoice-lifecycle process, combining technical and business statuses with tax reporting. Belgium principally uses the standard Peppol exchange model: an MLS may prove technical delivery, but a separate Invoice Response or ERP workflow is needed to establish whether the customer has accepted the invoice. [impots.gouv.fr], [efacture.belgium.be], [peppol.org]

Extended article

OpenPeppol introduces a clearer technical status layer

As structured electronic invoicing becomes mandatory across Europe, businesses must distinguish between the technical delivery of an invoice and its subsequent processing by the customer. OpenPeppol’s Message Level Status, or MLS, addresses the first of these questions: what happened to the electronic message after it was transmitted by the supplier’s Peppol Service Provider?

The first final MLS specification was released in May 2025, followed by MLS version 1.1.0 on 7 July 2026. OpenPeppol also published a Service Provider Operational Guideline on 2 July 2026, setting out the obligations of Peppol Service Providers and the transition from the older Message Level Response, or MLR, to MLS. [docs.peppol.eu], [docs.peppol.eu], [docs.peppol.eu]

Under the Peppol four-corner model:

• C1 is the sending business;
• C2 is the sender’s Peppol Service Provider;
• C3 is the recipient’s Peppol Service Provider; and
• C4 is the receiving business.

MLS is principally exchanged between C3 and C2. It enables the receiving Service Provider to inform the sending Service Provider whether the document could be forwarded successfully, whether forwarding is temporarily impossible, or whether delivery ultimately failed. Its purpose is to improve the reliability and traceability of the network-level exchange. [docs.peppol.eu], [docs.peppol.eu]

An MLS therefore answers questions such as:

• Was the invoice received by the receiving Service Provider?
• Could it be processed at message level?
• Was it forwarded to the recipient?
• Is forwarding temporarily unavailable?
• Did the delivery fail?

However, MLS does not establish whether the customer considers the invoice commercially correct, has posted it in accounts payable, has approved it for payment or accepts the VAT treatment applied by the supplier. [docs.peppol.eu], [docs.peppol.eu]

BLS or BLR: an important terminology clarification

“BLS” is sometimes used informally to mean Business-Level Status, but this is not the principal formal Peppol acronym. The recognised Peppol concept is generally BLR—Business Level Response. For invoicing, the relevant Peppol business document is the Invoice Response.

The Peppol Invoice Response is designed to communicate the recipient’s business-processing decision. Depending on the process and implementation, it can indicate that an invoice has been received, accepted, conditionally accepted, rejected or placed under query. Unlike MLS, this response originates from—or represents a decision made by—the receiving business rather than merely its Peppol Service Provider. [docs.peppol.eu], [peppol.org]

The distinction can be summarised as follows:

A positive MLS should therefore never automatically update an invoice in the supplier’s ERP to “customer accepted.” At most, it should support a status such as technically delivered. A separate business response, customer notification or internal accounts-receivable workflow is needed before the invoice can be treated as accepted or approved for payment. [docs.peppol.eu], [docs.peppol.eu]

Application in France

France demonstrates why these status layers must be carefully separated. The French e-invoicing reform starts on 1 September 2026, when all taxpayers within scope must be able to receive regulated electronic invoices, while large and medium-sized businesses must also issue regulated e-invoices and perform e-reporting. The corresponding issuing and e-reporting obligations apply to smaller businesses from 1 September 2027. [impots.gouv.fr], [impots.gouv.fr], [peppol.org]

France uses accredited private platforms—Plateformes Agréées, previously referred to as PDPs—to transmit invoices, exchange status messages and communicate required data to the tax administration. France has also integrated components of its domestic architecture with Peppol. The France Peppol country profile lists French UBL and CII invoice formats, Factur-X, CDAR invoice-status messages, Peppol BIS Billing and the Peppol Invoice Message Response among the supported elements. [fonoa.com], [peppol.org]

The French lifecycle includes both technical and business events. Four statuses are generally identified as mandatory:

• Submitted or filed—déposée;
• Rejected—rejetée;
• Refused by the recipient—refusée; and
• Collected or paid—encaissée.

Additional statuses may cover availability to the buyer, processing, approval, partial approval, dispute, suspension and payment transmission. A technical rejection is fundamentally different from a refusal: rejection normally means that the invoice failed a technical, syntax or mandatory-data control, while refusal reflects a business decision by the buyer. [hayot-expertise.fr], [cleartax.com], [e-invoicin…asware.com]

Consequently, a French implementation cannot rely on MLS alone. MLS can contribute to technical transmission assurance at the Peppol Service Provider layer, but the French CDAR and invoice-lifecycle process must communicate the nationally prescribed statuses to the relevant platforms, trading parties and tax administration. A multinational ERP should map these statuses separately rather than reducing all responses to a single “accepted/rejected” field. [fonoa.com], [frenchinvoice.fr], [peppol.org]

A sensible French status model would therefore distinguish at least:

1. Message sent to the supplier’s platform;
2. Technically accepted by the platform;
3. Delivered or made available to the buyer;
4. Rejected for technical reasons;
5. Refused for business reasons;
6. Accepted or approved by the buyer;
7. Payment initiated; and
8. Payment collected and reported where required.

This distinction is especially important for services subject to VAT on collection, because France’s reform includes payment-data reporting where VAT becomes due upon receipt of payment. [impots.gouv.fr], [e-invoicin…asware.com]

Application in Belgium

Belgium’s domestic B2B structured e-invoicing mandate has applied since 1 January 2026 to transactions falling within its legal scope. The official Belgian guidance describes Peppol as the standard secure network through which structured invoices are exchanged between businesses, with Belgian participants normally registered using their Crossroads Bank for Enterprises number under identifier scheme 0208. [efacture.belgium.be], [efacture.belgium.be], [efacture.belgium.be]

Unlike France, Belgium does not currently operate the same type of extensive national invoice-lifecycle and platform-reporting model. The principal requirement is the issuance and receipt of a compliant structured invoice, normally using Peppol BIS Billing 3.0 over Peppol. The Peppol BIS Billing specification is a Core Invoice Usage Specification of EN 16931 and provides the interoperable invoice structure used in the network. [efacture.belgium.be], [docs.peppol.eu]

For Belgium, the consequences are as follows:

• AS4 receipt: indicates that the transmission between Access Points occurred.
• MLS: provides additional message-processing and forwarding information between the Peppol Service Providers.
• Invoice Response: may communicate whether the Belgian customer accepts, disputes or rejects the invoice at business level.
• ERP/AP status: records whether the invoice was posted, matched to a purchase order, approved and scheduled for payment.

A technically successful Peppol delivery does not by itself show that the Belgian customer has accepted the invoice or that the invoice gives the customer a definitive VAT deduction entitlement. The legal validity and VAT treatment still depend on the invoice contents, the underlying transaction and the applicable Belgian VAT rules. [efacture.belgium.be], [docs.peppol.eu]

Belgian businesses should therefore ask their software or Peppol provider not merely whether it “supports Peppol,” but whether it supports:

• MLS receipt and interpretation;
• Peppol Invoice Response;
• differentiated technical and business rejection codes;
• automatic reconciliation with the original invoice;
• routing of business disputes to accounts receivable;
• retention of status messages as audit evidence; and
• prevention of a technical acknowledgment being treated as customer approval.

Application in other EU countries

The MLS specification is a Peppol network specification rather than a country-specific VAT status system. It can therefore be used wherever the relevant Peppol Service Providers implement the applicable MLS rules. However, it does not replace national clearance acknowledgments, lifecycle messages or tax-authority responses. [docs.peppol.eu], [docs.peppol.eu]

Netherlands and the Nordic countries

Countries such as the Netherlands, Denmark, Sweden and Finland have significant experience with Peppol-based B2G or B2B document exchange. In these countries, the same basic separation applies: Peppol transmission or MLS status provides evidence about technical processing, while an Invoice Response or another procurement message communicates the customer’s business decision. National invoice formats or CIUS requirements may still apply. [peppolvalidator.com], [invoice-portal.de]

Germany

Germany requires businesses to be able to receive structured domestic B2B e-invoices, with issuing obligations being phased in. Germany supports EN 16931-compliant formats such as XRechnung and ZUGFeRD, and Peppol may be used as a transmission channel. Where Peppol is used, MLS can support technical delivery monitoring, but it does not replace the buyer’s AP approval or any business rejection communicated outside Peppol. [peppolvalidator.com], [sensetask.com]

Italy, Poland and Romania

Italy’s SdI, Poland’s KSeF and Romania’s RO e-Factura operate national platform or clearance-style models. Their platform acknowledgments have specific legal and operational significance. An MLS generated in connection with a Peppol exchange would not replace the acceptance, rejection, identification or clearance response generated by the relevant national system. [peppolvalidator.com], [sensetask.com]

The central lesson is that companies should not attempt to create one universal status called “invoice accepted.” They need a layered model capable of recording:

1. Network transmission;
2. Message validation;
3. Delivery to the recipient;
4. National platform or tax-authority acceptance;
5. Customer business acceptance;
6. Accounting approval; and
7. Payment or collection.

Practical conclusion for Finance, Tax and IT teams

MLS is a significant improvement in Peppol network reliability, particularly as OpenPeppol transitions away from the older MLR model. Nevertheless, it remains a message-level rather than a business-level control. A successful MLS confirms technical processing or forwarding; it does not establish that the customer agrees with the invoice, that the VAT treatment is correct or that payment will follow. [docs.peppol.eu], [docs.peppol.eu]

For multinational implementation programmes, the recommended approach is to establish a common global status architecture with separate fields for technical delivery, national compliance, business acceptance and payment. France should then be configured with its mandatory lifecycle and CDAR requirements, Belgium with standard Peppol delivery and optional Invoice Response capabilities, and other countries with their respective clearance or reporting statuses. This avoids false positives, improves accounts-receivable follow-up and provides a more defensible audit trail.

External resources

• Peppol Message Level Status Specification v1.1.0
• Peppol Service Provider Operational Guideline on MLS
• Peppol MLR Deprecation and Phase-out Plan
• Peppol BIS Invoice Response
• France: OpenPeppol Country Profile
• France: Official overview of the e-invoicing reform
• Belgium: Official Peppol FAQ
• Belgium: Official technical and VAT e-invoicing FAQ