Sur cette page
- Approche réutilisable (socle + adaptateurs pays)
- Allemagne (DE) : XRechnung + Leitweg‑ID, et ZUGFeRD dans les workflows
- France (FR) : workflows plateforme + Factur‑X comme pont pratique
- Italie (IT) : transmission type clearance via SdI (FatturaPA)
- Espagne (ES) : portails secteur public et exigences B2B en évolution
- Pologne (PL) : KSeF, plateforme structurée et exigences techniques strictes
- Pays‑Bas (NL) : modèles d’échange “PEPPOL‑first”
- Stratégie de tests pour déploiements multi‑pays
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).
- 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é.
- 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é.
- 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.
- 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.
- 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é.
- 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.
- 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.