The 10 Most Common E-Invoice Errors in 2026 (and How to Fix Each One)

We run 1,326 rules against every invoice that passes through our validator. Schema checks, EN 16931 business rules, Peppol format rules, country-specific CIUS rules — the full stack.

After analyzing thousands of validations, the pattern is clear: the same small set of errors appears again and again. Ten rules account for a disproportionate share of all failures. If you fix these ten, you eliminate the vast majority of invoice rejections before they happen.

Here they are, in order of frequency.

The 10 Most Common Errors

1. BR-06: Seller Name Missing

Rule: An invoice shall have the seller name.

BR-06 fires when the Seller group (BG-4) doesn't include the seller's legal name in cbc:RegistrationName or cbc:Name. This is one of the most basic requirements in EN 16931 — every invoice must identify who sent it.

Why it happens: The ERP export template maps company data from a table where the legal name field is empty or uses a different field (trade name instead of registered name). Some systems populate the seller name only in the PDF layout but not in the XML data.

How to fix it: Check your company master data in your ERP. Ensure the registered legal name is populated and that your invoice XML template maps it to the correct element under cac:AccountingSupplierParty/cac:Party.

Full fix guide →

2. BR-07: Buyer Name Missing

Rule: An invoice shall have the buyer name.

BR-07 is the mirror of BR-06 for the buyer side. The Buyer group (BG-7) must include the buyer's name. No name, no valid invoice.

Why it happens: The customer record in your ERP is incomplete. The company name field is blank, or the export template pulls from a contact name field that's empty for that specific customer.

How to fix it: Update the customer record in your ERP with the buyer's legal company name. Verify that your XML template maps from the correct field under cac:AccountingCustomerParty/cac:Party.

Full fix guide →

3. BR-05: Currency Code Missing

Rule: An invoice shall have a document currency code.

BR-05 requires a valid ISO 4217 currency code in BT-5 (the cbc:DocumentCurrencyCode element). It must be a three-letter code like EUR, GBP, or SEK — not "Euro", not "€", not empty.

Why it happens: The template doesn't include the currency element, or it maps to a display value ("Euro") instead of the ISO code ("EUR"). Some multi-currency ERPs leave the currency field blank when only one currency is configured.

How to fix it: Add <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode> (or your relevant currency code) to your invoice XML template. Make sure it pulls from your ERP's ISO currency code, not a display name.

Full fix guide →

4. BR-03: Issue Date Missing

Rule: An invoice shall have an invoice issue date.

BR-03 requires the invoice issue date (BT-2) in YYYY-MM-DD format. Without a valid issue date, the invoice has no legal standing.

Why it happens: The date field isn't mapped in the XML export, or it's formatted incorrectly. European locale settings often produce DD/MM/YYYY or DD.MM.YYYY, which fail XSD date validation. Some systems output 21-Apr-2026 — also invalid.

How to fix it: Ensure your ERP outputs dates in ISO 8601 format: 2026-04-28. If your ERP uses locale-specific date formatting, configure the XML export to override it with the ISO format.

Full fix guide →

5. BR-01: Specification Identifier Missing

Rule: An invoice shall have a specification identifier.

BR-01 requires BT-24 — the specification identifier that tells the receiver which standard and profile the invoice conforms to. For Peppol BIS 3.0, this must be urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0. For XRechnung, it includes the XRechnung version.

Why it happens: The template was built without the cbc:CustomizationID element, or it contains an outdated specification identifier from an older version. When XRechnung or Peppol releases a new version, templates that hard-code the old identifier start failing.

How to fix it: Add the correct cbc:CustomizationID value for your target format and version. Keep this value updated when new specification versions are released.

Full fix guide →

6. BR-10: Buyer Postal Address Missing

Rule: The buyer shall have a postal address with at least a country code.

BR-10 requires the buyer's postal address group (BG-8) to include at minimum the country code element (cbc:IdentificationCode within cac:Country). Street, city, and postal code are optional at the EN 16931 level, but the country code is mandatory.

Why it happens: The customer record has a full address in a single text field but doesn't break it into structured components. Or the address mapping in the XML template includes street and city but skips the country code element.

How to fix it: Ensure the buyer's country code is mapped to the correct XML element. Use ISO 3166-1 alpha-2 codes (DE, FR, BE, NL, etc.), not country names.

Full fix guide →

7. BR-12: Invoice Total with VAT Required

Rule: An invoice shall have the invoice total amount with VAT.

BR-12 requires the total payable amount including VAT (BT-112) in cbc:TaxInclusiveAmount within the cac:LegalMonetaryTotal group. This is the amount the buyer owes.

Why it happens: The XML template calculates and includes the net total and VAT total but doesn't include the combined figure. Some ERP systems that compute VAT separately from the invoice total leave this element empty or omit it entirely.

How to fix it: Ensure your template includes cbc:TaxInclusiveAmount with the sum of the net total and VAT amount. The value must match the calculation: invoice total without VAT (BT-109) + VAT total (BT-110) = invoice total with VAT (BT-112).

Full fix guide →

8. BR-16: Invoice Line Must Have an Identifier

Rule: Each invoice line shall have an invoice line identifier.

BR-16 requires every cac:InvoiceLine element to contain a cbc:ID — a unique identifier for that line within the invoice. This is typically a sequential number (1, 2, 3...) but can be any string.

Why it happens: The ERP generates line items without populating the line ID field. This happens most often when migrating from a system that used positional line numbering (first line, second line) instead of explicit identifiers.

