Guide
Markdown exportEU top markets playbook (DE, FR, IT, ES, PL, NL)
If you sell across Europe, you do not need 27 completely different implementations. You need a strong core (EN 16931 mapping + validation) and a small set of country adapters (routing IDs, channels, and constraints). This playbook starts with the largest and most mature markets.
A repeatable approach (core + country adapters)
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).
Checklist: A repeatable approach (core + country adapters)
Use these points as the practical checks for this section.
- Core: EN 16931 mapping + code lists + VAT logic
- Adapter: routing ID/portal + profile validation
- Ops: retry + audit trail + storage
Germany (DE): XRechnung + Leitweg-ID, plus ZUGFeRD in business workflows
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.
Checklist: Germany (DE): XRechnung + Leitweg-ID, plus ZUGFeRD in business workflows
Use these points as the practical checks for this section.
- Routing/IDs: Leitweg-ID in B2G scenarios
- Syntax: UBL or CII (XRechnung profiles)
- Pitfalls: buyer reference fields, addresses, VAT breakdown
France (FR): platform workflows + FacturâX as a practical bridge
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.
Checklist: France (FR): platform workflows + FacturâX as a practical bridge
Use these points as the practical checks for this section.
- Identifiers: SIREN/SIRET + VAT ID
- Format: FacturâX (EN 16931 profile) commonly used
- Pitfalls: party identifiers and address strictness
Italy (IT): clearance-style delivery via SdI (FatturaPA)
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.
Checklist: Italy (IT): clearance-style delivery via SdI (FatturaPA)
Use these points as the practical checks for this section.
- Channel: SdI
- Format: FatturaPA XML
- Pitfalls: recipient codes (Codice Destinatario/PEC), platform acknowledgements
Spain (ES): public sector portals and evolving B2B requirements
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.
Checklist: Spain (ES): public sector portals and evolving B2B requirements
Use these points as the practical checks for this section.
- Channel: FACe for B2G
- Formats: Facturae and sometimes UBL
- Pitfalls: identifier formats (NIF/CIF) and address completeness
Poland (PL): KSeF as a structured platform with strict technical expectations
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.
Checklist: Poland (PL): KSeF as a structured platform with strict technical expectations
Use these points as the practical checks for this section.
- Channel: KSeF
- Format: structured XML (platform-defined)
- Pitfalls: error/status handling and operational resilience
Netherlands (NL): PEPPOL-first exchange patterns
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.
Checklist: Netherlands (NL): PEPPOL-first exchange patterns
Use these points as the practical checks for this section.
- Channel: PEPPOL
- Format: PEPPOL BIS Billing 3.0 (UBL)
- Pitfalls: wrong participant IDs and profile rule mismatches
Testing strategy for multi-country rollouts
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.