Why Your ERP Keeps Generating Invalid E-Invoices (And How to Stop It)

Your ERP says it supports e-invoicing. The sales team checked the box during procurement. The consultant configured the output format. You've been sending invoices for weeks, maybe months.

And they keep getting rejected.

The error messages are cryptic. Your Access Point tells you the invoice is invalid, but the invoice looks perfectly fine in your ERP's preview screen. The PDF is correct. The amounts are right. The customer details are there. So what's going wrong?

The answer is almost always the same: your ERP generates what it thinks is a valid e-invoice, but what it actually produces doesn't pass the validation rules that receivers enforce. There's a gap between "my ERP has an e-invoicing module" and "my invoices actually comply with EN 16931, Peppol BIS 3.0, and whatever country-specific rules apply."

This article covers the most common reasons ERPs produce invalid invoices, with specific examples from SAP, Microsoft Dynamics, Odoo, and Exact Online. More importantly, it covers what you can do about it.

The Gap Between "Supports E-Invoicing" and "Produces Valid Invoices"

ERP vendors implement e-invoicing support based on the standard as they understand it at the time of development. But the standard is a moving target. EN 16931 defines the semantic data model. Peppol BIS defines the syntax binding. Each country adds its own CIUS rules. And all of these get updated periodically.

The result: an ERP module that was compliant when it shipped may produce invoices that fail validation today, because the rules have been tightened, a new country mandate has added requirements, or the ERP's XML template has subtle issues that only surface under specific conditions.

Here are the patterns we see most often.

Problem 1: Wrong Date Formats

The EN 16931 standard requires dates in ISO 8601 format: YYYY-MM-DD. That means 2026-06-16, not 16/06/2026, not 06-16-2026, not June 16, 2026.

This sounds trivial, but date formatting is the source of a surprising number of rejections. The issue is that ERPs typically store dates in an internal format and then convert them for output. If the XML export template uses the system's locale settings instead of forcing ISO format, you get locale-dependent dates in your invoice XML.

SAP typically handles this well in standard configurations, but custom ABAP templates sometimes apply DD.MM.YYYY formatting (common in German locale settings) instead of the required ISO format.

Dynamics 365 can produce dates formatted according to the user's regional settings. If a German user's Windows locale is set to DD.MM.YYYY, the invoice XML may inherit that format unless the e-invoicing template explicitly overrides it.

Odoo generally uses ISO dates in its XML output, but third-party e-invoicing modules sometimes apply the company's date format preference, which may not be ISO 8601.

When the date format is wrong, you'll typically see a cvc-datatype-valid.1.2.1 error at the schema validation layer. The invoice never even reaches business rule validation — it fails immediately because the XML doesn't match the expected data type for date fields.

The fix: Check your ERP's XML export template. Ensure all date fields output YYYY-MM-DD regardless of the user's locale settings. This is a template-level fix, not a system setting.

Problem 2: Continental Decimal Separators

In much of continental Europe, the decimal separator is a comma and the thousands separator is a period. So a price might display as 1.234,56 in your ERP.

XML Schema, however, requires the dot as decimal separator with no thousands separator. The correct XML value is 1234.56.

This might seem obvious, but we regularly see invoices where amount fields contain values like 1.234,56 or 1,234.56 (correct separators but with thousands grouping, which is also invalid in XML). The cvc-datatype-valid.1.2.1 error fires because 1.234,56 isn't a valid decimal number according to the XML Schema definition.

Exact Online users encounter this when custom export configurations pull from display values rather than raw numeric fields. The ERP stores the amount correctly, but the export template reads the formatted display string instead of the underlying number.

SAP has well-known issues with thousand separators in certain output configurations. The WRITE statement in ABAP uses locale-dependent formatting by default, so a German system produces 1.234,56 unless the template explicitly uses NO-GROUPING and forces dot-as-decimal.

The fix: Ensure your XML output maps to raw numeric values, not display-formatted strings. Amount fields in XML should contain only digits and a single dot as decimal separator: 1234.56.

Problem 3: Disallowed XML Elements

Your ERP adds elements to the invoice XML that don't belong in the Peppol BIS 3.0 schema. The receiver's Access Point sees unknown elements and rejects the invoice.

This is the most common source of UBL-CR-* errors. These are "content restriction" rules — they flag elements that exist in the broader UBL 2.1 specification but are not permitted in the Peppol BIS profile.

Common offenders include StatementDocumentReference, OrderDocumentReference sub-elements beyond what BIS 3.0 allows, and custom extension elements that ERPs add for internal purposes.

Dynamics 365 sometimes includes additional reference elements in its UBL output that are valid in generic UBL but not in Peppol BIS. These elements carry internal data like payment batch references or ERP-specific identifiers that have no place in the Peppol schema.

Odoo with certain e-invoicing apps adds custom namespace extensions or additional party information elements that trigger UBL-CR rules.

The fix: Compare your ERP's XML output against the Peppol BIS 3.0 schema. Remove or suppress any elements that aren't part of the allowed subset. Run a sample invoice through a validator and look specifically for UBL-CR errors in the format rules category — each one will tell you exactly which element to remove.

Problem 4: Missing Mandatory Fields

Your ERP has all the data — but the XML template doesn't map every required field. The invoice looks complete in the ERP interface because the PDF template pulls from different fields than the XML template.

The most commonly missed fields across ERPs:

