Les formats de facturation électronique

Un format de facturation électronique est la structure lisible par une machine dans laquelle circule une facture — non pas le PDF d'une facture, mais la facture elle-même, sous forme de données qu'un système acheteur peut comptabiliser sans ressaisie. Il n'existe en Europe que deux syntaxes XML qui comptent (UBL 2.1 et UN/CEFACT CII), une norme sémantique par-dessus (EN 16931), puis une longue traîne de profils nationaux — Factur-X, ZUGFeRD, XRechnung, FatturaPA, Facturae, KSeF FA(3), ZATCA, MyInvois — qui contraignent les mêmes données pour l'administration fiscale d'un pays. Cette page est la carte complète, et dit exactement lesquels Flowie produit, accepte et délivre.

La réponse courte, par pays

Si vous ne lisez qu'une section, lisez celle-ci. En 2026, la question du format se ramène à quatre cas :

• Vous émettez dans l'UE via Peppol (Belgique, Pays-Bas, pays nordiques, Irlande, la plupart du B2G) → Peppol BIS Billing 3.0, c'est-à-dire de l'UBL 2.1 contraint à l'EN 16931. C'est ce que Flowie émet par défaut.
• Vous émettez vers un pays doté de sa propre plateforme de clearance (Italie, Pologne, Roumanie, Espagne, Arabie saoudite, Inde, Malaisie, Égypte, Turquie) → le format national que cette plateforme accepte, dédouané avant ou pendant la délivrance de la facture.
• Vous émettez en France ou en Allemagne → un PDF hybride Factur-X / ZUGFeRD, ou du CII/UBL simple, ou XRechnung pour les acheteurs publics allemands. Les trois sont légaux ; c'est la capacité de l'acheteur qui tranche.
• Vous ne savez pas → envoyez du JSON et laissez Flowie résoudre la capacité du destinataire depuis l'annuaire du réseau. C'est ce que répond POST /v1/directory/verify.

Les mandats, échéances et réseaux pays par pays sont documentés dans la section conformité — 47 juridictions, avec une matrice de couverture triable par réseau.

Les quatre couches : modèle, syntaxe, profil, réseau

Presque toutes les disputes sur les formats de facturation électronique sont deux personnes qui parlent de couches différentes. Une facture sur le réseau, ce sont quatre décisions empilées, et chacune est indépendante des autres :

Ce que Flowie gère

Deux directions, un endpoint chacune. À l'émission, le champ format de POST /v1/documents/send déclare ce que vous nous confiez :

À la réception, chaque document est disponible sous trois formes depuis les endpoints documents : l'artefact original tel que l'émetteur l'a déposé (le PDF Factur-X, si c'est ce qu'il a envoyé), le XML structuré, et le JSON normalisé que portent les webhooks. Vous n'avez jamais à parser une syntaxe que vous ne voulez pas supporter.

Sur le volet français, le flux AFNOR XP Z12-013 déclare explicitement sa syntaxe — CII, UBL, Factur-X pour les factures, plus CDAR pour les statuts du cycle de vie et FRR pour l'e-reporting. Voir le playbook d'intégration français.

Catalogue des formats

Tous les formats de facturation électronique que vous risquez de croiser, ce qu'ils sont vraiment, où ils sont exigés, et si Flowie les gère. Cliquez sur un en-tête de colonne pour trier.

Émission & réception signifie que Flowie produit le format à l'aller et le normalise au retour — vous travaillez en JSON et ne touchez jamais au schéma. Le détail pays par pays, y compris quel réseau porte quel format, est dans la matrice de couverture.

EN 16931 — la norme sémantique européenne

L'EN 16931 n'est pas un format de fichier. C'est le modèle sémantique de données qui dit ce que contient une facture : 164 termes métier (BT-1…) regroupés en groupes métier (BG-1…), plus environ 200 règles de gestion qui disent quand chacun est obligatoire et comment les totaux doivent s'additionner. Tout format européen de facturation électronique en est une contrainte.

