Convertir une facture PDF en Factur-X ou ZUGFeRD

Transformer un PDF existant en facture hybride conforme, ce sont deux tâches et non une — et la moitié difficile n’est pas la construction du fichier, mais les données.

Vous avez des années de factures au format PDF ordinaire, et voilà qu’un client réclame une facture électronique structurée. La question qui vient naturellement est de savoir si l’on peut simplement convertir l’existant. La réponse honnête a deux moitiés : la partie technique est simple — et la partie qui décide si le résultat est fiable ne l’est pas.

La distinction compte, car le mot « convertir » masque une étape. Un PDF ordinaire ne contient aucune donnée structurée. Visuellement, il peut être indiscernable d’un vrai fichier Factur-X, mais il n’y a aucun XML incorporé qu’un logiciel puisse lire. Convertir signifie donc deux choses distinctes : obtenir les données de la facture, puis construire un fichier correct avec ces données à l’intérieur.

Un PDF ordinaire ne contient aucune donnée structurée ; les données viennent soit du système source, soit d’une lecture du PDF qui doit être vérifiée ; ensuite un fichier PDF/A-3 est construit avec le XML incorporé
C’est l’étape du milieu qui décide si l’on peut faire confiance au résultat.

Étape 1 — d’où viennent les données

Il existe deux voies, et elles ne sont pas également fiables.

Depuis le système qui a produit la facture

Si le PDF a été généré par un logiciel de comptabilité ou de facturation, ce logiciel détient toujours les chiffres sous-jacents : montants, taux de taxe, lignes, dates, identifiants. Alimenter le générateur avec ces chiffres est la voie fiable, car rien n’a besoin d’être deviné — les données sont déjà exactes et déjà structurées.

Cela vaut la peine d’y tenir, même quand cela paraît demander plus de travail. Reconstituer des chiffres à partir d’une page mise en page revient à reconstruire ce qui existe déjà, sous forme exacte, ailleurs.

Lire les données dans le PDF

Lorsque seul le PDF existe — une facture fournisseur, une archive, un document issu d’un système que vous n’exploitez plus — les données doivent être récupérées depuis le fichier lui-même. Deux cas :

  • Le PDF possède une couche de texte. C’est le cas de la plupart des PDF produits par un logiciel. Le texte se lit directement, et la difficulté tient à la mise en page : quel nombre est le total hors taxes, lequel est la taxe, quelles lignes appartiennent au tableau.
  • Le PDF est un scan. Une facture photographiée ou numérisée n’est qu’une image ; les caractères doivent d’abord être reconnus (OCR), puis interprétés. Chaque erreur de reconnaissance devient un chiffre faux en aval.

Cette étape exige un humain. L’extraction fondée sur la mise en page d’une facture quelconque n’est pas encore au point où l’on pourrait lui confier les chiffres qui comptent — montants de TVA, totaux, identifiants. Tout processus sérieux soumet les valeurs extraites à une personne qui les confirme avant que le fichier ne soit construit. Un convertisseur qui promet une facture électronique finie à partir de n’importe quel PDF en trente secondes, sans rien à vérifier, promet ce que l’état de l’art ne permet pas.

Étape 2 — construire le fichier

Une fois les données confirmées, elles doivent être incorporées dans un conteneur PDF/A-3. C’est là qu’échouent beaucoup de tentatives artisanales, car joindre un fichier XML à un PDF dans un éditeur n’est pas la même chose.

Un fichier hybride correct exige :

  • Un conteneur PDF/A-3 valide — la variante archivistique du PDF, avec polices incorporées et profils colorimétriques déclarés.
  • Le XML rattaché avec la bonne relation (AFRelationship) et sous le nom de fichier attendu, afin que le logiciel destinataire le reconnaisse comme données de facture.
  • Des métadonnées XMP déclarant la norme et le profil auxquels le fichier prétend se conformer.
  • Un profil qui correspond aux données réellement disponibles. Revendiquer le profil EN 16931 en omettant des champs qu’il exige produit un fichier qui échoue à la validation ; voir les profils.

Et Acrobat, PDF24 ou les logiciels de comptabilité ?

