Les bases de la facturation électronique

Dernière révision le 26 septembre 2026.

Une facture électronique structurée contient des données que les logiciels peuvent lire directement. Il peut s'agir d'un fichier XML ou, avec des formats comme Factur-X / ZUGFeRD, d'un XML intégré dans un PDF lisible. Ce guide présente les éléments en jeu, la façon dont ils s'articulent et ce qu'un validateur peut vous dire ou non. Il s'adresse aux développeurs et aux équipes financières qui découvrent la facturation électronique.

Trois idées en portent l'essentiel :

• Un format définit la façon dont les données sont écrites, par exemple UBL ou CII.
• Une norme définit ce qu'elles signifient : la norme EN 16931 fixe ce qu'une facture européenne doit dire.
• Des règles supplémentaires s'appliquent dans des contextes particuliers : le réseau Peppol, les factures adressées aux organismes publics allemands ou un profil Factur-X / ZUGFeRD.

Les trois formats en bref

La suite de ce guide explique ce qui se cache derrière chaque colonne, puis les identifiants et les versions exacts.

Ce qui rend une facture structurée

Un PDF ou une image numérisée ressemble à une facture pour une personne, mais un programme doit deviner où se trouvent le numéro de facture, les totaux et la TVA. Une facture structurée indique chaque valeur dans un élément nommé : le numéro de facture dans un élément, chaque ligne avec sa quantité, son prix et son montant net, la ventilation de la TVA, les totaux, ainsi que le vendeur et l'acheteur avec des identifiants tels que les numéros de TVA.

Comme la structure et sa signification sont convenues à l'avance, le destinataire peut charger la facture directement, la vérifier et la rapprocher d'une commande.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
    xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
    xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
    <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>
    <cbc:ID>EX-2026-0001</cbc:ID>
    <cbc:IssueDate>2026-06-15</cbc:IssueDate>
    <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
    <cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
    <!-- the supplier, the customer, the invoice lines and the VAT breakdown -->
    <cac:LegalMonetaryTotal>
        <cbc:LineExtensionAmount currencyID="GBP">740.00</cbc:LineExtensionAmount>
        <cbc:TaxExclusiveAmount currencyID="GBP">740.00</cbc:TaxExclusiveAmount>
        <cbc:TaxInclusiveAmount currencyID="GBP">888.00</cbc:TaxInclusiveAmount>
        <cbc:PayableAmount currencyID="GBP">888.00</cbc:PayableAmount>
    </cac:LegalMonetaryTotal>

Syntaxe, sémantique et règles d'utilisation

Trois couches répondent à trois questions différentes sur une facture électronique.

Syntaxe : comment est-elle écrite ?

La syntaxe est le vocabulaire XML : les noms des éléments, leur ordre et leurs types de données. Deux syntaxes comptent en Europe : UBL 2.1 (Universal Business Language) et la Cross Industry Invoice (CII) de l'UN/CEFACT. Une vérification de schéma (XSD) vous indique si un document est bien formé dans sa syntaxe, et non s'il s'agit d'une facture complète.

Modèle sémantique : que doit-elle dire ?

La norme EN 16931, norme européenne de facturation électronique, définit le modèle de base de la facture : les informations qu'une facture porte et les règles qui les relient. Chaque information est un terme métier doté d'un identifiant, comme BT-1 pour le numéro de facture et BT-106 pour la somme des montants nets des lignes ; les termes liés forment des groupes (BG-). Des règles métier (BR-) doivent être respectées entre eux : BR-CO-10, par exemple, exige que BT-106 soit égal à la somme des montants nets des lignes de la facture. EN 16931 ne définit pas de syntaxe propre ; ses spécifications techniques lient le modèle à UBL 2.1 et à CII D16B.

Règles d'utilisation : comment cette communauté l'utilise-t-elle ?

Une spécification d'utilisation de la facture de base (CIUS) adapte le modèle de base à un contexte particulier. Elle peut rendre obligatoires des informations facultatives, restreindre des listes de codes et ajouter des règles, mais elle doit rester un sous-ensemble du modèle de base et ne doit enfreindre aucune de ses règles. Une extension va dans l'autre sens et ajoute des informations que le modèle de base ne définit pas.

