Factur-X 1.08 / ZUGFeRD 2.4 : nouveautés et migration pour développeurs

Factur-X 1.08 est la version applicable depuis le 15 janvier 2026. C’est celle qui sera utilisée dans le cadre de la réforme de facturation électronique française. Côté allemand, elle correspond à ZUGFeRD 2.4 — les deux identifiants désignent le même standard technique. Si vous développez un logiciel qui génère, valide ou consomme des factures Factur-X, cet article résume ce qui change concrètement dans votre code et vos pipelines.

Pour le contexte complet de la réforme et son calendrier, voir Facturation électronique 2026 : le guide technique complet pour développeurs.

Contexte : versions et timeline

Le standard Factur-X a connu plusieurs versions depuis sa création. Côté français (FNFE-MPE) et côté allemand (FeRD), les versions ont convergé progressivement.

À partir de ZUGFeRD 2.1 / Factur-X 1.0 (2020), les standards sont techniquement alignés, avec des différences principalement dans les conventions de nommage, le packaging et les références de profil selon les contextes d’usage. En pratique, le nom du fichier embarqué dans le PDF diffère (factur-x.xml pour Factur-X, zugferd-invoice.xml pour ZUGFeRD) ainsi que les métadonnées XMP associées. Le schéma XML CII, les profils et les URN GuidelineID sont partagés.

Les deux standards sont co-maintenus par la FNFE-MPE (Forum National de la Facture Electronique et des Marchés Publics Electroniques, France) et le FeRD (Forum elektronische Rechnung Deutschland, Allemagne). Les spécifications sont publiées conjointement.

Le changement principal : CII D16B vers D22B

C’est le changement le plus significatif de la version 1.08. Toutes les versions précédentes de Factur-X (1.0 à 1.07) reposaient sur le binding CII D16B — celui défini par la liaison CEN officielle EN16931-3-5. Factur-X 1.08 passe à CII D22B.

Ce que D22B signifie

D16B et D22B sont des versions du schéma UN/CEFACT Cross-Industry Invoice. Le numéro correspond à un millésime de publication des données de référence UN/CEFACT (D16B = 2016 batch B, D22B = 2022 batch B). Chaque version étend le schéma en ajoutant des éléments et des types, sans supprimer ceux existants.

Le point crucial : D22B est une extension rétrocompatible de D16B. Tout document XML CII valide en D16B reste valide en D22B. L’inverse n’est pas vrai — un XML qui utilise des éléments ajoutés en D22B ne passera pas la validation contre le XSD D16B.

Ce qui change dans vos fichiers

Le schéma XSD de référence passe de CrossIndustryInvoice_100pD16B.xsd à CrossIndustryInvoice_100pD22B.xsd. Les namespaces XML restent identiques :

<!-- Les namespaces ne changent PAS -->
<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">

Les namespaces rsm:, ram: et udt: n’ont pas changé. C’est le contenu du schéma (les éléments et types disponibles) qui a évolué, pas les identifiants de namespace.

Rétrocompatibilité en pratique

Si votre code génère du XML CII conforme à D16B, ce XML reste valide contre le XSD D22B sans aucune modification. La migration de D16B vers D22B est transparente pour les documents existants.

En revanche, si vous validez localement avec xmllint ou un validateur XSD embarqué, vous devez remplacer le fichier XSD de référence :

# Avant (Factur-X 1.07)
xmllint --schema CrossIndustryInvoice_100pD16B.xsd factur-x.xml --noout

# Après (Factur-X 1.08)
xmllint --schema CrossIndustryInvoice_100pD22B.xsd factur-x.xml --noout

Nouveaux éléments optionnels dans D22B

Le passage à D22B élargit le vocabulaire disponible dans le schéma CII. Les profils EXTENDED et EXTENDED-CTC-FR de Factur-X 1.08 peuvent exploiter ces nouveaux éléments pour transporter des données métier supplémentaires.

