E-invoicing software for Europe: what to check before you choose

E-invoicing software for a European business has to do seven things well: generate the right structured format for each country, validate it before the invoice is issued, carry it over the channel that country uses, read incoming structured invoices, keep the structured original for the retention period, decide the VAT treatment from the facts of the transaction, and expose all of that to other systems through an API. No single product does all seven in every country without limitations; the useful question is which limitations, and whether the vendor names them.

Format generation: one invoice, four national dialects

The software must produce the exact format each mandate expects — XRechnung or ZUGFeRD for Germany, Factur-X for France, Peppol BIS Billing 3.0 for Belgium, FA(3) for Poland — from the same invoice data, without the user editing XML.

Three of the four are profiles of EN 16931, the European semantic standard whose parts 1 and 2 the Commission makes available free of charge through national standards bodies; the fourth, Poland's FA(3), is a national schema of its own. "Supports EN 16931" is therefore necessary but not sufficient. Ask specifically:

• Which syntaxes for Germany — XRechnung in UBL, in CII, or both? ZUGFeRD in which profiles (the BMF FAQ excludes MINIMUM and BASIC-WL from the e-invoice definition)?
• Does the French output embed the CII XML in a PDF/A-3 (Factur-X) so that the same file serves humans and machines?
• Is the Belgian output the Peppol BIS Billing 3.0 UBL that the network validates, or a generic UBL that a receiving access point may reject?
• Which FA version for Poland — FA(3) is the current schema — and can the software also render the visualisation with the KSeF number and QR code that the Ministry requires when an invoice is used outside the system?
• Is the format chosen automatically from the issuing company's country, or does the user have to pick?

The format guide maps each format to its country and mandate.

Validation before issuance, not after rejection

A structured invoice that fails the national business rules is not an e-invoice under that mandate; the software should run those rules before the number is assigned, not learn about failure from a rejected transmission.

Validation has layers: XML schema, EN 16931 Schematron rules, national CIUS rules (KoSIT's for XRechnung, the Peppol BIS rules for Belgium, the FA(3) schema for Poland), and cross-checks such as totals and VAT breakdown arithmetic. Ask which layers run, whether the rule sets are the current versions (the standard's 2026 edition triggers a migration, and KoSIT and OpenPeppol publish releases on their own schedules), and whether a failed validation blocks issuance or only warns. A free online checker that validates a file against a country's rules is a fair way to test a vendor's claims — see the e-invoice checker.

Transport: the part that differs most by country

Germany prescribes no channel, Belgium prescribes Peppol, France prescribes registered platforms, Poland prescribes its state system; software that covers all four either integrates each channel or names which it hands off to a provider.

Be precise about the words. "Peppol-ready" can mean an accredited access point, a connection through one, or merely the ability to export a BIS file. "KSeF-ready" can mean production use or a module tested only against the sandbox. The vendor should say which; the network comparison explains why the distinction matters.

Receiving: turning incoming XML into bills

Every mandate starts with receiving, so the software must read XRechnung, ZUGFeRD/Factur-X and UBL files — from email, upload or a network — into a purchase record without retyping.

Ask what happens with a hybrid PDF: is the embedded XML extracted and used, or is the PDF treated as an image? Ask whether the supplier, amounts, VAT breakdown, due date and payment reference are mapped into the bill, and whether a file that fails validation is refused or flagged. Ask how incoming Peppol documents reach the inbox once the company's identifier is registered. For Germany see receiving e-invoices.

Archiving: the structured file is the original

Where the invoice is a structured file, that file — not a PDF rendering of it — is what has to be kept for the national retention period, unchanged and retrievable.

The Belgian authority notes that "the rules on archiving remain unchanged" by the mandate, which is true everywhere: retention periods and integrity requirements are national and predate e-invoicing. What changes is the object. Ask whether the software stores the issued XML (and the received XML) as sent, whether it can export the archive in bulk, and whether an invoice remains retrievable after a subscription ends. Retention periods and any national requirements on immutability or audit trails require professional confirmation.

Tax verdicts: decided from facts, not typed in

The VAT line on an invoice follows from the seller's country, the buyer's country, the buyer's status as a business and the kind of supply; software should derive it from those facts and refuse to guess where the facts are insufficient.

This matters more in Europe than anywhere, because the structured formats carry the VAT category codes and exemption reasons explicitly and validators check them against the amounts. Ask whether the software distinguishes standard, zero-rated, exempt, reverse charge and outside-scope outcomes, whether it checks the buyer's VAT ID against VIES at issuance, whether it stores the decision with the invoice for later audit, and — importantly — whether it has an honest "requires input" state instead of a default rate. See cross-border e-invoicing for the rules behind the verdicts and the free VAT ID checker.

API: the invoice is usually created somewhere else

For a SaaS, marketplace or ERP-driven business the invoice originates in another system; the e-invoicing software needs a documented API with authentication, idempotent creation, webhooks and a test mode.

Ask whether the API creates drafts that are then issued under the product's validation, or issues legal invoices directly (which bypasses the checks above); whether keys can be scoped to a single company and to read or write; whether POST requests accept an idempotency key so that a retried call cannot create two invoices; which events are pushed by webhook and how they are signed; and what the rate limit is. Developers will want to read the reference before buying — see the e-invoicing API and the API reference.

The checklist

Twelve questions that separate coverage from claims; a vendor that answers each with a plain yes, no or "through provider X" is telling you what you need to know.

1. Which national formats are generated automatically from the company's country, and in which syntaxes and profiles?
2. Which validation rule sets run before issuance, and which versions?
3. Does a failed validation block issuance?
4. For Belgium: which accredited access point carries the traffic, and is the vendor one itself?
5. For France: is the vendor a plateforme agréée, or which PA does it transmit through, and is that live?
6. For Poland: has the KSeF integration been used in production?
7. Are incoming XRechnung, ZUGFeRD/Factur-X and UBL files read into bills with the embedded XML?
8. Is the structured original stored as issued and exportable in bulk?
9. Is the VAT treatment derived from the transaction's facts, with a VIES check and a stored verdict?
10. Does the API create drafts under validation, with scoped keys, idempotency and signed webhooks?
11. Is there a test mode that behaves like production?
12. Which of the above are described by the vendor as limitations, and are the limitations dated?

How KRONENWERK handles this

KRONENWERK covers formats, validation, receiving, tax verdicts and the API in full; transport is where the limitations sit, and they are named below.

KRONENWERK does not file or remit any tax, does not provide tax or legal advice and holds no security certification; it makes no guarantee about compliance outcomes. Beyond e-invoicing it is an accounting product — double-entry ledger, bills and expenses, bank connections through Enable Banking and Plaid, multi-company and multi-currency, five interface languages. See e-invoicing in KRONENWERK, invoicing, plans and, for developers, the developer overview. Back to the Europe hub.