Understanding Peppol Rejections: What MLR Means and How to Fix It

You sent an invoice over Peppol. Instead of a delivery confirmation, your Access Point sent back a negative response. The response document is called an MLR — Message Level Response — and it's telling you that your invoice was rejected before it reached the buyer.

The MLR contains an error code, a brief description, and sometimes an XPath pointing to the offending element. What it doesn't contain is a clear explanation of what went wrong or how to fix it.

This article breaks down exactly what an MLR is, how it fits into the Peppol delivery chain, what the error codes actually mean, and how to prevent rejections from happening in the first place.

What Is an MLR?

MLR stands for Message Level Response. It's a structured document defined in the Peppol Business Interoperability Specifications (BIS) that an Access Point sends back to the sender when something goes wrong with an invoice delivery.

Think of it as a return-to-sender notice. The invoice left your system, reached the Peppol network, and was evaluated. The evaluation found a problem. The MLR is the formal notification of that problem.

An MLR is not the same as a business rejection from the buyer. It's a technical rejection from the Peppol infrastructure — specifically, from one of the Access Points in the delivery chain. The buyer may never see the invoice at all.

MLR vs. IMR: Two Different Types of Rejection

Peppol defines two response types, and they mean very different things:

MLR (Message Level Response) — A technical response from an Access Point. It tells you whether the invoice was successfully received and processed at the transport and validation level. An MLR rejection means the invoice failed technical validation and was not forwarded to the buyer.

