# Playbook des principaux marchés UE (DE, FR, IT, ES, PL, NL)

Si vous vendez à l’échelle européenne, vous n’avez pas besoin de 27 implémentations totalement différentes. Il vous faut un socle fiable (mapping EN 16931 + validation) et un petit ensemble d’adaptateurs pays (IDs de routage, canaux, contraintes). Ce playbook commence par les marchés les plus importants et matures.

## Approche réutilisable (socle + adaptateurs pays)

Construisez un modèle canonique de données de facture, puis exportez vers les syntaxes requises (UBL/CII/FatturaPA/KSeF). Gardez la validation proche de la génération et traitez les erreurs comme du feedback produit.

Les adaptateurs pays doivent rester petits : identifiants destinataire, canaux de transport et quelques écarts de règles (CIUS).

## Checklist pratique: Approche réutilisable (socle + adaptateurs pays)

- Socle : mapping EN 16931 + listes de codes + logique TVA
- Adaptateur : ID de routage/portail + validation de profil
- Ops : retry + audit trail + stockage

## Allemagne (DE) : XRechnung + Leitweg‑ID, et ZUGFeRD dans les workflows

L’Allemagne est fortement associée à XRechnung pour la facturation au secteur public. XRechnung est essentiellement EN 16931 exprimé en UBL ou CII avec des règles spécifiques allemandes.

Dans de nombreux workflows B2B, ZUGFeRD/Factur‑X (PDF + XML embarqué) est utilisé pour conserver un PDF lisible tout en permettant le traitement structuré.

## Checklist pratique: Allemagne (DE) : XRechnung + Leitweg‑ID, et ZUGFeRD dans les workflows

- Routage/IDs : Leitweg‑ID en B2G
- Syntaxe : UBL ou CII (profils XRechnung)
- Pièges : références acheteur, adresses, ventilation TVA

## France (FR) : workflows plateforme + Factur‑X comme pont pratique

La France est un grand marché où l’échange via plateforme est courant, notamment pour la facturation au secteur public. Attendez‑vous à des exigences sur les identifiants (SIREN/SIRET) et une forte qualité des données des parties.

Factur‑X (basé sur EN 16931) sert souvent de format “pont” car il combine lisibilité PDF et XML structuré.

## Checklist pratique: France (FR) : workflows plateforme + Factur‑X comme pont pratique

- Identifiants : SIREN/SIRET + TVA
- Format : Factur‑X (profil EN 16931) fréquent
- Pièges : identifiants des parties et rigueur des adresses

## Italie (IT) : transmission type clearance via SdI (FatturaPA)

L’Italie est le cas d’école de l’e‑facturation pilotée par plateforme. Les factures transitent via le “Sistema di Interscambio” (SdI) au format XML FatturaPA.

Techniquement, cela implique souvent : conformité au format + identifiants stricts + traitement des retours plateforme comme partie du workflow d’émission.

## Checklist pratique: Italie (IT) : transmission type clearance via SdI (FatturaPA)

- Canal : SdI
- Format : FatturaPA XML
- Pièges : codes destinataire (Codice Destinatario/PEC), accusés plateforme

## Espagne (ES) : portails secteur public et exigences B2B en évolution

L’Espagne dispose d’une e‑facturation B2G bien établie via FACe et utilise des formats comme Facturae. Selon le secteur, des échanges basés sur UBL peuvent aussi apparaître.

Pour des implémentations multi‑pays, misez sur des identifiants de parties propres et une logique TVA cohérente, puis adaptez le canal.

## Checklist pratique: Espagne (ES) : portails secteur public et exigences B2B en évolution

- Canal : FACe en B2G
- Formats : Facturae et parfois UBL
- Pièges : formats d’identifiants (NIF/CIF) et complétude des adresses

## Pologne (PL) : KSeF, plateforme structurée et exigences techniques strictes

La Pologne est l’un des principaux marchés “plateforme structurée”. En pratique : intégration fiable, données précises et gestion des retours/statuts plateforme.

Prévoyez l’excellence opérationnelle : retries, supervision et stockage long terme de ce qui est envoyé et accepté.

## Checklist pratique: Pologne (PL) : KSeF, plateforme structurée et exigences techniques strictes

- Canal : KSeF
- Format : XML structuré (défini par la plateforme)
- Pièges : gestion erreurs/statuts et résilience

## Pays‑Bas (NL) : modèles d’échange “PEPPOL‑first”

Les Pays‑Bas sont fortement alignés sur PEPPOL BIS et l’échange via réseau. C’est un bon pays “ancre” pour une stratégie “network first”.

En contexte PEPPOL, les identifiants participant et la découverte d’endpoint sont aussi importants que le XML.

## Checklist pratique: Pays‑Bas (NL) : modèles d’échange “PEPPOL‑first”

- Canal : PEPPOL
- Format : PEPPOL BIS Billing 3.0 (UBL)
- Pièges : mauvais IDs participant et écarts de règles de profil

## Stratégie de tests pour déploiements multi‑pays

Utilisez un petit jeu de factures représentatif et stable : une facture simple, une avec plusieurs taux TVA, une avec remises/frais, une avec acomptes et un avoir.

Pour chaque pays/canal : validation locale puis validation/sandbox cible. Conservez le XML “passé” comme fixture.

## Ressources associées

- [Guides pays (formats, routage, identifiants)](/resources/countries)
- [Guide du standard XRechnung](/resources/compliance/xrechnung-standard)
- [Profils ZUGFeRD expliqués](/resources/zugferd/profiles)
- [Guide du réseau PEPPOL](/resources/compliance/peppol-network-guide)