Elle existe grâce à la directive européenne 2014/55/UE, qui a obligé les acheteurs publics de l'Union à accepter les factures électroniques dans une norme commune. L'EN 16931-1:2026 a été publiée en mai 2026 et a formellement retiré l'édition 2017, avec une période de migration le temps que les profils suivent — un document qui valide contre un schematron de génération 2017 continuera donc de valider, et le changement concret arrivera quand chaque profil national se republiera sur la nouvelle édition.

La spécification technique complémentaire CEN/TS 16931-2 liste les syntaxes qui s'y conforment, et il y en a exactement deux : UBL 2.1 et UN/CEFACT CII. Tout le reste, en Europe, est un profil de l'une des deux.

Flowie expose le modèle directement : le référentiel des termes métier liste les 164 BT, ce à quoi chacun correspond en UBL et en CII, et ceux que la France exige en plus. Les échecs de validation reviennent en nommant le terme métier, pas l'étape de schematron — voir le catalogue d'erreurs.

UBL 2.1 — la syntaxe XML que parlent la plupart des réseaux

UBL (Universal Business Language) 2.1 est une norme OASIS qui définit des schémas XML pour toute la chaîne achats — commandes, avis d'expédition, factures, avoirs. Ses documents Invoice et CreditNote sont l'une des deux syntaxes conformes à l'EN 16931, et celle qu'a retenue le réseau Peppol.

Une facture UBL EN 16931 annonce son profil dans deux éléments en tête de document :

<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>

CustomizationID est le profil — le CIUS que le document prétend satisfaire. ProfileID est le processus métier auquel il appartient. Trompez-vous sur l'un ou l'autre et un point d'accès conforme rejettera le document avant qu'un humain ne le voie. Flowie écrit les deux pour vous quand vous envoyez format: "json", et les valide quand vous déposez votre propre XML.

UBL sert aussi de base à plusieurs formats nationaux antérieurs à la norme européenne ou qui l'étendent — OIOUBL (Danemark), ISDOC (Tchéquie), UBL-TR (Türkiye), ZATCA (Arabie saoudite) et MyInvois (Malaisie).

UN/CEFACT CII — l'autre syntaxe conforme

Le CII (Cross Industry Invoice) est la syntaxe XML d'UN/CEFACT, normalisée dans la publication de schémas D16B. Son élément racine est rsm:CrossIndustryInvoice, et il porte les mêmes termes métier EN 16931 que l'UBL dans un arbre différent : trois sections de premier niveau (ExchangedDocument, SupplyChainTradeTransaction et le contexte d'en-tête) au lieu de la structure plus plate d'UBL.

Le CII compte bien davantage que sa part de marché ne le laisse croire, parce que c'est le XML embarqué dans chaque PDF Factur-X et ZUGFeRD — ce qui en fait la syntaxe dominante en France et en Allemagne, les deux plus grands marchés de la facturation électronique d'Europe continentale.

Factur-X & ZUGFeRD — les formats PDF hybrides

Factur-X (France) et ZUGFeRD (Allemagne) sont la même norme publiée par deux organismes — le FNFE-MPE et le FeRD — sous deux noms. Une facture Factur-X est un fichier PDF/A-3 contenant une pièce jointe XML CII : un humain ouvre le PDF et lit une facture ; une machine ouvre le même fichier, en extrait factur-x.xml et la comptabilise. Un seul artefact, deux publics, aucun problème de rapprochement.

La norme définit une échelle de profils, de MINIMUM et BASIC WL (trop pauvres pour constituer à eux seuls une facture légale) à BASIC et EN 16931 (le socle pleinement conforme) jusqu'à EXTENDED (qui ajoute des termes au-delà de l'EN 16931). La réforme B2B française accepte Factur-X au profil EN 16931 et au-dessus.

Flowie traite le PDF comme l'original : déposez un Factur-X et le CII embarqué est extrait, mappé et validé, tandis que le PDF que vous avez envoyé reste l'artefact renvoyé comme document original — ce qu'exige l'AFNOR XP Z12-013 d'un émetteur français, et ce que demandera un auditeur. Voir la vue d'ensemble France et la page Allemagne pour les deux mandats.

Peppol BIS Billing 3.0 et PINT