La question revient sans cesse, autant y répondre franchement.

  • Les outils PDF généralistes — Acrobat, PDF24 et leurs semblables — savent joindre un fichier à un PDF et souvent produire du PDF/A. Ce qu’ils ne savent pas faire : construire un XML de facture CII valide à partir de votre facture, parce qu’ils ignorent ce qu’est une facture. Joindre un XML fabriqué à la main donne un fichier qui échoue dès la première couche de validation.
  • Les logiciels de comptabilité et de facturation produisent de plus en plus souvent du Factur-X directement, et lorsque vos factures naissent là, c’est de loin la meilleure voie : les données ne quittent jamais leur forme structurée. Ce que ces systèmes n’offrent généralement pas, c’est la conversion d’un PDF tiers quelconque qui ne vient pas d’eux.
  • Les convertisseurs dédiés se situent entre les deux : ils lisent le PDF, proposent les données et construisent le fichier hybride. Leur point faible est toujours l’étape de lecture — c’est pourquoi l’écran de confirmation compte davantage que la vitesse de conversion.

Faut-il vraiment convertir vos archives ?

En général non, et cela épargne beaucoup de travail inutile.

Les obligations portent sur les factures que vous émettez désormais, pas rétroactivement sur celles déjà émises. Ces dernières restent valides sous la forme dans laquelle elles ont été émises et doivent être conservées sous cette forme pendant la durée légale. Convertir un ancien fonds d’archives en Factur-X est donc un projet facultatif, le plus souvent superflu.

Les cas où convertir des PDF existants aide réellement sont plus étroits : un client qui n’accepte que des factures structurées, y compris pour des documents déjà envoyés ; une migration d’un système à un autre ; ou une facture fournisseur entrante que vous souhaitez comptabiliser automatiquement.

Toujours vérifier le résultat

Un fichier converti ne devrait jamais partir sans contrôle. La conversion offre plus d’occasions d’erreur que la génération de zéro, parce que les données ont traversé une étape d’interprétation. Faites passer le fichier obtenu par un validateur et regardez les trois couches — conteneur, schéma et règles de gestion — avant qu’il n’atteigne qui que ce soit. Le fonctionnement est décrit dans comment fonctionne la validation.

Deux échecs sont particulièrement fréquents après une conversion :

  • Des totaux qui ne se recoupent pas — écarts d’arrondi entre la somme des lignes et le total du document, signalés par des codes BR-CO-*.
  • Une catégorie de TVA sans la justification requise — par exemple une facture exonérée ou en autoliquidation sans motif indiqué.

Les deux proviennent de l’étape d’extraction, non du format de fichier — c’est exactement la raison d’être de l’écran de confirmation. Voir les règles de gestion pour ce que ces codes vérifient.

Ce qu'il faut réunir avant de commencer

Une facture structurée exige des mentions qu'une facture PDF ordinaire ne porte pas toujours. Avant de vous lancer, passez cette liste en revue — s'il manque une mention, aucun outil n'y changera rien : il faut aller la chercher.

MentionChampPrésente sur une facture ordinaire ?
Numéro, date, deviseBT-1, BT-2, BT-5toujours
Nom et adresse du vendeur, code paysBT-27, BG-5, BT-40presque toujours — le pays rarement sous forme de code
Nom de l'acheteurBT-44toujours
Numéro de TVA ou identifiant fiscal du vendeurBT-31 / BT-32souvent, mais fréquemment sans préfixe pays
Lignes avec quantité, prix unitaire, montant netBG-25oui, mais sous forme d'image de tableau
Taux et montant de TVA par tauxBT-119, BT-117le plus souvent en total seulement, pas par catégorie
Coordonnées de paiement, IBANBG-16, BT-84souvent — imprimé avec des espaces
Référence acheteur ; pour le secteur public, l'identifiant de routageBT-10rarement — à demander au destinataire
Contact du vendeur : nom, téléphone, e-mailBG-6rarement complet
Motif d'exonération ou d'autoliquidationBT-120 / BT-121sous forme de phrase, pas de champ

Les trois dernières lignes sont la raison habituelle pour laquelle une conversion par ailleurs impeccable échoue : l'information existe dans l'opération, mais pas sur la feuille.

Étape par étape

  1. Remonter à la source. Le logiciel qui a produit cette facture existe-t-il encore ? Si oui, exportez-en les données et sautez entièrement l'extraction. Ce n'est pas un détour, c'est le raccourci.
  2. Vérifier qu'il y a une couche de texte. Sélectionnez un montant à la souris dans votre lecteur PDF. S'il se sélectionne et se copie, il y a du texte. Si la sélection saute à la page entière, c'est une image — un scan, et le chemin s'allonge.
  3. Extraire et affecter les données. Les caractères reconnus doivent devenir des champs. C'est l'étape où naissent les erreurs ; la section ci-dessous montre exactement où.
  4. Compléter ce qui manque. Identifiant de routage, coordonnées de contact, motif d'exonération — voir la liste ci-dessus. Rien de tout cela ne se devine.
  5. Construire le fichier. Choisir un profil (EN 16931 en règle générale), produire le XML, le placer en pièce jointe dans un PDF/A-3. Cette étape est purement mécanique et échoue rarement.
  6. Vérifier, puis envoyer. Conteneur, schéma, règles de gestion. Ensuite, comparez les montants du rapport avec ceux de la page — la vérification ne dit rien sur le fait que 850,00 était le bon chiffre au départ.