• Peppol BIS Billing 3 est une CIUS de la norme EN 16931, définie par OpenPeppol et écrite en UBL.
• XRechnung, la norme allemande de facturation des acheteurs publics, se compose de la CIUS XRechnung et de l'Extension XRechnung.
• Factur-X / ZUGFeRD définit des profils : le profil EN 16931 suit le modèle de base, MINIMUM et BASIC WL portent moins qu'une facture EN 16931 complète, et EXTENDED en porte davantage.

Un validateur parcourt ces couches dans l'ordre : le fichier est-il un XML bien formé, respecte-t-il le schéma de sa syntaxe, les règles EN 16931 sont-elles respectées, et les règles d'utilisation le sont-elles ? Ironfang rend compte de chaque étape séparément : un document non valide se distingue ainsi d'une défaillance du service, et vous voyez où un problème commence.

Syntaxes, identifiants et versions

UBL et CII peuvent porter les mêmes informations EN 16931 sous des noms d'éléments différents. Le numéro de facture, par exemple, est cbc:ID en tête d'une facture UBL et ram:ID dans rsm:ExchangedDocument en CII. Chaque document déclare aussi les règles qu'il suit, dans son identifiant de spécification : cbc:CustomizationID en UBL, ou le ram:ID de ram:GuidelineSpecifiedDocumentContextParameter en CII. Les validateurs s'appuient sur cette déclaration pour choisir les règles à appliquer.

Factur-X et ZUGFeRD sont une même norme sous deux noms : Factur-X 1.09.2 correspond à ZUGFeRD 2.5.2. Une facture hybride est un fichier PDF/A, une page lisible dans laquelle le XML de la facture est intégré : un seul fichier sert ainsi à la fois à la personne et au programme.

Ironfang Finance valide ces versions, et chaque résultat indique la version exacte selon laquelle le document a été vérifié :

• Peppol BIS Billing 3.0, version de mai 2026, pour les factures et les avoirs UBL.
• XRechnung 3.0.2, dans le paquet technique de la KoSIT du 31 août 2026, en UBL et en CII.
• Factur-X 1.09.2 / ZUGFeRD 2.5.2 dans les profils MINIMUM, BASIC WL, BASIC, EN 16931 et EXTENDED, en PDF ou en XML. Le profil XRECHNUNG à l'intérieur d'un PDF ZUGFeRD est reconnu et signalé comme non encore pris en charge, jamais vérifié comme autre chose.

Les guides des formats vont plus loin : XRechnung et Factur-X / ZUGFeRD.

Ce que la validation établit

Un résultat réussi signifie que le document, tel qu'il a été envoyé, respectait, au moment de la vérification, chaque règle que le validateur a vérifiée pour une version nommée de sa spécification. Les erreurs font échouer un document ; les avertissements méritent d'être lus, mais ne le font pas échouer.

Il n'établit pas que :

• la facture a été envoyée, remise, reçue ou acceptée par l'acheteur ;
• le contenu est commercialement exact : un validateur peut vérifier que les totaux concordent, pas que vous avez facturé le bon prix ;
• les exigences propres de l'acheteur, au-delà des règles publiées, sont respectées ;
• la facture remplit toutes les obligations légales ou fiscales qui vous concernent.

Certaines choses échappent à ce qu'une vérification XML peut voir. Pour un PDF Factur-X / ZUGFeRD, par exemple, Ironfang indique qu'il n'a pas comparé la page PDF visible au XML intégré : seul le XML constitue les données de facture qui ont été vérifiées.

Le réseau Peppol est une autre affaire

"Peppol" désigne deux choses. Peppol BIS Billing 3 est la spécification de document décrite plus haut. Le réseau Peppol est le moyen par lequel les documents circulent : les organisations y envoient et y reçoivent des documents commerciaux par l'intermédiaire d'un prestataire de services accrédité Peppol de leur choix, et chaque partie n'a besoin que d'un prestataire pour joindre tous les autres participants du réseau.

