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.

ZUGFeRD — le format hybride allemand de référence

ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) est le format hybride PDF/A-3 + XML CII embarqué porté par le Forum elektronische Rechnung Deutschland (FeRD) depuis 2014. Co-publié avec FNFE-MPE comme Factur-X, c'est un des deux formats canoniques du B2B allemand au 1ᵉʳ janvier 2025.

Historique 2014 → 2024

ZUGFeRD est plus ancien que le mandat européen EN 16931. Sa trajectoire illustre la convergence progressive du format hybride allemand vers le standard européen :

  • 2008-2010 — Création de FeRD. Le Forum elektronische Rechnung Deutschland est créé en 2010 sous l'égide de l'AWV (Arbeitsgemeinschaft für wirtschaftliche Verwaltung), avec mandat du BMF de proposer un format pivot facture pour l'économie allemande.
  • 25 juin 2014 — ZUGFeRD 1.0. Première version stable, structure PDF/A-3 + XML CII basée sur UN/CEFACT 2009. Trois profils BASIC / COMFORT / EXTENDED.
  • 15 mars 2019 — ZUGFeRD 2.0. Refonte majeure : alignement avec EN 16931, co-publication avec FNFE-MPE comme Factur-X (les deux formats sont désormais structurellement identiques, seul le nom diffère par convention nationale). Ajout du profil MINIMUM (pour Chorus Pro B2G uniquement).
  • 22 mars 2021 — ZUGFeRD 2.2. Profil COMFORT renommé "EN 16931" pour coller au vocabulaire de la norme. Profil BASIC WL (Without Lines) ajouté pour besoins archivage.
  • 14 juin 2022 — ZUGFeRD 2.3. Refinements compatibilité Factur-X 1.07. Premier vrai upload sur OASIS DocStore.
  • 17 mai 2024 — ZUGFeRD 2.3.2. Version courante. Quelques correctifs Schematron, intégration des règles BR-DE-* compatibles XRechnung 3.0, mise à jour Factur-X 1.07.2.

Les 5 profils

Le profil détermine la granularité des données structurées portées par le XML embarqué et donc la validité légale du document selon le contexte (B2G fédéral, B2B Wachstumschancengesetz, archivage).

text zugferd-profils-2.3.2.txt
┌──────────────┬────────────┬─────────────┬─────────────────────────────────────┐
│ Profil       │ Lines      │ EN 16931    │ Usage typique                       │
├──────────────┼────────────┼─────────────┼─────────────────────────────────────┤
│ MINIMUM      │ Non        │ Non         │ Données comptables uniquement       │
│              │            │             │ (totaux HT/TVA/TTC). Pas valide     │
│              │            │             │ pour B2B post-2025 UStG.            │
├──────────────┼────────────┼─────────────┼─────────────────────────────────────┤
│ BASIC WL     │ Non        │ Non         │ Without Lines: conservation pure,   │
│              │            │             │ pas valide en B2B.                  │
├──────────────┼────────────┼─────────────┼─────────────────────────────────────┤
│ BASIC        │ Oui        │ Oui         │ TPE / PME : facture minimale avec   │
│              │ (résumées) │ (subset)    │ lignes, valide B2B 2025+.           │
├──────────────┼────────────┼─────────────┼─────────────────────────────────────┤
│ EN 16931     │ Oui        │ Oui         │ Profil de référence — alignement    │
│ (COMFORT*)   │            │             │ complet sur la norme européenne.    │
├──────────────┼────────────┼─────────────┼─────────────────────────────────────┤
│ EXTENDED     │ Oui        │ Oui +       │ Industrie, transport, BTP — champs  │
│              │            │ extensions  │ avancés (numéros de série, lots,    │
│              │            │             │ références logistiques).            │
└──────────────┴────────────┴─────────────┴─────────────────────────────────────┘
* "COMFORT" est l'ancien nom du profil EN 16931 (jusqu'à ZUGFeRD 2.2.0).

PDF/A-3 et règles d'embarquement