Les étapes 1 à 4 coûtent le temps. L'étape 5 prend quelques secondes, et l'étape 6 est la seule qui vous dise si les précédentes étaient justes.

Un exemple déroulé

La théorie n'aide guère ici, voici donc le chemin complet sur une facture. Le PDF possède une couche de texte : c'est le cas favorable — pas de scan, pas de reconnaissance de caractères. Ce qu'un extracteur de texte tire de la page ressemble à ceci :

Ligne de la couche de texte
Muster Werkzeug GmbH · Industriestr. 4 · 45127 Essen
Rechnung Nr. 2026-0417 Kundennummer 88213
Rechnungsdatum 04.09.2026 Lieferdatum 01.09.2026
3 Spannzange SZ-12 249,00 747,00
1 Adapterplatte A-4 120,50 120,50
Rabatt 2 % -17,50
Nettobetrag 850,00
zzgl. 19 % USt 161,50
Rechnungsbetrag 1.011,50
USt-IdNr. DE812345678 IBAN DE89370400440532013000

Un humain lit cela en deux secondes. Pour un programme, ce ne sont que des caractères avec des coordonnées, et il faut en tirer une affectation vers les champs de la norme :

ChampValeurCe dont cela dépend
BT-1 numéro de facture2026-0417sur la même ligne que le numéro de client — la confusion des deux est l'erreur la plus fréquente
BT-2 date d'émission2026-09-04format national sur la page, ISO dans le XML
BT-27 vendeurMuster Werkzeug GmbHpremière ligne de l'en-tête — sauf si l'en-tête est un logo en image
BT-31 numéro de TVADE812345678reconnaissable sans ambiguïté, donc fiable
BT-131 lignes747,00 et 120,50le tableau doit être reconnu comme un tableau, pas comme un bloc de texte
BT-107 remise17,50un signe moins devant ; s'il est manqué, la remise s'ajoute
BT-109 net850,00—
BT-117 taxe161,50le taux 19 est dans le même fragment de texte que le montant
BT-112 TTC1011,50le séparateur de milliers doit disparaître — 1.011,50 lu comme un nombre donne sinon 1,01
BT-84 IBANDE89370400440532013000imprimé avec des espaces, il va dans le XML sans

Quatre endroits de cette seule facture sont délicats, et aucun n'est exotique : le numéro de facture à côté du numéro de client, le format de date, le séparateur de milliers et le signe de la remise. C'est précisément pourquoi un contrôle humain se trouve au bout de ce chemin, et non une automatisation.

Si l'affectation est juste, le reste suit : 747,00 + 120,50 = 867,50, moins 17,50 font 850,00, plus 19 % font 1011,50. Ce sont les mêmes chaînes que recalculent les règles de gestion.

Cas particulier : la facture est un scan

Avec un document scanné ou photographié, il n'y a pas de couche de texte — il y a une image. La reconnaissance de caractères s'intercale entre l'image et les champs, et elle ne se comporte pas comme une erreur que l'on remarque : elle ne produit pas un champ vide, mais un champ faux. Un 8 devient un 3, 1.011,50 devient 1.011,5D, un O devient un 0.

Trois choses séparent l'exploitable du dangereux :

  • La résolution. En dessous de 300 dpi, la reconnaissance devient de la devinette. Une photo d'écran est inutilisable à cet usage.
  • Une page droite. Des feuilles entraînées de travers décalent les colonnes entre elles, et « ce nombre appartient à cette colonne » est la première chose à casser.
  • Un contrôle de chaque nombre ensuite. Pas par sondage. Totaux, montants de taxe, identifiants et numéro de facture sont relus un à un contre la page.

Si le document vient d'un fournisseur, le chemin le plus court consiste presque toujours à lui demander le fichier structuré plutôt qu'à le reconstruire depuis son papier. Il doit de toute façon être en mesure d'en recevoir un, et en règle générale son logiciel sait aussi en émettre.

Erreurs courantes et messages qu'elles déclenchent

La conversion produit toujours les mêmes erreurs et, comme la vérification répond à chacune par un code de règle, le code ramène à la cause.

