ediverse

Tapez pour rechercher dans les standards, messages, outils et glossaire.

ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

— 01

Fondamentaux

— 02

Standards

— 03

Messages phares

— 04

Outils
Factur-X — facture hybride PDF + XML CII franco-allemande

Factur-X / ZUGFeRD

La facture hybride franco-allemande : un PDF/A-3 lisible par l'humain qui transporte, en pièce jointe, un XML CII conforme à la norme européenne EN 16931. Un format, deux noms, un même fichier en France et en Allemagne.

Pourquoi une facture hybride ?

Le débat sur la facturation électronique s'est longtemps polarisé entre deux camps : les tenants du tout-PDF (lisible par l'humain mais opaque à la machine), et ceux du tout-XML (parfait pour les ERP, illisible sans feuille de style). Factur-X / ZUGFeRD résout la tension en empilant les deux dans un seul fichier : un PDF/A-3 dont le rendu visuel est la facture, et qui contient en pièce jointe un fichier XML conforme à EN 16931.

Cette approche permet à une PME :

  • de continuer à imprimer ou à archiver une facture regardable à l'œil ;
  • de transmettre ce même fichier à un client qui automatise la saisie comptable ;
  • de répondre à l'obligation française de e-invoicing B2B sans pour autant adopter une plateforme EDI lourde, le PDF/A-3 restant le contenant familier.

Le caractère hybride est volontairement réversible : un lecteur qui ne sait lire que le PDF affiche la facture comme d'habitude ; un système comptable moderne consomme le XML en pièce jointe sans regarder le rendu.

Architecture d'un fichier

Techniquement, Factur-X / ZUGFeRD est un PDF/A-3 — variante du standard PDF/A (ISO 19005-3) qui autorise les pièces jointes. Une facture Factur-X se compose donc de deux objets superposés :

  1. Le flux PDF traditionnel : en-têtes, lignes de facture, totaux, mentions légales, signature visuelle. C'est ce que voit le destinataire humain.
  2. Le fichier XML embarqué portant le nom factur-x.xml (ou zugferd-invoice.xml dans les premières versions ZUGFeRD). Ce XML est conforme à la syntaxe UN/CEFACT CII (Cross Industry Invoice) et porte strictement les mêmes informations que le PDF visuel.

Une cinquième entité de contexte dans les métadonnées XMP du PDF signale la présence du XML, son profil et son nom de fichier : c'est par ce mécanisme que le destinataire détecte le caractère hybride sans ouvrir le PDF.

Les profils Factur-X / ZUGFeRD

Le standard publie cinq profils, du plus simple au plus complet. Tous partagent la même enveloppe PDF/A-3 et la même syntaxe CII : ils diffèrent par le nombre d'éléments métier obligatoires.

ProfilCouvertureUsage typique
MINIMUMDonnées minimales (émetteur, destinataire, total TTC, numéro et date)Niveau Chorus Pro — réception côté administration française.
BASIC WLEn-tête et pied complets, mais sans lignes (Without Lines)Facture forfaitaire ou simple à un client B2B.
BASICBASIC WL + détail des lignesFacture PME-PME complète.
EN 16931Toutes les données définies par la norme européenne (anciennement appelé profil COMFORT)Profil de référence pour l'interopérabilité PEPPOL.
EXTENDEDEN 16931 + extensions sectorielles (logistique, transport, transactions B2B complexes)Industrie, automobile, transport — profil encore en évolution.

Pour Chorus Pro, le profil minimum acceptable est MINIMUM. Pour la facturation B2B française post-2026, BASIC ou EN 16931 sont les plus pertinents. Le profil XRECHNUNG que l'on voit parfois cité côté allemand est en pratique un alignement EN 16931 + règles allemandes — il peut être porté soit dans un Factur-X EN 16931, soit dans un UBL XRechnung pur (sans PDF).

Anatomie d'un XML CII

Le XML embarqué utilise la syntaxe Cross Industry Invoice (CII) de l'UN/CEFACT. Son organisation diffère d'UBL mais couvre la même sémantique. La racine est <rsm:CrossIndustryInvoice> avec quatre blocs principaux : contexte d'échange, document, transaction commerciale et lignes.