• Seller name (BR-06) — The registered legal name is missing from the XML seller party group
• Buyer postal address country code (BR-10) — The street and city are there, but the ISO 3166-1 alpha-2 country code element is missing
• Document currency code (BR-05) — The currency appears on line items but the document-level currency code element is empty
• Specification identifier (BR-01) — The CustomizationID is missing or contains an outdated value

SAP users frequently hit BR-10 because the address mapping populates street, city, and postal code but skips the country code element, especially when the country code is stored in a separate field in the business partner master data.

Exact Online tends to handle mandatory fields well in its standard templates, but custom configurations often omit the specification identifier (CustomizationID) or use a generic value that doesn't match the target network.

The fix: Run a representative invoice through the validator and check for business rule errors. Each BR-* error tells you exactly which field is missing. Then trace that field back to your ERP's XML template configuration and add the mapping.

Problem 5: Incorrect or Outdated CustomizationID

The cbc:CustomizationID element (BT-24) tells the receiver which specification profile your invoice conforms to. For Peppol BIS 3.0, the value must be exactly:

urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0

For XRechnung, it includes the XRechnung version number, which changes with each release. If your ERP hardcodes an older version string, invoices start failing when receivers update their validation rules.

This is a particularly frustrating failure because the invoice content is perfectly correct — it's just the header identifier that's wrong. The BR-01 error fires because the specification identifier is either missing or doesn't match the expected pattern.

The fix: Check your CustomizationID value against the current specification version. For Peppol, it rarely changes. For XRechnung, it updates with each new version (currently 3.0.2 as of 2026). If your ERP hardcodes this value, you'll need to update it after each specification release.

Problem 6: VAT Logic That Doesn't Match the Rules

Your ERP calculates VAT correctly for accounting purposes. But EN 16931 business rules enforce specific relationships between VAT-related fields that your ERP may not populate in the way the standard expects.

The most common issue: invoices with 0% VAT that don't include the required tax exemption reason code. When VAT is zero — whether for reverse charge, intra-community supply, or exempt services — the invoice must include a reason code in BT-121 explaining why. ERPs that handle the accounting correctly often leave this field empty in the XML because the accounting system doesn't need a coded reason.

Similarly, the calculation chain from line amounts to tax totals to the final payable amount must follow specific rules. BR-CO-10 through BR-CO-15 enforce that the sums actually add up as expected, with specific rounding tolerance rules. ERPs that calculate totals independently rather than deriving them from line items sometimes produce values that are off by a cent due to different rounding approaches.

The fix: Test with invoices that use 0% VAT rates — reverse charge, exempt, and intra-community supply scenarios. These edge cases are where VAT-related business rules most often fail. Check the business rules category for BR-CO-* errors.

The Real Fix: Validate Before Sending

Every problem above has a specific fix. But the underlying issue is the same: your ERP generates the invoice, sends it to the Access Point, and the first validation happens at the receiver's end. By then, you have a rejection, a payment delay, and a support ticket.

The pattern that eliminates this: validate every invoice before it reaches the Access Point. Add a pre-send validation step that catches errors while you can still fix them. The invoice passes through your compliance gate, fails fast if something is wrong, and only reaches the network when it's confirmed valid.

This works regardless of which ERP you use. SAP, Dynamics, Odoo, Exact Online, or any other system — the validator checks the output against all four rule layers (schema, business rules, format rules, country rules) and tells you exactly what's wrong before the invoice leaves your organization.

For teams building this into their workflow permanently, the validation pipeline guide covers the architecture for automated pre-send validation with auto-remediation of structural issues.

ERP-Specific Resources

If you're troubleshooting invoices from a specific system, start with the error codes you're seeing. Every error code in the error library includes the rule description, the exact XPath location where the error occurs, and fix instructions.

For ERP integration architecture — where to place the validation gate, how to handle errors programmatically, and how to build auto-remediation into your pipeline — see Integrating E-Invoice Compliance Into Your ERP.

FAQ

My ERP vendor says their system is EN 16931 compliant. Why do invoices still fail?

EN 16931 compliance means the system can produce the correct structure. It doesn't mean every invoice it generates will be valid. Missing master data (incomplete customer records, missing company details), misconfigured templates (wrong field mappings), and outdated specification identifiers all cause valid-looking invoices to fail. Compliance is about capability; validation is about each specific invoice.

Do I need to validate every invoice, or just test a sample?

Every invoice, ideally. Template issues affect all invoices from that template, but data issues (missing buyer country code, incomplete address) vary per customer. A sample test catches template problems but misses data-dependent errors. Automated pre-send validation catches both, with no manual effort per invoice.

Can these ERP-generated errors be auto-fixed?

Some can. Structural issues like extra XML elements (UBL-CR errors) can be stripped automatically because removing them doesn't change the invoice's commercial meaning. Date format conversion and decimal separator normalization are also automatable. But missing business data — a buyer name, a country code, a VAT reason — can't be invented. Those require fixing the source data in your ERP.

Which ERP produces the fewest validation errors?

None of them are immune. SAP, Dynamics, Odoo, and Exact Online all produce invalid invoices under certain configurations. The difference is usually in the quality of the initial configuration and how actively the templates are maintained as specifications evolve. The most reliable setups are the ones that validate every invoice before sending, regardless of which ERP generates it.

How do I find out which ERP template field maps to which XML element?

Start from the error. Each validation error includes the XPath — the exact location in the XML where the problem is. Trace that XPath back to your template configuration. In SAP, that's the IDoc or XML mapping. In Dynamics, it's the Electronic Reporting format configuration. In Odoo, it's the QWeb template or e-invoicing module settings. The how to validate guide covers reading error reports, including XPath locations.