How to Choose an E-Invoice Validation Solution: A Buyer's Guide

You've decided your organization needs e-invoice validation. Maybe you're an ERP vendor adding compliance checks, an access point operator filtering invalid invoices, or a finance team preparing for a new country mandate. You search for solutions and find... a lot of options. Open-source validators. Commercial APIs. SaaS platforms. ERP plugins. Government reference implementations.

How do you evaluate them? What actually matters — and what's marketing noise?

This guide covers the seven criteria that separate a validation tool you'll rely on from one you'll replace within a year. It also covers the questions most evaluation teams forget to ask until it's too late.

The Landscape: What's Out There

Before diving into evaluation criteria, here's the territory. E-invoice validation tools roughly fall into four categories:

Open-source / government reference validators — Most notably KoSIT, Germany's official validation tool. Free, open-source, and used as the reference implementation for XRechnung. Accurate and authoritative — it defines what "correct" means.

Commercial validation APIs — Cloud services exposing validation via REST API. Some also offer auto-remediation, evidence generation, and multi-format support. Invoice Navigator falls in this category.

ERP built-in validation — SAP, Dynamics, Oracle and others increasingly include e-invoice validation. Quality varies widely — some run full Schematron rule sets, others do basic structural checks.

Peppol Access Point validation — Your access point validates as part of delivery. But this is a gate, not a development tool — you discover errors when your invoice is rejected, not before.

Criterion 1: Rule Coverage

This is the most important and most often oversimplified. When a vendor says "we validate against EN 16931," ask: which version? Which rules specifically?

A complete e-invoice validation stack covers multiple layers:

• XSD schema validation — structural conformity (element names, data types, required elements)
• EN 16931 business rules (BR-*) — the ~65 core rules covering mandatory fields, calculations, and VAT logic
• Co-occurrence rules (BR-CO-*) — conditional field requirements
• Conformance rules (UBL-CR-* or CII-SR-*) — syntax-specific element filtering
• CIUS rules — country-specific extensions like XRechnung (BR-DE-*), Peppol BIS (PEPPOL-EN16931-R*), or national rules for France, Italy, Poland, etc.

Some validators only implement the EN 16931 core rules and skip the conformance or CIUS layers. That means an invoice might "pass" their validation but get rejected by a Peppol access point or a German government portal because a BR-DE-* rule was violated.

Ask specifically: do you cover business rules, format rules, syntax rules, and country-specific rules? And for which countries?

Criterion 2: Format Support

EU e-invoicing isn't a single format — it's a family of formats built on the EN 16931 semantic model. At minimum, a useful validator should support:

• UBL 2.1 — used by Peppol, XRechnung, and most Northern/Western European implementations
• CII D16B — used by Factur-X, ZUGFeRD, and French implementations
• XRechnung — Germany's national CIUS (in both UBL and CII variants)
• Factur-X / ZUGFeRD — hybrid PDF/A-3 with embedded CII XML

Depending on your market, you might also need:

• FatturaPA — Italy's national format
• KSeF — Poland's structured e-invoice format (connected to the national system)
• Peppol BIS Billing 3.0 — the Peppol-specific rule layer on top of UBL

The depth of format support matters too. Some validators can parse a ZUGFeRD PDF but don't validate the PDF/A-3 conformance — they only check the extracted XML. A ZUGFeRD invoice with valid XML but a non-compliant PDF container will pass their validation and still get rejected in production.

For a deeper look at the UBL vs CII decision, see our UBL vs CII comparison guide.

Criterion 3: Auto-Remediation

This is where the market splits dramatically. Most validators only flag errors. Some also fix them.

The distinction matters because knowing an invoice has errors is only the beginning. Someone still needs to fix those errors, re-generate the invoice, and re-validate. At scale — hundreds or thousands of invoices per day — manual remediation is a bottleneck that consumes developer time and delays delivery.

Auto-remediation (also called auto-fix) means the system can automatically correct certain categories of errors:

• Structural fixes — wrong namespace prefixes, missing XML declarations, incorrect element ordering
• Format fixes — date format conversion (DD-MM-YYYY to YYYY-MM-DD), whitespace normalization, invalid code values
• Missing identifiers — adding scheme identifiers that the standard requires but the source system omitted

