Factur-X : que faire si le PDF et l’XML divergent ?

Une facture arrive dans une GED. À l’écran, le PDF présente un montant exigible. L’ERP, lui, importe une autre valeur depuis l’XML embarqué. Le comptable voit une facture ; le système en traite une autre.

Le réflexe consiste souvent à demander quelle représentation doit « gagner ». Le PDF, parce qu’il est lisible et contrôlé par un humain ? L’XML, parce qu’il est structuré et destiné à l’automatisation ? Aucune de ces réponses n’est sûre dans tous les cas. Le bon niveau de décision n’est pas le fichier entier, mais le champ métier, sa provenance et la preuve disponible.

En bref

• Une facture hybride Factur-X porte un rendu PDF et un XML embarqué : une contradiction matérielle n’est pas une variante normale à ignorer.
• Un XML attaché dans un PDF/A-3 ne prouve pas à lui seul qu’il s’agit d’un Factur-X conforme.
• Distinguer présentation, écart explicable et contradiction métier avant de bloquer.
• Arbitrer par champ, conserver ce qui concorde, demander uniquement la décision minimale.
• scan = diagnostic ; convert = transformation ; profil non exécuté = non évalué. Aucune transmission officielle ni acceptation PA.

Une facture hybride peut contenir deux vérités opérationnelles

La publication Factur-X 1.09 / ZUGFeRD 2.5 du 10 juin 2026, corrigée en 1.09.2 / 2.5.2 le 4 août 2026, reste techniquement le format hybride de référence à revérifier à la lecture. Le FeRD décrit le format hybride comme des données XML structurées embarquées dans un fichier PDF/A-3, le PDF constituant la représentation visuelle (publication officielle ZUGFeRD 2.5). Le FeRD recommande d’utiliser cette version à partir du 1er juillet 2026 ; cela n’équivaut pas à une obligation légale française à cette date exacte.

Cette dualité ne crée pas deux factures indépendantes. La documentation du FeRD présente le PDF et l’XML comme portant les mêmes informations de facture (FAQ technique). Une contradiction matérielle n’est donc pas une variante normale à ignorer : c’est un défaut à qualifier.

Il faut toutefois commencer par identifier ce que l’on a réellement reçu.

PDF/A-3 autorise techniquement l’inclusion de contenus arbitraires comme fichiers embarqués (ISO 19005-3). La présence d’une pièce jointe XML n’est donc pas spécifique à Factur-X. Le dossier officiel Factur-X ajoute notamment un schéma d’extension XMP, des profils, des XSD et des Schematron (contenu du dossier Factur-X 1.09). En déduire qu’un XML attaché suffit à qualifier le porteur serait une erreur.

Pourquoi choisir silencieusement une représentation est dangereux

Deux risques symétriques :

• faire gagner l’XML peut injecter dans l’ERP une valeur étrangère au rendu contrôlé par l’utilisateur ;
• faire gagner le PDF peut supprimer des données structurées exactes, plus détaillées ou invisibles dans la mise en page.

Le problème n’est pas seulement documentaire. Une divergence sur le total exigible peut fausser le paiement ; sur la TVA, la comptabilisation ; sur la devise, tous les calculs ; sur l’identité d’une partie, le rapprochement ; sur les lignes, les réceptions ; sur le compte de paiement, le contrôle antifraude. Une variation typographique n’a évidemment pas la même gravité.

Pour replacer ce conflit dans un diagnostic plus large, voir Pourquoi valider une facture électronique ne se résume pas à « valide / invalide ».

Différence de présentation ou contradiction métier ?

Avant de créer une alerte, le système doit normaliser les valeurs et distinguer cinq niveaux.

EN 16931 définit un modèle sémantique et des règles métier ; la Commission européenne rappelle notamment que les informations pertinentes doivent être structurées comme prévu et que les montants doivent être calculés conformément aux règles applicables (conformité EN 16931). Cela justifie une validation par profil et des recalculs contrôlés. Cela ne crée pas pour autant une règle universelle disant que le PDF ou l’XML gagne toujours en cas de conflit.

La méthode robuste : un diagnostic par champ

Pour chaque terme métier, une GED ou une API devrait conserver au minimum :

• la valeur visible dans le PDF et son emplacement ;
• la valeur structurée dans l’XML et son chemin ;
• l’éventuelle valeur recalculée ;
• la provenance et les transformations appliquées ;
• le niveau de confiance de l’extraction ;
• le type de conflit ;
• l’autorité démontrée, ou son absence ;
• l’action proposée.

L’« autorité » ne doit pas être une préférence codée en dur. Elle peut être établie par une chaîne de génération traçable, un calcul déterministe, une donnée maître explicitement définie, ou une confirmation humaine. Sans cette preuve, le système doit conserver l’incertitude.