IMR (Invoice Message Response) — A business response from the buyer (or the buyer's system). It tells you whether the buyer accepts or rejects the invoice for business reasons. An IMR rejection means the invoice was technically valid and delivered, but the buyer's system or process rejected it — wrong purchase order number, disputed amounts, unrecognized supplier, etc.

The critical difference: an MLR rejection is something you can fix with better validation. An IMR rejection is a business dispute that requires communication with the buyer.

When your Access Point sends you a negative MLR, you're dealing with a technical problem in your invoice document. The fix is on your side.

The Peppol Delivery Chain

To understand where rejections happen, you need to understand the four-corner model that Peppol uses for message delivery:

Corner 1          Corner 2          Corner 3          Corner 4
Your ERP    →    Sending AP    →    Receiving AP    →    Buyer's System
(Sender)         (Your AP)         (Buyer's AP)         (Receiver)

Corner 1 (C1): Your ERP or invoicing system. This is where the invoice is generated and submitted for delivery.

Corner 2 (C2): Your Access Point. The certified Peppol service provider that your business connects to. It receives your invoice, validates it, and routes it to the receiver's Access Point.

Corner 3 (C3): The receiver's Access Point. The certified service provider that the buyer connects to. It receives the invoice from C2, may perform additional validation, and delivers it to the buyer's system.

Corner 4 (C4): The buyer's ERP or invoicing system. This is where the invoice arrives if everything passes.

Validation can happen at both C2 and C3. Your sending Access Point (C2) validates the invoice before transmitting it. If it fails, you get an MLR immediately from your own AP. If it passes C2 validation but fails at the receiving Access Point (C3), you get an MLR back from C3 — which arrives via your AP but originated at the other end.

This matters because different Access Points may enforce rules with different strictness. Your AP might accept an invoice that the receiver's AP rejects, or vice versa. The Peppol validation rules are standardized, but implementation varies.

The Three Validation Layers

When an Access Point validates your invoice, it runs three distinct layers of checks. Each layer catches different types of problems:

Layer 1: XML Schema Validation

The first check verifies that the invoice XML is well-formed and conforms to the UBL 2.1 schema (or CII schema, depending on your format). This catches:

• Malformed XML (unclosed tags, encoding issues)
• Wrong element names or namespaces
• Invalid data types (text in a numeric field, wrong date format)
• Elements in the wrong order

Schema errors produce cvc-* error codes. The most common is cvc-datatype-valid.1.2.1, which fires when a value doesn't match its expected type — a date formatted as 16/06/2026 instead of 2026-06-16, or an amount with comma-as-decimal.

If an invoice fails schema validation, the Access Point stops here. It won't run business rules or format-specific checks on an invoice that isn't even valid XML.

Layer 2: EN 16931 Business Rules (Schematron)

The second layer runs the EN 16931 semantic business rules using Schematron validation. These are the BR-* rules that enforce the European standard's requirements:

• Mandatory field checks — Is the seller name present? The buyer name? The currency code? (BR-06, BR-07, BR-05)
• Calculation rules — Do line totals sum correctly? Does VAT add up? Does the payable amount equal what the math says it should?
• Cross-field consistency — If the invoice has a due date, does it come after the issue date? If there's a tax exemption, is a reason code provided?

These are the business rule errors that account for the majority of Peppol rejections. They test the semantic content of the invoice — not just whether the XML is structurally valid, but whether the data makes sense.

Layer 3: Format-Specific and Country CIUS Rules

The third layer applies rules specific to the Peppol BIS profile and any country-specific CIUS (Core Invoice Usage Specification) that applies:

• Peppol BIS rules — Additional constraints beyond EN 16931 that Peppol requires, including valid identifier schemes, permitted code list values, and BIS-specific element restrictions
• Country CIUS rules — Germany's BR-DE-* rules (requiring Leitweg-ID for public sector, specific payment terms), Belgium's BEvCIUS rules, the Netherlands' SI-UBL rules, etc.

Country-specific errors are particularly tricky because they only fire when the invoice is destined for a specific country. An invoice template that works perfectly for Belgian receivers may fail when you send it to a German public sector buyer because the BR-DE rules require a Leitweg-ID in BT-10.

How to Read an MLR Rejection Message

An MLR rejection from your Access Point typically contains these elements:

• Response code — The overall result. A value indicating rejection (varies by AP implementation, but commonly RE for rejected)
• Error code — The specific validation rule that failed (e.g., BR-06, UBL-CR-077, cvc-datatype-valid.1.2.1)
• Description — A human-readable description of the rule (often terse and technical)
• Location/XPath — The path to the element in the XML where the error occurred

The error code is the key piece of information. It maps directly to a specific validation rule, and each rule has a defined meaning and a known fix.

Common MLR Rejection Reasons (and What to Do)

Here are the rejection reasons we see most frequently, mapped to their error codes:

Missing Mandatory Fields

The invoice is missing a required element. The MLR will reference a BR-* code:

• BR-01 — Missing specification identifier (CustomizationID)
• BR-03 — Missing invoice issue date
• BR-05 — Missing document currency code
• BR-06 — Missing seller name
• BR-07 — Missing buyer name

What to do: Find the missing field in your ERP's invoice template configuration. These errors mean the XML element is absent or empty — the data usually exists somewhere in your ERP, it's just not mapped to the XML output.

Disallowed Elements

The invoice contains XML elements that aren't permitted in Peppol BIS 3.0. These are UBL-CR-* errors:

• UBL-CR-077 — Contains StatementDocumentReference (not allowed in BIS 3.0)
• Other UBL-CR codes — Various elements from the broader UBL 2.1 spec that Peppol restricts

What to do: Remove the flagged element from your XML template. These elements may serve a purpose internally, but they must not appear in Peppol invoices. See the format rules category for the full list.

Calculation Mismatches

The amounts in the invoice don't add up according to EN 16931 calculation rules. These show up as BR-CO-* errors:

• Line extension amounts don't sum to the expected total
• Tax amounts don't match the tax rate applied to the taxable amount
• The payable amount doesn't equal total with VAT minus prepaid amount

What to do: Check your ERP's rounding logic. EN 16931 has specific rules about when rounding happens (at line level vs. document level). If your ERP rounds differently, the totals may be off by a cent — enough to fail validation.

Schema Validation Failures

The XML doesn't match the expected data types. These produce cvc-* errors:

• cvc-datatype-valid.1.2.1 — A value doesn't match its type (wrong date format, comma-as-decimal)

What to do: Check the specific field referenced in the error. Fix the format: dates must be YYYY-MM-DD, amounts must use dot-as-decimal with no thousand separators, boolean values must be true or false.

How to Prevent MLR Rejections

The pattern is straightforward: validate before you send.

Every MLR rejection represents an invoice that traveled through your system, reached the Peppol network, failed validation, and bounced back. The entire round trip was wasted. The fix was always available before sending — the same validation rules that the Access Point runs can be run on your side first.

The workflow:

1. Your ERP generates the invoice XML
2. The invoice passes through a pre-send validation gate
3. If valid: send to Access Point (zero rejection risk)
4. If invalid: the error report tells you exactly what's wrong, before the invoice enters the network

For automated setups, see the validation pipeline guide for code and architecture patterns. For manual testing, the how to validate guide walks through the process step by step.

When an MLR Isn't Your Fault

Occasionally, an MLR rejection comes from an issue on the receiving side — the receiver's Access Point (C3) has an overly strict or non-standard validation configuration, or there's a transient infrastructure issue. If you've validated your invoice against all four rule layers and it passes, but the receiver's AP still rejects it, the issue may be:

• Non-standard validation at C3 — Some Access Points add rules beyond the official Peppol validation artifacts. Contact the receiver's AP if your invoice passes standard validation but gets rejected.
• Outdated validation artifacts — The receiver's AP may be running an older version of the Schematron rules. This is rare but happens during transition periods after a specification update.
• Transport-level issues — TLS certificate problems, message size limits, or AS4 configuration issues that aren't about the invoice content at all.

In these cases, the problem isn't in your invoice. But you still need the validation report to prove it.

FAQ

What's the difference between an MLR rejection and a Peppol delivery failure?

An MLR rejection means the invoice was received by an Access Point, validated, and found to be non-compliant. A delivery failure means the invoice couldn't be transmitted at all — the recipient's Access Point was unreachable, the Peppol participant ID wasn't found in the directory, or there was a transport-level error. MLR rejections are content problems. Delivery failures are network problems.

My invoice passes validation locally but gets rejected by the receiving Access Point. Why?

Three possible causes. First, you may be validating against a different specification version than the receiver expects. Check that your CustomizationID matches what the receiver's AP requires. Second, the receiver may apply additional validation beyond the standard Peppol rules. Third, there may be country-specific CIUS rules you're not checking. Make sure you validate against all four layers, including the destination country's rules.

How quickly should I expect an MLR after sending an invoice?

MLR timing depends on the Access Points involved. Your sending AP (C2) typically validates within seconds and returns an MLR almost immediately if the invoice fails. If the invoice passes C2 and fails at the receiving AP (C3), the MLR may take minutes to hours, depending on the receiver's processing time and how quickly C3 sends the response back through the network.

Can I retry sending after an MLR rejection?

Yes, once you've fixed the issue. An MLR rejection doesn't blacklist the invoice or create any permanent state. Fix the problem identified in the error code, re-validate to confirm the fix works, and resend. The receiver's system treats the resent invoice as a new submission.

Are MLR rejections logged anywhere I can audit later?

Your Access Point should log all MLR exchanges. Most APs provide a dashboard or API where you can review sent invoices, delivery statuses, and rejection details. For your own records, keeping the original invoice XML alongside the MLR response is good practice for compliance audit trails.