Guide
Export MarkdownPlaybook 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)
Utilisez ces points comme contrôles pratiques pour cette section.
- 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
Utilisez ces points comme contrôles pratiques pour cette section.
- 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
Utilisez ces points comme contrôles pratiques pour cette section.
- 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)
Utilisez ces points comme contrôles pratiques pour cette section.
- 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
Utilisez ces points comme contrôles pratiques pour cette section.
- 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
Utilisez ces points comme contrôles pratiques pour cette section.
- 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”
Utilisez ces points comme contrôles pratiques pour cette section.
- 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.