Exemple synthétique

L’exemple suivant est entièrement fictif. Le PDF et l’XML concordent sur les parties, la devise, les lignes et le compte de paiement. Le PDF affiche cependant une remise que l’XML ne porte pas ; les bases, la TVA et le total en divergent mécaniquement.

La décision humaine minimale tient en une question : la remise globale est-elle applicable ? Le système n’a aucune raison de redemander la devise, les lignes, les parties ou le compte de paiement. Après la réponse, il peut recalculer les valeurs dépendantes, produire un candidat distinct et documenter le changement.

Quand corriger automatiquement et quand demander un arbitrage

Chaque conflit doit aboutir à une action explicite parmi cinq familles :

1. Correction déterministe : normalisation de format ou recalcul dont les entrées et la règle sont établies.
2. Conservation des deux valeurs avec avertissement : utile lorsque l’écart n’affecte pas la sémantique ciblée mais mérite une trace.
3. Confirmation ciblée : une seule décision métier résout plusieurs valeurs dépendantes.
4. Blocage de la génération finale : nécessaire lorsque choisir sans preuve modifierait une donnée matérielle du candidat.
5. Impossibilité de conclure : extraction insuffisante, profil inconnu ou preuves incompatibles.

Un conflit local ne doit pas déclencher une ressaisie générale. Il ne justifie pas non plus automatiquement une reconstruction complète. La stratégie « réparer ou reconstruire » est développée dans Réparer ou reconstruire une facture électronique. Ici, l’invariant est simple : préserver tout ce qui est non conflictuel et n’arbitrer que ce qui doit l’être.

Ce qu’un candidat corrigé doit prouver

Un candidat doit être séparé de la source. Le dossier minimal devrait comprendre : identifiant du candidat, SHA-256, hash des sources, opération appliquée, profil ciblé, résultats de validation, diff champ par champ, données conservées, modifiées et omises. Une nouvelle comparaison PDF/XML doit porter sur le candidat lui-même.

Le hash ne prouve pas que la facture est correcte. Il prouve que le rapport, le diff et les validations concernent un artefact déterminé. Sans fichier réel, une mention « candidat généré » ou « validé » reste invérifiable. Voir Un candidat généré sans fichier, hash, diff ni omissions explicites n’est pas une preuve.

La distinction source/candidat ne signifie pas non plus « prêt à transmettre ». Cette étape aval est traitée dans « Générable maintenant » ne veut pas dire « prêt à transmettre ».

Ce qu’il faut demander à une API ou à une GED

Avant de confier les écritures à une représentation hybride, demandez au fournisseur de démontrer :

1. la classification distincte d’un Factur-X, d’un PDF avec pièce jointe, d’une paire PDF/XML et d’un XML autonome ;
2. l’extraction parallèle du PDF et de l’XML, sans canal privilégié silencieusement ;
3. la normalisation et la comparaison par champ ;
4. la provenance, la confiance et la base d’autorité de chaque décision ;
5. la conservation des données non conflictuelles ;
6. le nombre exact de décisions humaines restantes ;
7. l’existence du candidat, de son hash, de ses validations et de son diff ;
8. la parité des constats entre API, interface Web et rapport.

Une démonstration limitée à « XML détecté » ou à un badge vert ne répond à aucune de ces questions.

Positionnement FacturX API — sans promesse runtime non prouvée

FacturX API se positionne comme brique de préparation documentaire. Un scan public est un diagnostic documentaire, pas une transmission officielle ni une acceptation PA. Une conversion, lorsqu’elle s’applique, est une transformation documentaire. FacturX API n’est pas une Plateforme Agréée.

La méthode de comparaison PDF/XML champ par champ décrite ici est un modèle d’architecture à exiger. Les capacités avancées de détection, de provenance complète et de parité API/Web/rapport doivent être évaluées sur un parcours synthétique réel, borné aux cas réellement supportés, avant toute promesse d’intégration.

Sources officielles

• FNFE-MPE — Factur-X
• FNFE-MPE — Contenu du dossier Factur-X 1.09 / 1.09.2
• FeRD — ZUGFeRD 2.5
• FeRD — FAQ technique
• ISO — ISO 19005-3 (PDF/A-3)
• Commission européenne — EN 16931 compliance

Les versions Factur-X / ZUGFeRD évoluent : revérifiez la publication courante au moment de la lecture.

Articles liés

• Réparer ou reconstruire une facture électronique
• Un candidat généré sans fichier, hash, diff ni omissions explicites n’est pas une preuve
• Pourquoi valider une facture électronique ne se résume pas à « valide / invalide »
• « Générable maintenant » ne veut pas dire « prêt à transmettre »
• Extraire le XML d’un PDF Factur-X
• PDF/A-3 Factur-X : conformité et pièges