Il est important de souligner que ces ajouts sont tous optionnels. Aucun champ obligatoire n’a été ajouté au noyau EN16931 par le changement de binding. Les profils MINIMUM, BASIC WL, BASIC et EN 16931 ne requièrent aucun des nouveaux éléments D22B. Pour un développeur qui cible ces profils, le changement D16B vers D22B est strictement transparent.

Les profils EXTENDED et EXTENDED-CTC-FR, en revanche, peuvent tirer parti du vocabulaire élargi de D22B pour des cas d’usage spécifiques — données de transport, informations douanières enrichies, ou extensions nationales. La spécification Factur-X 1.08 publiée par FNFE-MPE documente précisément quels éléments D22B sont exploités par chaque profil.

Parmi les ajouts notables de D22B exploitables dans les profils EXTENDED et EXTENDED-CTC-FR : la gestion des sous-lignes (sub-lines), utiles pour les sous-totaux, les kits, les bundles et les articles composites. Cette structuration permet de détailler une ligne de facture en sous-éléments sans impacter les totaux de premier niveau.

Pour comprendre les différences entre profils et choisir le bon, voir Profils Factur-X : MINIMUM, BASIC, EN16931, EXTENDED.

Impact sur les pipelines de validation

La validation d’une facture Factur-X comprend trois niveaux : conformité PDF/A-3, validation XSD, et validation Schematron. Le passage à la version 1.08 impacte les deux derniers.

Validation XSD : mettre à jour le schéma

Si vous embarquez une validation XSD dans votre pipeline (en local ou en CI/CD), vous devez remplacer le fichier XSD D16B par le D22B. C’est le seul changement requis — le reste de votre pipeline XSD (parseur, intégration xmllint, etc.) ne change pas.

Les XSD officiels sont distribués avec la spécification Factur-X 1.08 publiée par la FNFE-MPE, et avec la spécification ZUGFeRD 2.4 publiée par le FeRD.

Validation Schematron : vérifier la version des artefacts

Les artefacts Schematron EN16931 (les fichiers .sch ou .xslt compilés) sont publiés par le CEN TC 434 et distribués via le dépôt ConnectingEurope. Ils sont versionnés indépendamment du binding CII.

Les Schematron valident la sémantique (cohérence des montants, présence conditionnelle de champs, règles BR-*), pas la syntaxe D16B vs D22B. Le passage à D22B ne change pas la nature des contrôles Schematron, qui restent sémantiques. En pratique, vérifiez la version exacte des artefacts de validation que vous déployez.

Les artefacts Schematron évoluent : des règles sont corrigées, des edge cases sont traités. Il est recommandé de vérifier que vous utilisez la dernière version publiée des artefacts Schematron, indépendamment du passage à 1.08.

Les Schematron spécifiques aux profils Factur-X (MINIMUM, BASIC WL, BASIC, EXTENDED) sont distribués par la FNFE-MPE. Ceux-ci ont été mis à jour pour la version 1.08 — assurez-vous de les récupérer si vous validez les contraintes de profil localement.

Pour comprendre la distinction XSD vs Schematron et le workflow de debug des erreurs BR-*, voir Valider EN16931 / Factur-X : XSD vs Schematron, erreurs BR-*.

Validation PDF/A-3 : aucun changement

Le conteneur PDF/A-3 (ISO 19005-3) n’est pas impacté par le changement de version Factur-X. Les exigences restent identiques : polices embarquées, profil ICC, AFRelationship cohérent avec la relation réelle entre PDF et XML (Data, Source ou Alternative selon le cas), métadonnées XMP avec le namespace fx:. Pour le détail des contraintes PDF/A-3, voir PDF/A-3 vs PDF/A-1 : pourquoi Factur-X exige PDF/A-3.

API FacturX API : mise à jour automatique

Si vous utilisez l’API FacturX API pour la validation, les artefacts (XSD D22B, Schematron EN16931, Schematron profils) sont mis à jour côté serveur. Aucune modification de votre intégration n’est nécessaire. L’API accepte les factures générées en D16B comme en D22B.

GuidelineID : pas de changement de format

Les URN GuidelineID — les identifiants qui déclarent le profil Factur-X dans le XML — ne changent pas entre la version 1.07 et la version 1.08. C’est un point de confusion fréquent.