How to fix it: Add a <cbc:ID> element to each cac:InvoiceLine. Sequential integers work fine: <cbc:ID>1</cbc:ID>, <cbc:ID>2</cbc:ID>, etc.

Full fix guide →

9. UBL-CR-077: Disallowed StatementDocumentReference

Rule: A UBL invoice shall not include the StatementDocumentReference element.

UBL-CR-077 fires when the invoice XML contains a cac:StatementDocumentReference element. This element exists in the broader UBL 2.1 specification but is explicitly excluded from the Peppol BIS 3.0 and EN 16931 UBL profiles. Its presence makes the invoice invalid.

Why it happens: ERP systems that support multiple document types sometimes include reference elements from credit notes, statements, or older UBL versions in the invoice XML. Custom ERP export templates built from UBL 2.1 documentation rather than the restricted Peppol BIS subset also trigger this.

How to fix it: Remove the cac:StatementDocumentReference element and any of its children from your invoice XML template. If you need to reference a statement, use cac:AdditionalDocumentReference instead.

Full fix guide →

10. cvc-datatype-valid.1.2.1: Invalid Value Format

Rule: The value is not valid for the specified data type.

cvc-datatype-valid.1.2.1 is an XML Schema (XSD) error that fires at the very first validation layer. It means a field's value doesn't match the data type the schema expects. This is a catch-all error that can apply to any typed field.

Common triggers:

• Decimal amounts with commas: 1.234,56 instead of 1234.56 — XML Schema requires dot as decimal separator, no thousand separators
• Dates in wrong format: 21/04/2026 instead of 2026-04-21
• Booleans as words: Yes/No instead of true/false
• Text in numeric fields: TBD in a quantity or amount field

Why it happens: The ERP applies locale-specific formatting to values that must be in strict XML data types. European locales commonly use comma as the decimal separator, which breaks XML Schema decimal validation.

How to fix it: Identify which field is mentioned in the error message and ensure it uses the correct format. For amounts: dot-separated decimals, no thousand separators. For dates: YYYY-MM-DD. For booleans: true or false.

Full fix guide →

What These Errors Have in Common

Look at the list above. Seven out of ten are missing mandatory fields. Two are structural template issues. One is a data format problem. None of them are obscure edge cases.

These are not complex validation failures requiring deep technical knowledge. They're missing data and misconfigured templates. Every single one is fixable in minutes once you know which field to check.

The pattern is consistent:

• The data exists — it's in your ERP, in your customer records, in your company settings. It's just not making it into the invoice XML.
• The fix is in the template — map the right field to the right element, and the error never occurs again.
• One fix prevents hundreds of rejections — because the same template generates all your invoices. Fix BR-06 once, and every future invoice includes the seller name.

How to Prevent These Errors

The most effective prevention strategy is also the simplest: validate every invoice before you send it.

Validate Before Sending

Add a pre-submission validation step to your invoicing workflow. Run every outgoing invoice through a validator that checks all four rule layers. If it passes, send it. If it fails, fix it before it reaches the network.

This is the pattern used by every ERP vendor with consistently low rejection rates. The validation step catches errors at the source, before they become rejections, support tickets, and payment delays.

Use a Comprehensive Validator

Not all validators check all layers. Some only run schema validation and miss EN 16931 business rules. Some check EN 16931 but skip country CIUS rules. To catch all ten errors on this list, you need a validator that runs the full stack: XSD schema, EN 16931, format-specific rules (Peppol/XRechnung/ZUGFeRD), and country CIUS.

Our free validator checks all 1,326 rules. No account required. Upload your invoice XML, get a complete report in seconds.

Fix Templates, Not Individual Invoices

When you find an error, don't just fix the one invoice. Fix the template or master data that caused it. One template fix prevents the same error on every future invoice from that template.

Explore by Category

The error library organizes all 1,300+ rules into categories so you can find related errors quickly:

• Business rules — EN 16931 BR-* rules covering mandatory fields, amount calculations, and VAT logic
• Format rules — Peppol BIS, XRechnung, ZUGFeRD, and Factur-X format-specific requirements
• Syntax errors — XML Schema (XSD) validation failures including cvc-* errors and structural issues

FAQ

Which error is the single most common e-invoice rejection?

BR-06 (missing seller name) and BR-07 (missing buyer name) are consistently the top two. They're trivial to fix but easy to miss in template configuration because the name appears in the PDF layout but may not be mapped to the XML data layer.

Do these errors apply to all EU e-invoice formats?

The BR-* errors (1 through 8 on this list) apply to every EN 16931-based format: Peppol BIS, XRechnung, ZUGFeRD, Factur-X, and others. UBL-CR-077 applies specifically to UBL-based formats (Peppol BIS, XRechnung UBL). The cvc-datatype error applies to any XML-based invoice format.

Can these errors be auto-fixed?

Some can. Structural issues like UBL-CR-077 (removing a disallowed element) are auto-fixable because the fix doesn't change the invoice's commercial meaning. Missing business data like BR-06 (seller name) cannot be auto-fixed — the correct name must come from your system. Our validator classifies each error as auto-fixable, input-required, or blocked so you know exactly what needs manual attention.

I fixed one error and now I see a different one. Why?

Validation runs in layers. If your invoice fails at the schema level (layer 1), you won't see business rule errors (layer 2) until the schema error is fixed. Fixing a schema error lets validation proceed to the next layer, which may reveal additional issues. This is normal — it doesn't mean the fix created a new problem.

How do I check for all these errors at once?

Use a validator that runs all four rule layers in a single pass. Our free validator checks schema, EN 16931, format, and country rules simultaneously and returns every error in one report. That way you see the full picture and can fix everything before sending.