Ce qui dérapeMessageCorrection
Séparateur de milliers lu avec le nombre, le TTC arrive à 1,01BR-CO-15retirer les séparateurs avant la conversion, pas après
Remise reprise sans son signe moinsBR-CO-13une remise va dans BT-107 en montant positif, pas en ligne négative
Totaux de ligne recalculés depuis quantité × prix au lieu d'être reprisBR-CO-10reprendre le total de ligne imprimé — c'est lui qui fait foi
Montant de taxe arrondi, base non arrondieBR-CO-17les deux valeurs à deux décimales, arrondi commercial
Numéro de TVA repris des données de base sans préfixe paysBR-CO-09ajouter le code pays, supprimer les espaces
Identifiant fiscal trouvé à la place du numéro de TVA, les deux champs restent videsBR-CO-26placer l'identifiant fiscal dans BT-32 plutôt que de le jeter
IBAN repris avec ses espacesBR-DE-19retirer les séparateurs
Tableau des lignes non reconnu, seuls les totaux reprisBR-16une ligne globale sur le total vaut mieux qu'aucune

Un message qui n'est pas une erreur. Chaque fichier ZUGFeRD converti affiche BR-DE-21. Il dit seulement que le fichier n'est pas une XRechnung — ce qui est exact et voulu.

Questions fréquentes

Puis-je convertir un scan ?

Techniquement oui, de façon fiable non. Un scan est une image ; les caractères doivent d'abord être reconnus, et chaque erreur de reconnaissance devient un nombre faux dans un champ qui compte. Si c'est inévitable, contrôlez chaque chiffre à la main — surtout les totaux et les identifiants.

Puis-je convertir tout mon archivage d'un coup ?

Vous le pouvez, mais vous n'en avez presque jamais besoin. L'obligation porte sur les factures que vous émettez à partir de l'échéance, pas sur vos archives. Les anciennes factures restent valables et conservables en PDF. La conversion n'a de sens que si un destinataire réclame après coup une facture ancienne sous forme structurée.

L'apparence de la facture est-elle conservée ?

Oui. Dans une facture hybride, la page visible ne change pas — le XML lui est joint, il ne la remplace pas. Qui ouvre le fichier dans un lecteur PDF voit ce qu'il voyait avant.

Et s'il manque dans le PDF une mention exigée par la norme ?

Alors elle ne peut pas non plus en être extraite, et il faut l'ajouter. Les manques les plus fréquents sont la référence acheteur pour le secteur public (BR-DE-15) et les coordonnées de contact du vendeur (BR-DE-2). Ni l'une ni les autres ne figurent complètes sur une facture ordinaire.

Quel profil choisir ?

EN 16931 en règle générale — c'est le profil conforme à la norme et celui qu'attendent les destinataires. BASIC suffit pour des factures simples, EXTENDED n'est nécessaire que pour des situations que la norme ne couvre pas. Les différences sont détaillées sous profils.

Comment savoir que la conversion a réussi ?

Pas au fait que le fichier s'ouvre. Déposez-le dans une vérification et lisez le rapport : conteneur, schéma et règles de gestion doivent tous passer. Comparez ensuite les chiffres du rapport avec ceux de la page — la vérification confirme la conformité, pas l'exactitude.

En résumé

  • Convertir, c'est obtenir des données puis construire un fichier. La seconde étape est triviale ; la première décide du résultat.
  • Depuis le système plutôt que depuis le PDF. Si les chiffres existent encore structurés quelque part, prenez-les là.
  • Couche de texte oui, scan seulement avec contrôle. La reconnaissance produit des nombres faux, pas des champs vides — et un nombre faux ne se remarque pas.
  • Quatre pièges couvrent la plupart des erreurs : numéro de facture à côté du numéro de client, format de date, séparateur de milliers, signe de la remise.
  • Vérifiez toujours avant d'envoyer — et cherchez le code de règle dans le répertoire des codes au lieu de deviner.
  • L'archivage n'a pas à être converti. L'obligation vise les nouvelles factures.

Ce à quoi s’attendre, honnêtement

La conversion entièrement automatique — déposer n’importe quel PDF, récupérer un fichier hybride validé, ne rien contrôler — est un domaine en développement actif qui dépend de la fiabilité de l’extraction de données, au point de pouvoir lui confier des chiffres fiscaux. Elle n’y est pas encore pour des mises en page quelconques, et quiconque prétend le contraire vend la démonstration plutôt que le cas général.

La voie qui fonctionne aujourd’hui est peu spectaculaire et sûre : prendre les données là où elles ont été produites quand c’est possible, les confirmer une fois quand ça ne l’est pas, laisser le générateur construire le PDF/A-3 et le XML, et valider avant d’envoyer.