Facture électronique : où placer un QR code sur une facture française
Votre fournisseur vous adresse une facture qui ressemble trait pour trait à celle du mois d'août. Même mise en page, même logo, et près des conditions de règlement un QR code qui pointe vers une page de paiement. Depuis septembre, ce fichier transporte aussi un XML à l'intérieur de lui-même, et c'est ce XML que lit le logiciel comptable de votre client. Le QR code n'y figure pas, et il n'y figurera jamais.
Ce seul constat détermine la place d'un QR code sur une facture française et ce que vous pouvez raisonnablement lui demander.
La réforme, réduite à ce qui compte ici
La facturation entre entreprises passe désormais par des données structurées échangées via des intermédiaires immatriculés. Deux dates portent le changement. Depuis le 1er septembre 2026, toute entreprise assujettie à la TVA en France doit être en mesure de recevoir une facture électronique structurée, et les grandes entreprises ainsi que les ETI doivent émettre les leurs sous cette forme. Au 1er septembre 2027, l'obligation d'émission s'étendra aux PME, TPE et micro-entreprises.
L'échange ne se fait pas par courriel. Il se fait par une plateforme agréée, terme désormais retenu par l'administration fiscale pour les plateformes que l'on appelait PDP, immatriculées par l'État et publiées sur impots.gouv.fr. Trois formats structurés sont dans le périmètre : Factur-X, UBL et CII. Les plateformes assurent la conversion entre eux, ce qui explique que votre client puisse recevoir une facture dans un format que vous ne produisez pas.
L'effet sur le PDF que vous envoyez depuis des années est plus subtil qu'il n'y paraît. Le PDF ne disparaît pas. Il cesse d'être la facture.
Factur-X, ou la facture cachée dans le PDF
Factur-X est le format que rencontreront la plupart des petits fournisseurs français, parce qu'il ressemble à ce qu'ils envoient déjà. Un fichier Factur-X est un PDF/A-3 auquel est attaché, dans le conteneur, un fichier XML toujours nommé factur-x.xml. La page, c'est la facture lisible par un humain. Le XML porte la même facture sous forme de données, en syntaxe CII, selon la sémantique de la norme européenne EN 16931.
C'est un objet franco-allemand. La FNFE-MPE le publie en France, le FeRD publie en Allemagne le ZUGFeRD techniquement identique, et un même fichier satisfait les deux. Il existe en profils de richesse croissante, de MINIMUM à EXTENDED, le profil EN 16931, souvent appelé COMFORT, correspondant exactement à la norme européenne.
Ce qu'il faut en retenir quand on met une facture en page : deux représentations d'un même document voyagent ensemble, et c'est l'émetteur qui répond de leur cohérence. Toute information présente dans le fichier de données structurées doit être présente et conforme dans la représentation lisible. En cas de divergence sur les montants ou les données fiscales, c'est la donnée structurée qui gouverne le traitement automatisé.
Le code est dans l'image, et l'image n'est pas la donnée
Un QR code posé sur la page est un objet graphique de la couche PDF. Rien dans le XML ne le décrit, ne le référence, ni ne soupçonne son existence. Le logiciel de votre client importe le XML, comptabilise la facture, met le règlement en file d'attente, et n'affiche jamais la page. Ce que dit votre code n'atteint donc qu'un seul public : la personne qui ouvre le PDF et approche son téléphone de l'écran.
Ce n'est pas une raison d'y renoncer. C'est une raison d'être honnête sur sa fonction. Les instructions de règlement disposent déjà de leurs propres champs dans la donnée structurée : le compte à créditer, l'échéance, la référence à rappeler. Ce sont ces champs que lit une campagne de règlement. Un code qui les répète est un confort offert à un humain. Un code qui les contredit est une incohérence que vous avez fabriquée vous-même, sur un document que vous devez conserver six ans au titre de l'article L. 102 B du livre des procédures fiscales et dix ans au titre de l'article L. 123-22 du code de commerce.
Les quatre mentions ajoutées par la réforme
Autant les traiter pendant que la maquette est ouverte, car la page lisible doit les porter aussi :
- Le SIREN du client, pour les opérations domestiques entre assujettis établis en France.
- L'adresse de livraison, lorsque le lieu de livraison du bien diffère de l'adresse de facturation.
- La nature de l'opération : livraison de biens, prestation de services, ou opération mixte.
- L'option pour le paiement de la TVA sur les débits, lorsqu'un prestataire l'a exercée, sur chaque facture émise.
Elles s'ajoutent aux mentions que la facture française portait déjà. La sanction d'une mention manquante ou inexacte reste l'amende de l'article 1737 du code général des impôts, appliquée par mention et plafonnée en proportion du montant de la facture. Personne n'a jamais été sanctionné pour l'absence d'un QR code. C'est l'une de ces quatre mentions qui coûte cher, et c'est par là qu'il faut commencer.
À quoi sert alors le code ?
Les usages qui conviennent à la couche lisible, à peu près par ordre de pertinence :
- Ouvrir la fiche de cette facture dans votre portail client. Un scan, le document, son statut, son historique, l'interlocuteur qui en répond.
- Ouvrir une page de paiement. Utile si vous acceptez la carte ou un virement initié depuis une page hébergée, ce qui n'est pas le même mécanisme qu'un virement lancé depuis l'application bancaire du client.
- Ouvrir la voie de réclamation. Sur une facture contestée, la zone la plus photographiée est celle qui indique qui appeler.
- Ouvrir le bon de livraison ou le relevé d'heures derrière les lignes. Un lien vers la pièce justificative remplace trois courriels par un scan.
Ce qui ne convient pas : tout ce que le XML transporte déjà et que la chaîne de règlement traitera de toute façon.
Le code de paiement européen, et pourquoi la France n'est pas la Suisse
Il existe bien une norme pour encoder un virement dans un code. L'European Payments Council publie l'EPC069-12, qui définit la charge utile : un identifiant de service, une version, le nom du bénéficiaire, l'IBAN, un montant en euros et une référence de règlement. Scanné dans une application bancaire qui l'implémente, l'écran de virement arrive prérempli.
Le problème est l'adoption, et elle est géographique. Les pays où l'usage est banal se concentrent dans l'aire germanophone, au Benelux, en Scandinavie et dans les pays baltes, où les applications bancaires portent la fonction depuis des années et où les factures sont composées en supposant qu'elle sera utilisée. Les applications bancaires françaises ne l'ont pas généralisée de la même façon. Notre article sur le code EPC et le Girocode allemand détaille la charge utile. Avant d'imprimer cela sur une maquette française, ouvrez l'application de votre propre banque, puis demandez à vos trois plus gros clients de tenter l'essai chez eux. Si le scan ne produit rien, le code n'est plus qu'un ornement qui génère des appels à votre comptabilité.
Règles pratiques pour le code lui-même
Une facture est un document archivé : traitez le code comme un objet qui sera scanné longtemps après que vous l'aurez oublié.
- Rendez-le modifiable. Une destination que vous pouvez réorienter survit à un changement de portail. Une URL figée dans un PDF de 2026 n'y survit pas, et ce PDF sera encore dans l'archive de votre client en 2032.
- Imprimez la destination en clair à côté. Une ligne de texte, et c'est la seule version qui fonctionne quand le code échoue ou que le lecteur refuse.
- Ne le rétrécissez pas pour le faire entrer. Les factures sont imprimées, photocopiées, renumérisées en mauvaise qualité. Dimensionnez-le pour la distance de lecture et laissez sa zone de silence libre du filet de tableau contre lequel vous étiez tenté de le coller.
- Validez le fichier ensuite. Ajouter un graphique dans un conteneur PDF/A-3 peut casser la conformité qu'attend votre plateforme. Passez le résultat dans un validateur plutôt que de faire confiance à l'export.
La répartition des rôles est tout le sujet. Le XML s'adresse à une machine qui ne regardera jamais votre page. Le code s'adresse à une personne qui n'ouvrira jamais votre XML. Écrivez chacun pour son propre lecteur.