Le container ZUGFeRD est strictement un PDF/A-3 (ISO 19005-3:2012 — Document Management Application: Use of ISO 32000-1 with support for Embedded Files) qui autorise l'attachement de fichiers arbitraires au PDF. Trois règles d'embarquement sont imposées par la spécification ZUGFeRD :

  • Nom de fichier obligatoire : factur-x.xml (lowercase, identique à Factur-X). Aucun autre nom n'est accepté par les validateurs FeRD/FNFE-MPE.
  • Relationship attribute : l'AFRelationship doit valoir Alternative (anciennement Data dans ZUGFeRD 1.x — déprécié).
  • MIME type : application/xml dans la EmbeddedFile dictionary du PDF.
  • Metadata XMP : le PDF doit contenir un namespace XMP fx: déclarant le profil ZUGFeRD utilisé (par ex. fx:ConformanceLevel = "EN 16931").

Un PDF qui embarque un XML mais ne respecte pas ces règles n'est PAS un ZUGFeRD au sens de la spec. C'est un piège fréquent quand on génère le PDF avec une bibliothèque arbitraire (jsPDF, PDFKit) sans wrapper Factur-X dédié.

XML CII embarqué

Le XML factur-x.xml embarqué dans ZUGFeRD est du UN/CEFACT Cross Industry Invoice (CII) D16B, namespace racine urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100. C'est la syntaxe alternative à UBL listée par l'annexe B de EN 16931.

xml zugferd-2.3.2-cii-extrait.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</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>RE-2026-DE-0142</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20260519</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <rsm:SupplyChainTradeTransaction>
    <ram:IncludedSupplyChainTradeLineItem>
      <ram:AssociatedDocumentLineDocument>
        <ram:LineID>1</ram:LineID>
      </ram:AssociatedDocumentLineDocument>
      <ram:SpecifiedTradeProduct>
        <ram:Name>Beratung — Architecture EDI</ram:Name>
      </ram:SpecifiedTradeProduct>
      <ram:SpecifiedLineTradeAgreement>
        <ram:NetPriceProductTradePrice>
          <ram:ChargeAmount>1200.00</ram:ChargeAmount>
        </ram:NetPriceProductTradePrice>
      </ram:SpecifiedLineTradeAgreement>
    </ram:IncludedSupplyChainTradeLineItem>
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Trois sections racines structurent le document CII :

  • ExchangedDocumentContext : métadonnées du document — profil ZUGFeRD utilisé via GuidelineSpecifiedDocumentContextParameter.
  • ExchangedDocument : en-tête facture — ID, date, type, notes libres.
  • SupplyChainTradeTransaction : corps facture — lignes, accords commerciaux, livraisons, paiements, taxes, totaux.

ZUGFeRD vs Factur-X

Pour la communauté technique, il est important de comprendre que ZUGFeRD et Factur-X désignent le même artefact technique avec deux gouvernances coordonnées :

AspectZUGFeRDFactur-X
MainteneurFeRD (Allemagne)FNFE-MPE (France)
Structure XMLUN/CEFACT CII D16BUN/CEFACT CII D16B (identique)
ContainerPDF/A-3PDF/A-3 (identique)
Profils5 (MIN / BASIC WL / BASIC / EN 16931 / EXTENDED)5 identiques
Nom du fichier embarquéfactur-x.xmlfactur-x.xml
Référence légale§14 UStG (Allemagne)Arrêté 7 octobre 2022 (France)
SchematronFeRD rulesetFNFE-MPE Schematron + CIUS FR
Validateur officielwww.ferd-net.de/validatorservices.fnfe-mpe.org

Validité B2B post-Wachstumschancengesetz

Pour qu'un ZUGFeRD soit reconnu comme E-Rechnung valide au sens du §14 UStG modifié (à compter du 1ᵉʳ janvier 2025), trois conditions cumulatives :

  1. Version ZUGFeRD ≥ 2.0.1 (premier alignement EN 16931). Le BMF schreiben du 15 octobre 2024 recommande la version 2.1.1 ou supérieure pour les nouveaux déploiements.
  2. Profil EN 16931 ou EXTENDED. Les profils MINIMUM et BASIC WL ne contiennent pas de lignes détaillées et sont donc invalides en B2B. Le profil BASIC est à la limite — il porte des lignes mais sans détails fiscaux complets, généralement accepté mais à éviter pour les transactions complexes.
  3. XML factur-x.xml bien embarqué avec relationship Alternative et metadata XMP fx: correctes.

Liens transverses