Why E-Invoice Validators Are Not Enough

Every EU e-invoicing guide ends with the same advice: validate your invoices. Run them through a validator. Check against EN 16931. Make sure they pass.

Good advice. Incomplete advice.

Validation tells you what's wrong. It doesn't fix anything. And for ERP vendors processing thousands of invoices through their pipeline, knowing what's wrong is only the starting point.

The Gap Between "Invalid" and "Compliant"

Here's what actually happens when an invoice fails validation:

1. The validator returns a list of errors — BR-CO-10, PEPPOL-EN16931-R010, BR-DE-15.
2. Someone on your team looks at the errors.
3. They trace each error back to the ERP export template or the source data.
4. They figure out the fix — sometimes trivial (wrong namespace), sometimes complex (VAT rounding logic).
5. They modify the invoice or the template.
6. They re-validate.
7. Repeat until it passes.

For one invoice, this is annoying. For a pipeline processing hundreds or thousands of invoices daily across multiple countries, formats, and customer configurations — this is a full-time job. Multiple full-time jobs.

The gap between "validator shows an error" and "invoice is compliant and sent" is where most of the operational cost lives. Not in the validation itself, but in everything that comes after.

Three Types of Errors

Not all validation errors are the same. Understanding the categories changes how you think about the problem.

Auto-Fixable: Structural Issues

These are errors where the commercial meaning of the invoice doesn't change. A wrong XML namespace prefix. A missing XML declaration. A date in the wrong format. A redundant whitespace character in an identifier field.

These errors are deterministic. The fix is unambiguous. There's exactly one correct resolution, and applying it doesn't alter what the invoice says — it alters how the invoice says it.

A validator flags these. A compliance gate fixes them automatically.

Input Required: Missing Business Data

These errors point to absent data that only the sender can provide. A missing buyer reference (BT-10). A purchase order number that the ERP didn't populate. A country-specific identifier that the customer's record doesn't include.

No system can guess this data. A validator flags the absence. A compliance gate stops the invoice and requests the specific input needed — not a generic "fix your errors" message, but a precise field-level request.

Blocked: Financial Fields

Amounts. VAT totals. Tax calculations. IBANs. Payment terms. Line item prices.

These fields are the commercial substance of the invoice. Modifying them — even to make validation pass — changes what the invoice says. A rounding error in the VAT total might mean the sum doesn't match the line items. The "fix" might be to adjust the total. But adjusting a financial total without explicit authorization is not a fix — it's a liability.

A validator doesn't distinguish. It shows "BR-CO-10: sum mismatch." A compliance gate classifies this as blocked and routes it for human review. The financial fields are architecturally protected — not configurable, not overridable.

The Revalidation Step

Fixing errors introduces risk. What if the fix creates a new error? What if a structural correction interacts with a country-specific rule in an unexpected way?

This is why revalidation matters. Every auto-fixed invoice should be validated again — not by the same system that fixed it, but by an independent validator. KoSIT (Germany's Koordinierungsstelle für IT-Standards) maintains the reference validation implementation. Running every remediated invoice through KoSIT revalidation before release ensures the fix didn't break something else.

Validate → classify → fix (where safe) → revalidate → release. That's the pipeline. Validators handle step one. The other four steps are where compliance actually happens.

The Evidence Trail

When an invoice passes through a compliance gate, three things should be recorded:

1. What was validated — the original invoice, the rule sets applied, the errors found.
2. What was changed — every auto-fix, documented with before/after values and the rule that triggered it.
3. What the final result was — the revalidation result confirming the remediated invoice passes all rules.

This is the Evidence Pack. It's the audit-ready proof that your invoice was compliant when it left your system. If a tax authority questions an invoice two years from now, the Evidence Pack shows exactly what happened.

Validators don't produce evidence packs. They produce error lists. The evidence trail is a compliance function, not a validation function.

What This Means for ERP Vendors

If you're building e-invoicing into an ERP product, validation is necessary but not sufficient. Your customers don't just need to know their invoices are invalid — they need those invoices to become valid, quickly, at scale, without manual intervention for every structural fix.

The architecture that solves this: a pre-submission compliance gate that sits between your ERP export and the Peppol Access Point (or other delivery channel). It validates, classifies, remediates (where safe), revalidates, and generates evidence — all before the invoice leaves your system.

That's what we built. See how it works →

FAQ

Can't I just fix errors manually?

For low volumes, yes. For pipelines processing hundreds of invoices daily across multiple countries and formats, manual remediation doesn't scale. The cost per invoice rejection (investigation, fix, revalidation, resend) compounds quickly.

Why not just fix the ERP export template?

You should. But templates drift across customers, country rules change quarterly, and edge cases (cross-border VAT, mixed currency, credit notes) produce errors that no template handles perfectly. Pre-submission validation catches what slips through.

Is auto-remediation safe?

Only when done correctly. The key principles: never modify financial fields, only fix structural issues where the commercial meaning is unchanged, always revalidate after fixing, always document what was changed. That's the architecture — not a configuration option.

How does Invoice Navigator handle this?

We validate against all four rule layers (XML schema, EN 16931, format rules, country CIUS), classify every error (auto-fix / input required / blocked), remediate structural issues, revalidate through KoSIT, and generate an Evidence Pack. Financial fields are never touched. Try the free validator →