Ces URN sont identiques en Factur-X 1.07 et 1.08. Le 1p0 dans l’URN fait référence à la série majeure du standard (1.x), pas à la version mineure. Un XML Factur-X 1.07 avec le GuidelineID urn:cen.eu:en16931:2017 et un XML Factur-X 1.08 avec le même GuidelineID sont traités de la même manière par les validateurs.

Ce qui change entre 1.07 et 1.08, c’est le schéma XSD sous-jacent (D16B vs D22B) et les artefacts de validation associés — pas l’identifiant de profil déclaré dans le document.

Migration depuis une version antérieure

Depuis Factur-X 1.07 / ZUGFeRD 2.3

C’est le cas le plus courant et le plus simple. Les XML existants restent valides sans modification :

• Les GuidelineID sont identiques
• Les namespaces XML sont identiques
• Les artefacts Schematron EN16931 restent compatibles
• Le XSD D22B accepte tous les documents D16B valides

Actions requises :

1. Mettre à jour les XSD si vous validez localement (D16B vers D22B)
2. Mettre à jour les Schematron de profil Factur-X si vous les utilisez en local
3. Tester vos fichiers existants contre les nouveaux artefacts pour confirmer l’absence de régression

Si vous utilisez un validateur comme KoSIT ou Mustangproject, vérifiez que la version déployée intègre les artefacts 1.08. Pour un comparatif des options de validation, voir Déployer un validateur Factur-X : KoSIT, Mustangproject ou API SaaS.

Depuis ZUGFeRD 2.0

Si vous migrez depuis ZUGFeRD 2.0 (2019), la rupture est plus significative. ZUGFeRD 2.0 utilisait un jeu de GuidelineID différent et certaines conventions d’embedding spécifiques. Les changements incluent :

• GuidelineID : les URN de ZUGFeRD 2.0 (préfixe urn:zugferd.de:2p0) ont été remplacés par les URN unifiés Factur-X depuis ZUGFeRD 2.1
• Nom du fichier embarqué : ZUGFeRD 2.0 utilisait zugferd-invoice.xml ; les versions 2.1+ acceptent les deux noms (zugferd-invoice.xml et factur-x.xml)
• Schematron de profil : les règles spécifiques aux profils ont évolué significativement

Cette migration nécessite une adaptation du code de génération XML, pas seulement une mise à jour des artefacts de validation.

Depuis Factur-X 1.0 / ZUGFeRD 2.1

Migration intermédiaire. Les GuidelineID sont déjà au format unifié. Les namespaces sont identiques. La principale différence est le passage D16B vers D22B et les éventuelles corrections de règles Schematron accumulées entre les versions. En pratique, les documents conformes à la version 1.0 passent la validation 1.08 dans la grande majorité des cas.

Recommandation générale : quelle que soit votre version de départ, validez un échantillon représentatif de vos factures existantes avec les artefacts 1.08 avant de mettre à jour votre pipeline de production. Cela détecte les éventuelles incompatibilités sans risque.

Résumé pour les développeurs pressés

Pour la majorité des développeurs qui ciblent les profils MINIMUM à EN 16931, la migration 1.07 vers 1.08 se résume à mettre à jour les fichiers XSD et à vérifier la version des artefacts Schematron. Le code de génération XML n’a pas besoin de changer.

Aller plus loin

• Facturation électronique 2026 : le guide technique complet — contexte de la réforme et architecture PDP
• Profils Factur-X : MINIMUM, BASIC, EN16931, EXTENDED — matrice de choix technique entre profils
• PDF/A-3 vs PDF/A-1 : pourquoi Factur-X exige PDF/A-3 — exigences du conteneur PDF
• Valider EN16931 / Factur-X : XSD vs Schematron, erreurs BR-* — workflow de debug complet
• Déployer un validateur Factur-X : KoSIT, Mustangproject ou API SaaS — comparatif des options de validation
• Champs obligatoires EN16931/Factur-X : cartographie et mapping ERP — mapping complet des Business Terms par profil