EU top markets playbook (DE, FR, IT, ES, PL, NL)

Build one canonical invoice data model, then export into the required syntaxes (UBL/CII/FatturaPA/KSeF). Keep validation close to generation and treat errors as product feedback.

Country adapters should be small: recipient identifiers, transport channels, and a handful of rule deltas (CIUS).

Germany is strongly associated with XRechnung for public sector invoicing. XRechnung is essentially EN 16931 expressed in UBL or CII with German-specific rules.

In many B2B workflows, ZUGFeRD/Factur‑X (PDF + embedded XML) is used because it preserves a human-readable PDF while enabling structured processing.

France is a major market where platform-based exchange is common, especially for public sector invoicing. Expect requirements around French business identifiers (SIREN/SIRET) and strict party data quality.

Factur‑X (based on EN 16931) is often used as a bridge format because it combines PDF readability with structured XML.

Italy is the reference case for platform-driven e‑invoicing. Invoices are exchanged via the “Sistema di Interscambio” (SdI) using the FatturaPA XML format.

Technically, this often means: format compliance + strict identifiers + handling platform responses as part of your issuance workflow.

Spain has well-established public sector e‑invoicing via FACe and uses formats like Facturae. Depending on your segment, you may also see UBL-based exchanges.

For cross‑border and multi‑country implementations, focus on clean party identifiers and consistent VAT logic—then adapt the delivery channel.

Poland is one of the most important “structured platform” markets. In practice, the key is: reliable integration, precise data, and handling platform responses and status.

Plan for operational excellence: retries, monitoring, and long-term storage of what you sent and what was accepted.

The Netherlands is strongly aligned with PEPPOL BIS and network exchange. This makes it a good anchor country for a “network first” strategy.

In PEPPOL contexts, participant IDs and endpoint discovery are as important as the invoice XML itself.

Use a small but representative invoice set and keep it stable: one simple invoice, one with multiple VAT rates, one with allowances/charges, one with prepayments, and one credit note.

For each country/channel, validate locally and then with the target validator or sandbox. Keep the exact XML that passed as a fixture.