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.
É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.
| Mention | Champ | Présente sur une facture ordinaire ? |
|---|---|---|
| Numéro, date, devise | BT-1, BT-2, BT-5 | toujours |
| Nom et adresse du vendeur, code pays | BT-27, BG-5, BT-40 | presque toujours — le pays rarement sous forme de code |
| Nom de l'acheteur | BT-44 | toujours |
| Numéro de TVA ou identifiant fiscal du vendeur | BT-31 / BT-32 | souvent, mais fréquemment sans préfixe pays |
| Lignes avec quantité, prix unitaire, montant net | BG-25 | oui, mais sous forme d'image de tableau |
| Taux et montant de TVA par taux | BT-119, BT-117 | le plus souvent en total seulement, pas par catégorie |
| Coordonnées de paiement, IBAN | BG-16, BT-84 | souvent — imprimé avec des espaces |
| Référence acheteur ; pour le secteur public, l'identifiant de routage | BT-10 | rarement — à demander au destinataire |
| Contact du vendeur : nom, téléphone, e-mail | BG-6 | rarement complet |
| Motif d'exonération ou d'autoliquidation | BT-120 / BT-121 | sous 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
- 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.
- 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.
- 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ù.
- 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.
- 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.
- 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 :
| Champ | Valeur | Ce dont cela dépend |
|---|---|---|
BT-1 numéro de facture | 2026-0417 | sur 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'émission | 2026-09-04 | format national sur la page, ISO dans le XML |
BT-27 vendeur | Muster Werkzeug GmbH | première ligne de l'en-tête — sauf si l'en-tête est un logo en image |
BT-31 numéro de TVA | DE812345678 | reconnaissable sans ambiguïté, donc fiable |
BT-131 lignes | 747,00 et 120,50 | le tableau doit être reconnu comme un tableau, pas comme un bloc de texte |
BT-107 remise | 17,50 | un signe moins devant ; s'il est manqué, la remise s'ajoute |
BT-109 net | 850,00 | — |
BT-117 taxe | 161,50 | le taux 19 est dans le même fragment de texte que le montant |
BT-112 TTC | 1011,50 | le séparateur de milliers doit disparaître — 1.011,50 lu comme un nombre donne sinon 1,01 |
BT-84 IBAN | DE89370400440532013000 | imprimé 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érape | Message | Correction |
|---|---|---|
| Séparateur de milliers lu avec le nombre, le TTC arrive à 1,01 | BR-CO-15 | retirer les séparateurs avant la conversion, pas après |
| Remise reprise sans son signe moins | BR-CO-13 | une 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 repris | BR-CO-10 | reprendre le total de ligne imprimé — c'est lui qui fait foi |
| Montant de taxe arrondi, base non arrondie | BR-CO-17 | les deux valeurs à deux décimales, arrondi commercial |
| Numéro de TVA repris des données de base sans préfixe pays | BR-CO-09 | ajouter le code pays, supprimer les espaces |
| Identifiant fiscal trouvé à la place du numéro de TVA, les deux champs restent vides | BR-CO-26 | placer l'identifiant fiscal dans BT-32 plutôt que de le jeter |
| IBAN repris avec ses espaces | BR-DE-19 | retirer les séparateurs |
| Tableau des lignes non reconnu, seuls les totaux repris | BR-16 | une 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.