Peppol BIS Billing 3.0 est un CIUS de l'EN 16931 exprimé en UBL 2.1, et c'est le profil de facturation électronique le plus largement déployé en Europe. C'est lui qui circule sur le modèle à quatre coins du réseau Peppol : vous envoyez à votre point d'accès, votre point d'accès délivre à celui du destinataire, et une consultation SMP résout de qui il s'agit. Flowie est un point d'accès, donc envoyer tient en un appel d'API.

PINT (Peppol International) est la généralisation mondiale, plus récente : un modèle de facturation commun que chaque juridiction spécialise au lieu de le forker. Des spécialisations PINT sont en service ou en approche en Australie et Nouvelle-Zélande (PINT A-NZ), au Japon (JP PINT), à Singapour (InvoiceNow), aux Émirats arabes unis (PINT AE, sur un modèle à cinq coins qui ajoute l'administration fiscale comme coin) — et dans l'UE, sous le nom de PINT EU, profil successeur de BIS Billing 3.0.

Formats nationaux européens et CIUS

La plupart des pays de l'UE utilisent Peppol BIS tel quel ou le restreignent par un CIUS national. Une poignée exploite des formats antérieurs à la norme européenne, toujours juridiquement exigés.

XRechnung (Allemagne)

Le CIUS allemand de l'EN 16931, maintenu par la KoSIT. Obligatoire pour les factures aux acheteurs publics fédéraux, et profil de référence du mandat B2B qui se déploie jusqu'en 2028. XRechnung peut être porté en UBL comme en CII, et ajoute des spécificités allemandes — routage par Leitweg-ID, coordonnées de contact acheteur obligatoires. Détails sur la page Allemagne.

FatturaPA (Italie)

Le schéma XML national italien, dédouané par le Sistema di Interscambio (SDI) pour toute facture B2B, B2C et B2G. Antérieur à l'EN 16931, il n'en est pas un CIUS : il a ses propres noms d'éléments, ses propres codes TipoDocumento (TD01–TD29) et ses propres messages de retour (esiti) qui arrivent de façon asynchrone après soumission. Flowie mappe le modèle canonique dessus et expose les esiti comme événements de cycle de vie — voir la vue d'ensemble Italie et l'explorateur TD.

Le reste, en bref

• Facturae (Espagne) — XML national avec signature XAdES obligatoire, utilisé pour le B2G via FACe pendant que le cadre B2B Crea y Crece se déploie. Espagne →
• KSeF FA(3) (Pologne) — le schéma de la plateforme nationale de clearance ; une facture n'a aucune existence légale tant que KSeF ne lui a pas attribué un numéro. Pologne →
• RO e-Factura (Roumanie) — un CIUS national de l'EN 16931 dédouané par l'ANAF. Roumanie →
• ISDOC (Tchéquie) — un standard national dérivé d'UBL, de 2009 ; les acheteurs publics l'acceptent, comme Peppol BIS. Tchéquie →
• OIOUBL (Danemark) — le profil UBL danois porté par NemHandel, encore vivant dans les ERP publics historiques. Danemark →
• EHF (Norvège) — aujourd'hui essentiellement du Peppol BIS avec des identifiants norvégiens. Norvège →
• Finvoice (Finlande) — un standard porté par les banques et délivré par les canaux bancaires, aux côtés de Peppol. Finlande →
• ebInterface (Autriche) — accepté sur le portail fédéral de facturation électronique à côté de Peppol BIS. Autriche →
• UBL.BE (Belgique) — le profil Peppol BIS belge, maintenant que le mandat B2B est en vigueur et que HERMES a été retiré. Belgique →

Formats de clearance et de reporting hors UE

Hors d'Europe, le modèle dominant est la clearance : la facture est soumise à l'administration fiscale et ne devient valide qu'une fois revenue tamponnée, numérotée ou signée. Le format est celui que dit le schéma de cette plateforme, et c'est rarement de l'EN 16931.

• Arabie saoudite — ZATCA / Fatoora : XML fondé sur UBL 2.1 avec tampon cryptographique, UUID et QR code ; les factures standard sont dédouanées avant émission, les simplifiées déclarées après. Arabie saoudite →
• Malaisie — MyInvois : UBL 2.1 en XML ou JSON, validé par la LHDN, qui renvoie un UUID et un QR code. Malaisie →
• Inde — facture GST : le schéma JSON INV-01 enregistré auprès d'un Invoice Registration Portal, qui renvoie l'IRN et un QR code signé. Inde →
• Égypte — ETA : documents JSON/XML soumis à l'administration fiscale pour une clearance quasi temps réel. Égypte →
• Türkiye — e-Fatura / e-Arşiv : UBL-TR, une customisation turque d'UBL 2.1, via le GİB. Türkiye →
• Israël — numéro d'allocation de l'ITA : pas de nouveau format de document ; au-dessus d'un seuil, les factures doivent obtenir un numéro d'allocation auprès de l'administration fiscale pour être déductibles. Israël →
• Chine — e-fapiao entièrement numérique : émise à l'intérieur de la plateforme Golden Tax IV de la STA plutôt qu'échangée entre partenaires commerciaux. Chine →

Le travail de Flowie est le même dans tous les cas : vous envoyez le JSON canonique, et le connecteur pays produit le schéma de la plateforme, le soumet et remonte le résultat sous forme d'événements de cycle de vie auxquels vous pouvez vous abonner. Ce qui change, c'est quand la facture devient juridiquement valide — d'où le fait que l'endpoint cycle de vie, et non la réponse d'envoi, est ce qu'il faut surveiller dans un pays à clearance.

L'EDI historique, et pourquoi un PDF n'est pas une facture électronique

UN/EDIFACT INVOIC et ANSI X12 810 sont les messages de facture EDI pré-XML, qui portent encore des volumes énormes dans la distribution, l'automobile et la logistique. Ils sont structurés et lisibles par une machine, donc ils résolvent le même problème — mais ce ne sont pas des syntaxes EN 16931, et un mandat qui nomme UBL ou CII ne les acceptera pas. Faire le pont est un projet de mapping ; parlez-nous-en si vous avez un socle EDI à conserver.

Une facture PDF, même envoyée par e-mail, n'est pas une facture électronique au sens des mandats actuels — pas plus qu'un scan ou un tableur. Le test qu'applique chaque réglementation est de savoir si la facture peut être traitée automatiquement sans ressaisie, ce qu'un PDF plat ne permet pas. C'est le malentendu le plus répandu des projets de facturation électronique, et la raison d'être de Factur-X : garder dans un seul fichier le PDF que voulait un humain et les données qu'exige la réglementation. Flowie stockera volontiers un PDF plat avec format: "raw" — simplement, il ne le routera pas comme une facture conforme.

Quel format envoyer ?

• Vous construisez une nouvelle intégration → envoyez format: "json". Vous décrivez la facture une fois ; Flowie produit la bonne syntaxe par destination et la reproduit quand un pays change de profil.
• Votre ERP émet déjà de l'UBL ou du CII → déposez-le avec ubl-xml / cii-xml. Vos octets restent l'original émis, ce qui compte pour l'audit.
• Votre ERP émet des PDF Factur-X ou ZUGFeRD → envoyez le PDF avec format: "auto". Le CII embarqué est extrait et validé ; le PDF reste l'original.
• Vous vendez en Allemagne → XRechnung pour les acheteurs publics, Factur-X/ZUGFeRD ou CII/UBL simple en B2B. Allemagne →
• Vous vendez en Italie, en Pologne, en Roumanie, en Espagne ou dans un pays à clearance du Golfe ou d'Asie → envoyez du JSON et laissez le connecteur pays produire le schéma national. Le format n'est pas vraiment votre choix là-bas ; le schéma de la plateforme est le contrat. Matrice de couverture →
• Vous ne savez pas ce qu'accepte le destinataire → POST /v1/directory/verify avant d'envoyer.

Questions fréquentes

Quelle est la différence entre UBL et CII ?

Ce sont deux syntaxes XML pour le même contenu sémantique. UBL 2.1 est une norme OASIS utilisée par Peppol et la plupart des réseaux d'Europe du Nord ; UN/CEFACT CII est utilisée en France et en Allemagne, et c'est le XML embarqué dans les PDF Factur-X et ZUGFeRD. Le CEN/TS 16931-2 reconnaît les deux comme conformes à l'EN 16931 : une facture passe donc de l'une à l'autre sans perte de contenu métier. L'élément racine les distingue : CrossIndustryInvoice pour le CII, Invoice ou CreditNote pour l'UBL.

Factur-X et ZUGFeRD, est-ce la même chose ?

Oui — techniquement la même norme hybride PDF/A-3, publiée conjointement par le FNFE-MPE en France et le FeRD en Allemagne sous deux noms. Un fichier ZUGFeRD est un fichier Factur-X valide, et réciproquement, au même niveau de profil. Les noms diffèrent pour des raisons de gouvernance et de marché, pas pour des raisons techniques.

XRechnung est-il un format Peppol ?

Non. XRechnung est un CIUS allemand de l'EN 16931 ; Peppol BIS Billing 3.0 est le CIUS d'OpenPeppol de la même norme. Les documents XRechnung transitent souvent par le réseau Peppol, d'où la confusion fréquente, mais ce sont deux profils distincts avec des champs obligatoires différents — notamment le Leitweg-ID allemand.

Une facture PDF est-elle une facture électronique ?

Non. Au sens de la directive européenne 2014/55/UE et des mandats nationaux qui en découlent, une facture électronique doit être émise, transmise et reçue dans un format structuré permettant un traitement automatique. Un PDF — ou un scan, ou une image envoyée par e-mail — ne qualifie pas, quelle que soit sa fabrication. Un PDF hybride Factur-X/ZUGFeRD, si : le XML structuré voyage à l'intérieur.

Dois-je convertir mes factures moi-même ?

Non. Envoyez le modèle JSON canonique à POST /v1/documents/send et Flowie produit ce que la destination exige. La conversion ne devient votre problème que si vous tenez à déposer un XML déjà produit pour un pays dont vous n'avez pas implémenté le profil.

L'EN 16931-1:2026 casse-t-elle mon intégration ?

Pas en elle-même. L'édition 2026 a été publiée en mai 2026 et a formellement retiré l'édition 2017, mais les profils nationaux l'adoptent à leur propre rythme et la validation continue d'accepter les versions de profil en vigueur pendant la migration. Tout changement effectif est annoncé dans le changelog avant de vous atteindre.

Quels formats Flowie gère-t-il ?

En entrée : le modèle JSON canonique, l'UBL 2.1, l'UN/CEFACT CII et les PDF Factur-X/ZUGFeRD (plus n'importe quel fichier stocké tel quel avec format: "raw"). En sortie : Peppol BIS Billing 3.0 et PINT pour le réseau Peppol, et le format national exigé par chacune des 47 juridictions documentées dans la section conformité — Factur-X et CII pour la France, XRechnung et ZUGFeRD pour l'Allemagne, FatturaPA pour l'Italie, KSeF FA(3) pour la Pologne, Facturae pour l'Espagne, ZATCA pour l'Arabie saoudite, MyInvois pour la Malaisie, et le reste du catalogue ci-dessus.

Références officielles

Les sources primaires, dans l'ordre où les couches s'empilent. Si un profil national et cette page divergent, le profil national l'emporte — dites-le-nous et nous corrigerons la page.

• Commission européenne — conformité à la norme eInvoicing (EN 16931, et comment en obtenir une copie)
• OASIS — Universal Business Language 2.1
• UNECE — schémas XML UN/CEFACT (Cross Industry Invoice)
• OpenPeppol — BIS Billing 3.0 · PINT Billing · PINT EU · Peppol eDelivery (AS4)
• FNFE-MPE — Factur-X · FeRD — ZUGFeRD
• KoSIT — XRechnung
• Agenzia delle Entrate — FatturaPA
• DGFiP — spécifications externes B2B (France)
• Ministerstwo Finansów — KSeF · Facturae · ISDOC · OIOUBL · Finvoice · ebInterface · UBL.BE
• ZATCA · SDK MyInvois · Facture GST Inde · Egyptian Tax Authority · GİB e-Fatura

Et sur ce site : l'endpoint d'envoi, le modèle document canonique, les types de documents & de factures, 47 guides pays, et les 164 termes métier EN 16931.