xml factur-x.xml 
<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossIndustryInvoice
    xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
    xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
    xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">

  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>

  <rsm:ExchangedDocument>
    <ram:ID>FX-2026-04127</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20260514</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>

  <rsm:SupplyChainTradeTransaction>
    <ram:IncludedSupplyChainTradeLineItem>
      <ram:AssociatedDocumentLineDocument>
        <ram:LineID>1</ram:LineID>
      </ram:AssociatedDocumentLineDocument>
      <ram:SpecifiedTradeProduct>
        <ram:Name>Conseil — atelier processus EDI</ram:Name>
      </ram:SpecifiedTradeProduct>
      <ram:SpecifiedLineTradeAgreement>
        <ram:NetPriceProductTradePrice>
          <ram:ChargeAmount>900.00</ram:ChargeAmount>
        </ram:NetPriceProductTradePrice>
      </ram:SpecifiedLineTradeAgreement>
      <ram:SpecifiedLineTradeDelivery>
        <ram:BilledQuantity unitCode="HUR">2</ram:BilledQuantity>
      </ram:SpecifiedLineTradeDelivery>
      <ram:SpecifiedLineTradeSettlement>
        <ram:SpecifiedTradeSettlementLineMonetarySummation>
          <ram:LineTotalAmount>1800.00</ram:LineTotalAmount>
        </ram:SpecifiedTradeSettlementLineMonetarySummation>
      </ram:SpecifiedLineTradeSettlement>
    </ram:IncludedSupplyChainTradeLineItem>

    <ram:ApplicableHeaderTradeAgreement>
      <ram:SellerTradeParty>
        <ram:Name>Atelier Numérique SARL</ram:Name>
        <ram:SpecifiedLegalOrganization>
          <ram:ID schemeID="0002">80214579500024</ram:ID>
        </ram:SpecifiedLegalOrganization>
      </ram:SellerTradeParty>
      <ram:BuyerTradeParty>
        <ram:Name>Coopérative Solaire SCIC</ram:Name>
        <ram:SpecifiedLegalOrganization>
          <ram:ID schemeID="0002">88410230400015</ram:ID>
        </ram:SpecifiedLegalOrganization>
      </ram:BuyerTradeParty>
    </ram:ApplicableHeaderTradeAgreement>

    <ram:ApplicableHeaderTradeSettlement>
      <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
      <ram:SpecifiedTradeSettlementHeaderMonetarySummation>
        <ram:TaxBasisTotalAmount>1800.00</ram:TaxBasisTotalAmount>
        <ram:TaxTotalAmount currencyID="EUR">360.00</ram:TaxTotalAmount>
        <ram:GrandTotalAmount>2160.00</ram:GrandTotalAmount>
      </ram:SpecifiedTradeSettlementHeaderMonetarySummation>
    </ram:ApplicableHeaderTradeSettlement>
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Points de lecture utiles :

  • Le GuidelineSpecifiedDocumentContextParameter identifie le profil — ici urn:factur-x.eu:1p0:en16931 = profil EN 16931.
  • TypeCode 380 = facture commerciale (codification UN/CEFACT 1001) ; 381 serait un avoir.
  • Les identifiants entreprise utilisent le couple schemeID + valeur : 0002 = SIRET français. Côté allemand, on utilise 0204 pour le Leitweg-ID, ou des USt-IdNr (numéro de TVA intracom).
  • Toutes les sommes sont portées par le bloc SpecifiedTradeSettlementHeaderMonetarySummation, qui calcule base HT, montant total de TVA, et grand total TTC selon les règles BR-CO-X d'EN 16931.

Réforme française 2026-2027

La France met en œuvre une réforme majeure de la facturation électronique B2B, successive à l'obligation Chorus Pro déjà en vigueur pour le B2G. Le calendrier officiel publié par la DGFiP en 2025-2026 prévoit :

DateObligation
1er septembre 2026Obligation de réception de factures électroniques B2B pour toutes les entreprises françaises, et obligation d'émission pour les grandes entreprises et ETI.
1er septembre 2027Obligation d'émission étendue aux PME et microentreprises.

Le calendrier est susceptible de glisser : la version définitive en vigueur le 14 mai 2026 doit être recroisée avec impots.gouv.fr et avec les communications les plus récentes de la DGFiP. Les formats acceptés par la Portail Public de Facturation (PPF) seront principalement : Factur-X (CII embarqué dans PDF/A-3), UBL Invoice, et CII pur.

XRechnung et Leitweg-ID en Allemagne

Côté allemand, l'obligation de e-invoicing B2G est déjà en vigueur depuis 2020 (loi E-RechV). Depuis le 1er janvier 2025, toute entreprise allemande doit aussi pouvoir recevoir une facture électronique B2B ; l'émission devient progressive en 2026-2028 selon la taille de l'entreprise.

Deux formats coexistent :

  • XRechnung — XML pur (UBL ou CII) conforme EN 16931 plus règles allemandes (BR-DE-XX). Imposé pour les marchés publics fédéraux et acceptable en B2B.
  • ZUGFeRD profil EN 16931 ou XRECHNUNG — facture hybride PDF/A-3 avec XML CII compatible XRechnung. C'est la solution la plus diffusée côté PME, car elle conserve une représentation visuelle.

Une particularité allemande : l'identifiant Leitweg-ID, qui route la facture vers l'autorité publique destinataire dans le portail ZRE / OZG-RE. Il est transporté dans l'élément CII BuyerReference ou son équivalent UBL BuyerReference.

Outils

  • Validateur Factur-X / ZUGFeRD — prévu pour la version 1.2 d'ediverse, validation PDF/A-3 + XML CII contre les profils Factur-X officiels. Lien à venir : /tools/facturx-validator/.
  • Outils FNFE-MPE — la fédération propose une bibliothèque de validation Java open source, ainsi qu'un visualisateur de XMP / XML embarqué pour vérifier la conformité d'un fichier émis.
  • Validateur officiel Mustangproject — projet open source allemand (mustangproject.org) qui sait lire, écrire et valider Factur-X / ZUGFeRD aux profils MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED.

Pour aller plus loin