The critical question is what the system won't fix. Financial fields — amounts, VAT totals, tax calculations, IBANs — should never be modified automatically. Changing a payable amount to make validation pass isn't a fix; it's a liability. Any credible remediation system must have clear boundaries around which fields are auto-fixable and which are blocked.

Criterion 4: Evidence and Audit Trail

When a tax authority audits you in three years, can you prove your invoice was compliant when it left your system?

An Evidence Pack is the answer. It's a structured record containing:

1. The original invoice — what came out of your ERP
2. The validation result — every rule checked, every error found
3. The remediation log — every auto-fix applied, with before/after values and the rule that triggered it
4. The revalidation result — proof that the fixed invoice passes all rules
5. Tamper-evident metadata — checksums or signatures that prove the evidence wasn't altered after the fact

Most validators produce error lists. Very few produce evidence packs. The difference becomes important when compliance isn't just about getting the invoice through the network today — it's about proving compliance in an audit later.

Ask: does your validation result include a hash of the validated document? Is the evidence package tamper-evident? Can it be stored independently and verified later?

Criterion 5: Integration Model

How does the validator fit into your existing infrastructure? The main options:

• REST API — most flexible. Send an invoice via HTTP, get structured results back. Look for clear documentation, SDK support, and sandbox environments.
• Web interface — useful for ad-hoc checks during development and for finance teams spot-checking invoices. Not for production pipelines.
• ERP plugin — convenient if your entire workflow lives in one ERP, but can create vendor lock-in.
• CI/CD integration — validate test invoices in your build pipeline to catch regressions when templates change.
• Self-hosted — KoSIT can be deployed on your infrastructure since it's open source. Some commercial vendors offer on-premise options at a premium.

Criterion 6: Pricing

Pricing models vary more than you'd expect: per-invoice, subscription tiers, open-source, or bundled with Peppol access point fees.

The hidden cost in open-source is maintenance. EU rules change frequently — XRechnung updates roughly twice per year, Peppol updates quarterly, new country mandates bring entire new rule sets. Keeping a self-hosted validator current requires dedicated effort.

The hidden cost in commercial solutions is lock-in. If validation results use proprietary error codes, switching providers means rewriting your error-handling code. Look for vendors whose responses include standardized rule IDs (BR-*, UBL-CR-*, PEPPOL-EN16931-R*) rather than proprietary identifiers.

Criterion 7: Freshness

This is the criterion most evaluation teams skip — and the one that causes the most pain six months after deployment.

EU e-invoicing rules are not static. In a typical year:

• XRechnung releases 1-2 specification updates with new or modified BR-DE-* rules
• Peppol publishes rule updates roughly quarterly
• New country mandates (Poland's KSeF, Belgium's B2B, France's reform) introduce entirely new rule sets
• The EN 16931 standard itself gets corrections and clarifications

When a new XRechnung version drops, there's typically a transition period (a few months) where both the old and new versions are accepted, then the old version is deprecated. If your validator doesn't update within that window, your invoices will start failing — not because they changed, but because the rules did.

Ask your vendor: how quickly do you add new rules after a specification update? Is the update automatic, or do we need to download and deploy a new version? Do you support validation against multiple specification versions simultaneously (important during transition periods)?

The Questions Most Buyers Forget to Ask

Beyond the seven criteria above, here are the questions that tend to surface only after you've made a choice — usually when something goes wrong.

"What happens when a new country mandate drops?"

Belgium's B2B mandate is arriving. Poland's KSeF continues evolving. Romania, Spain, and others are announcing new requirements. When a new country enters the picture, how fast does your validator add support? Days? Weeks? Quarters?

Some commercial validators have dedicated compliance teams that track mandate developments and pre-build rule sets before mandates take effect. Others are reactive — they add support after customers start asking for it. If you're operating across multiple EU markets, the proactive approach is worth paying for.

"Do you validate the fixed invoice too?"

This sounds obvious, but not every remediation tool revalidates after fixing. If an auto-fix introduces a new error (it happens — fixing one field can violate a cross-field business rule), you need to catch it before the invoice is sent.

The correct pipeline is: validate, fix, revalidate, release. If the tool skips the revalidation step, you're flying blind on the fixed invoice. Ask specifically: after auto-remediation, is the corrected invoice run through the full validation stack again? This is what makes the difference between a pipeline that works and one that ships invoices that pass one rule but break another. For more on this pattern, see our guide on how to validate e-invoices.

"Can I self-host, or is it cloud-only?"

For banks, government agencies, and defense contractors, sending invoice data to a third-party API may not be an option. KoSIT is the strongest self-hosted choice: open-source Java, deployed on your infrastructure, no data leaves your network. The trade-off is you're responsible for updates, scaling, and integration. Some commercial vendors offer on-premise deployments at a premium.

"What's the latency for real-time validation?"

If validation is in your critical path — the invoice doesn't ship until it passes — latency matters. Ask for P50 and P99 numbers for single-invoice validation. Ask what happens under load. A 5-second response is fine for overnight batch jobs; it's unacceptable in real-time pipelines.

"How do you handle conflicting rules?"

EU e-invoicing has rule conflicts — a Peppol rule might require a field that a national CIUS makes optional. Mature validators have documented conflict resolution policies. Ask: when rules conflict, how do you decide which applies?

Putting It Together

Score each option on the seven criteria above, weighted by your priorities. A few patterns tend to emerge:

• Maximum control, strong DevOps team: KoSIT (self-hosted) scores high on rule coverage and cost, lower on auto-remediation and freshness (you manage updates yourself).
• Hands-off compliance with auto-fix: a commercial API scores high on remediation, evidence, and freshness, with the trade-off of subscription pricing.
• Single-country, single-ERP: built-in validation might be sufficient today, but usually falls short when you add countries or formats.

Where Invoice Navigator Fits

In the interest of honesty: Invoice Navigator is a commercial validation platform. Here's a balanced view.

Strong fit: multi-format auto-detection (UBL, CII, XRechnung, Factur-X, ZUGFeRD, Peppol BIS), auto-fix with safety boundaries (financial fields are architecturally blocked), Evidence Packs, free tier with no account required, and a 1,300+ error library with plain-English explanations.

KoSIT might be better if: you have strict data residency requirements, only validate XRechnung, and have DevOps capacity to manage Schematron updates and Java deployments.

ERP built-in might be enough if: you operate in a single country with stable templates and rare errors.

FAQ

Is open-source validation really free?

The software is free. The operational cost is not. Running KoSIT in production means hosting, configuring, keeping Schematron rule files current, monitoring uptime, and scaling. For a team with existing DevOps infrastructure, this cost is marginal. For a team without it, setup and maintenance can exceed the cost of a commercial API.

Can I use multiple validators together?

Yes, and many organizations do. A common pattern is using KoSIT as a reference check (because it's the authoritative German government validator) alongside a commercial API for auto-remediation and evidence generation. This gives you the best of both: government-endorsed validation accuracy plus operational automation.

How important is Schematron version alignment?

Critical. If your validator is running XRechnung 3.0.1 Schematron rules but your invoices use the XRechnung 3.0.2 specification identifier, the validator might reject valid invoices or accept invalid ones. Always verify that your validator supports the exact specification version your invoices claim to conform to.

What if my ERP vendor says their validation is "EN 16931 compliant"?

Ask them to be specific. "EN 16931 compliant" could mean they run all ~65 BR-* rules, or it could mean they check 10 mandatory fields and call it compliant. Ask for the specific Schematron files they use, the version numbers, and whether they include CIUS-specific rules (XRechnung BR-DE-*, Peppol PEPPOL-EN16931-R*, etc.). If they can't answer, their validation is probably incomplete.

Should I validate incoming invoices or just outgoing ones?

Both. Outgoing validation prevents rejections. Incoming validation protects your ERP from ingesting malformed data that could cause processing errors or failed reconciliation — especially important if you receive invoices from many suppliers with varying e-invoicing maturity.

How fast do rules actually change?

Expect 2-4 rule updates per year across the specifications you care about. XRechnung updates roughly twice per year, Peppol quarterly. New country mandates can add entire new rule sets. The pace is accelerating as more EU countries adopt mandates.

---

Ready to test your invoices? The free validator runs the full validation stack — schema, business rules, format rules, and country-specific rules — with no account required. For API integration, see the developer documentation or check pricing for production use.