Your E-Invoice Was Rejected — Now What?
Your invoice just bounced back with a validation error. Here's exactly what happened, why, and how to fix it in minutes.
Your invoice didn't go through. The Access Point sent back a negative acknowledgment — an MLR (Message Level Response) with an error code, a terse description, and no guidance on what to do next.
This is not unusual. Across the Peppol network, invoice rejections happen every day. The invoice never reached the buyer. The payment clock never started. And until you fix the underlying issue and resend, it won't.
The good news: most rejections are caused by a small set of predictable problems, and most of those problems are fixable in minutes once you know where to look.
What Just Happened?
When your ERP system or invoicing software sends an e-invoice over Peppol (or any other EU e-invoicing channel), the document passes through a validation pipeline before it reaches the buyer. That pipeline has four layers:
- XML Schema validation — Is the XML well-formed? Do the elements match the expected structure? Are data types correct?
- EN 16931 business rules — Are all mandatory fields present? Do the amounts add up? Is the VAT logic consistent?
- Format-specific rules — Does the invoice satisfy Peppol BIS 3.0 requirements (or XRechnung, ZUGFeRD, Factur-X)?
- Country CIUS rules — Does it meet the destination country's additional requirements (Germany's BR-DE-* rules, Belgium's BEvCIUS, etc.)?
Your invoice failed at one or more of these layers. The error code in the rejection tells you exactly which rule was violated. The challenge is understanding what that code means and what to change in your invoice data or template.
The 5 Most Common Reasons Your Invoice Was Rejected
These five issues account for the majority of rejections we see across thousands of validations. Chances are, yours is one of them.
1. Missing Required Fields
The EN 16931 standard defines a set of mandatory fields that every invoice must contain. Leave one out, and the invoice fails validation immediately.
The most frequently missing fields:
- Seller name — BR-06 requires that your invoice includes the seller's legal name in the Seller group (BG-4). If your ERP template doesn't populate this field, every invoice will fail.
- Buyer name — BR-07 requires the buyer's name in the Buyer group (BG-7). This often happens when the customer record in your ERP has an empty company name field.
- Buyer postal address — BR-10 requires at minimum the buyer's country code. An incomplete address block — even if city and street are present — will fail if the country code element is missing.
Fix: Check your ERP customer and company master data. These fields usually exist in your system — they're just not mapped to the correct invoice XML elements.
2. Wrong or Missing Document Currency
BR-05 requires a valid ISO 4217 currency code in the Document Currency Code field (BT-5). This fails when the currency code element is empty, when it contains a non-standard value like "Euro" instead of "EUR", or when it's missing from the XML entirely.
Fix: Ensure your template maps to a valid three-letter currency code (EUR, GBP, SEK, PLN, etc.) from your ERP's currency configuration.
3. Missing Invoice Issue Date
BR-03 mandates that every invoice includes an issue date (BT-2). The date must be in YYYY-MM-DD format. Failures here usually mean the date field wasn't populated in the XML output, or it was formatted as DD/MM/YYYY or another locale-specific pattern that doesn't match the required ISO 8601 format.
Fix: Check your ERP's date format settings for invoice exports. The XML must contain dates like 2026-04-21, not 21/04/2026 or April 21, 2026.
4. Disallowed XML Elements
UBL-CR-077 fires when your invoice contains a StatementDocumentReference element that isn't permitted in the UBL invoice schema used by Peppol BIS 3.0. Some ERP systems include extra reference elements from older UBL versions or custom extensions. The receiver's Access Point rejects them because they don't belong in the schema.
Fix: Review your XML template and remove any elements that aren't part of the UBL 2.1 Invoice or CreditNote schema. If your ERP adds custom elements, configure it to exclude them from Peppol exports.
5. Invalid Value Formats
cvc-datatype-valid.1.2.1 is an XML Schema (XSD) error that means a value doesn't match its expected data type. Common triggers:
- An amount field contains a comma as the decimal separator (
1.234,56instead of1234.56) - A date field has the wrong format
- A boolean field contains "Yes" instead of
true - A quantity field contains text
Fix: Check the specific field mentioned in the error message. XML Schema requires dot-separated decimals without thousand separators, YYYY-MM-DD dates, and true/false for booleans.
How to Find Out Exactly What's Wrong
Your Access Point's rejection message includes an error code, but it may not give you enough context to pinpoint the issue in your invoice. To get a full picture:
- Get the invoice XML — Download or export the raw XML file that was rejected from your ERP or Access Point dashboard.
- Run it through a validator — Upload it to a comprehensive validator that checks all four rule layers (schema, EN 16931, format, and country CIUS).
- Read the error report — A good validator will tell you the exact rule that failed, the XPath location of the problem in your XML, and what the correct value or structure should be.
Our free validator does exactly this. No account required. Drop your XML file, get a complete validation report in seconds.
Find Out Exactly What's Wrong
Drop your invoice XML here. Get a full validation report against all rule layers — schema, EN 16931, Peppol, and country CIUS.
Validate My InvoiceHow to Fix It
Once you know which rule failed, you have two paths:
Manual Fix
Open the invoice XML in a text editor, find the element identified by the error's XPath, and correct the value. This works for one-off fixes but doesn't prevent the same error on future invoices. You still need to fix the root cause in your ERP template or master data.
Fix the Root Cause
Most rejections trace back to one of three places:
- ERP export template — A field mapping is missing or misconfigured. Fix the template once, and all future invoices are correct.
- Customer master data — A buyer record is incomplete (missing country code, missing company name). Update the record.
- Company settings — Your own seller details are incomplete (missing VAT number, missing postal address). Update your company profile.
Auto-Fix
Some errors are purely structural — a namespace typo, a wrong element order, a missing wrapper element. These don't affect the commercial meaning of the invoice and can be fixed automatically. Our validator identifies auto-fixable errors and can remediate them on the fly, so the corrected invoice passes validation without manual intervention.
Auto-fix only applies to structural issues. Errors involving missing business data (seller name, currency code, buyer address) require you to supply the correct information. No tool can invent your buyer's postal address.
Prevent It From Happening Again
The most effective pattern is to validate before sending. Add a pre-submission validation step to your invoicing workflow: every invoice gets checked against all four rule layers before it reaches the Access Point. If it passes, it sends. If it fails, you fix it before the buyer's system ever sees it.
This eliminates rejections entirely. No MLR errors. No payment delays. No support calls from confused customers asking why their invoice bounced.
Browse the error library for detailed fix instructions on any error code you encounter, or check out our guide on how the validation layers work.
FAQ
What is an MLR rejection in Peppol?
An MLR (Message Level Response) is a standardized response on the Peppol network that indicates whether an invoice was accepted or rejected by the receiver's Access Point. A negative MLR means the invoice failed validation and was not delivered. The MLR includes the error code and a description of the failure reason.
Does a rejected invoice still count as sent?
No. A rejected invoice never reached the buyer. It has no legal effect and does not start payment terms. You must fix the issue, regenerate the invoice, and resend it. The payment clock starts only when a valid invoice is successfully delivered.
Can I fix the XML and resend the same invoice number?
It depends on your Access Point provider and the buyer's system. Some networks allow resubmission with the same invoice number if the original was rejected. Others require a new invoice number. Check with your Access Point provider. In either case, the content should be corrected to pass validation.
How long does it take to fix a rejected invoice?
For common errors like missing fields or wrong formats, the fix itself takes minutes once you identify the problem. The bottleneck is usually diagnosis — figuring out which field is wrong and where to fix it in your ERP. A validator that shows the exact XPath location and expected value reduces diagnosis time to seconds.
Where can I look up any error code?
Our error library documents over 1,300 validation rules across all four layers — schema, EN 16931, Peppol, and country CIUS. Each entry includes the rule definition, what triggers the error, and step-by-step fix instructions. You can also search by error code or browse by category.
Check Your Compliance Status
Find out exactly what your business needs to do for e-invoicing compliance.
Use Obligation Finder