Valider une facture Peppol BIS vérifie le document ; cela ne l'envoie pas. Ironfang valide des documents. Ironfang n'envoie pas de factures, n'exploite pas de point d'accès Peppol (Access Point) et n'inscrit pas de participants sur le réseau.

Essayer : vérifier un exemple et corriger une erreur

En quelques minutes, passez d'une facture erronée à une facture corrigée, sans compte :

1. Ouvrez le validateur Peppol et choisissez l'exemple avec erreurs. Le résultat signale deux erreurs EN 16931 sur les totaux de la facture, BR-CO-10 et BR-CO-13.
2. Lisez l'explication de BR-CO-10 : la somme déclarée des montants des lignes doit être égale à la somme des lignes. Dans cet exemple, les lignes totalisent 740.00, mais le total déclare 750.00.
3. Comparez-le avec l'exemple valide annoté, où cbc:LineExtensionAmount dans les totaux vaut 740.00. Corrigez le montant déclaré et validez à nouveau le fichier.
4. Ouvrez le même fichier dans la visionneuse de factures pour lire la facture UBL comme un document.

La même démarche fonctionne pour les autres familles. Le validateur XRechnung propose un exemple CII sans référence acheteur (le Leitweg-ID), que XRechnung exige : il signale donc BR-DE-15. Le validateur Factur-X / ZUGFeRD propose un PDF d'exemple comportant deux erreurs, l'une dans ses métadonnées PDF, l'autre dans son XML. Lorsqu'un constat cite une règle, la référence des règles explique ce qu'elle vérifie et comment corriger le problème.

L'intégrer à un logiciel

• Valider depuis votre code : un démarrage rapide exécutable qui envoie une facture d'exemple à la Finance API et lit le résultat.
• Finance API V1 et V2 : quelle version de l'API couvre quel format, et en quoi les résultats diffèrent.
• Génération de factures : produire une facture Peppol BIS en UBL à partir de JSON.
• Comment fonctionne réellement la validation des factures Peppol (en anglais) et Comprendre les erreurs de validation EN 16931 (en anglais) : les étapes de validation et les familles de règles plus en détail.

Explorez l'espace d'apprentissage de la facturation électronique pour d'autres guides, outils et exemples, classés par tâche.

Sources

Les affirmations sur les normes figurant sur cette page ont été vérifiées le 26 septembre 2026 auprès de ces sources primaires :

• Commission européenne : "Required syntaxes": La norme EN 16931 définit le contenu, pas la syntaxe ; UBL 2.1 et UN/CEFACT CII D16B sont les deux syntaxes qui lui sont liées.
• Commission européenne : "EN 16931 compliance": Ce qu'une facture conforme doit contenir, et le fait qu'une CIUS est un sous-ensemble du modèle de base qui n'enfreint pas ses règles.
• OpenPeppol : Peppol BIS Billing 3.0: Peppol BIS Billing 3.0 est une CIUS de la norme EN 16931 en UBL, avec ses identifiants de spécification et de processus métier.
• OpenPeppol : "For end users": Les organisations envoient et reçoivent sur le réseau Peppol par l'intermédiaire d'un prestataire de services accrédité Peppol de leur choix.
• KoSIT (xeinkauf.de) : XRechnung: XRechnung se compose de la CIUS XRechnung et de l'Extension XRechnung, gérées par la KoSIT pour le IT-Planungsrat, en UBL 2.1 et en UN/CEFACT CII.
• FeRD : ZUGFeRD / Factur-X: ZUGFeRD intègre des données de facture XML structurées dans un document PDF/A-3 et correspond en France, avec la FNFE-MPE, à Factur-X.
• FeRD : ZUGFeRD 2.5.2: ZUGFeRD 2.5.2 correspond à Factur-X 1.09.2 et repose sur UN/CEFACT CII D22B.
• FNFE-MPE : Factur-X: Factur-X est la même norme que ZUGFeRD, une facture hybride PDF et XML, avec les profils MINIMUM, BASIC WL, BASIC, EN16931 et EXTENDED.

Les versions validées par Ironfang proviennent de son propre registre de jeux de règles, que chaque résultat cite. Ce guide explique les normes ; il ne constitue pas un conseil juridique ou fiscal.