Comparer le PDF et le XML d'une facture électronique : pourquoi regarder le PDF ne suffit pas

Termes métier

BT-112 Invoice total amount with VAT BT-115 Amount due for payment BT-84 Payment account identifier BT-109 Invoice total amount without VAT BT-110 Invoice total VAT amount BT-1 Invoice number

Exemples de code

VB.NET

Publié le

2026-11-12

Une facture ZUGFeRD comporte deux parties : le PDF que lisent les personnes et le XML intégré que traitent les logiciels. Juridiquement, c'est le XML qui compte. Dans beaucoup d'entreprises, on contrôle et on valide pourtant ce qu'affiche le PDF. Personne ne s'assure que les deux parties disent la même chose.

En bref : dans une facture électronique hybride, la partie structurée – le XML – fait foi. Si le PDF visible s'en écarte, la personne qui valide voit un autre montant ou d'autres coordonnées bancaires que ceux traités par le logiciel comptable. Il peut s'agir d'une erreur ou d'une tentative de fraude. À partir de la version 11.0.0.19, le SDK Aloaha ZUGFeRD vérifie en un seul appel, CheckPDFTextAgainstXML, si le montant de la facture, le montant à payer, le numéro de facture et l'IBAN du XML sont aussi imprimés sur les pages du PDF.

Pourquoi c'est important

Selon la lettre du ministère fédéral allemand des Finances du 15 octobre 2024 (point 31), les données de facture du XML constituent la partie déterminante d'un format hybride comme ZUGFeRD. Si le PDF et le XML divergent, les données du XML priment. Si le PDF présente d'autres mentions, il peut être considéré comme une facture supplémentaire, pour laquelle l'article 14c de la loi allemande sur la TVA doit être examiné ; la déduction de la TVA n'est possible que sur la base de la partie structurée (point 32). Le PDF n'est donc qu'une représentation pour l'œil humain.

En pratique, c'est souvent l'inverse : la facture arrive par e-mail, quelqu'un ouvre le PDF, vérifie le montant et le fournisseur, puis valide. Le logiciel lit ensuite le XML et paie ce qui y figure. Aucun contrôle n'existe entre ces deux étapes.

Une validation formelle selon l'EN 16931 ne détecte pas ces cas : le XML peut être parfaitement valide en soi. Il ne correspond simplement pas au PDF.

Le contrôle : CheckPDFTextAgainstXML

La fonction lit le XML intégré et le texte des pages du PDF, puis recherche les valeurs clés du XML dans le texte imprimé. Les montants sont reconnus dans toutes les notations usuelles (1.234,56 – 1,234.56 – 1234,56 – 1 234,56).

' VB.NET
Dim key As String = "VOTRE-CLE-DE-LICENCE"
Dim alo As New Aloaha_ZUGFeRD.XML(key)

Select Case alo.CheckPDFTextAgainstXML("C:\Reception\FA-4711.pdf", key)
    Case 1
        ' concordance : poursuivre le traitement
    Case 2
        ' avertissement : soumettre le rapport à une personne
        System.IO.File.WriteAllText("C:\Clarifier\FA-4711.txt", alo.PDFTextCheckReport)
    Case 0
        ' écart : bloquer le paiement, contacter le fournisseur
        System.IO.File.WriteAllText("C:\Bloque\FA-4711.txt", alo.PDFTextCheckReport)
    Case Else
        ' non vérifiable : la raison figure dans PDFTextCheckReport ou LastError
End Select

Le rapport de PDFTextCheckReport indique chaque valeur comparée sur une ligne (texte en anglais) :

PDF text check: WARNING - the payable amount is printed, but 1 other value(s) of the XML differ from the PDF.
OK       BT-112 grand total 1190.00: printed as 1.190,00
OK       BT-109 net total 1000.00: printed as 1.000,00
OK       BT-110 VAT total 190.00: printed as 190,00
OK       BT-1 invoice number RE-1001: printed
WARNING  BT-84 IBAN DE02120300000000202051: not printed - the PDF prints another IBAN: DE89370400440532013000
Rough check only: a value counts as printed when it appears anywhere in the page text.

Le contrôle s'exécute en local. La facture ne quitte pas l'entreprise.

Sans programmation : dans la GUI et la visionneuse PDF

À partir de la version 11.0.0.19, le même contrôle est intégré à nos programmes. Dans l'Aloaha ZUGFeRD GUI, il s'exécute pour chaque PDF avec Validate e-invoice…, et après la fusion du XML et du PDF, la GUI avertit si les deux ne vont pas ensemble. L'Aloaha ZUGFeRD PDF Viewer affiche le résultat sous forme de mention colorée dans la barre d'outils à l'ouverture d'un PDF ZUGFeRD.

Ce qu'a montré le test sur des factures réelles

Avant la publication, nous avons testé la logique de comparaison sur 15 factures ZUGFeRD réelles issues de notre support :

• 12 factures : résultat 1, le montant et le numéro de facture figurent sur le PDF.
• 2 factures : résultat 2. Pour l'une, le PDF imprime deux autres comptes bancaires que le XML ; pour l'autre, le numéro de facture manque dans le texte.
• 1 facture : résultat 0. Le XML provenait d'un exemple, le PDF était une vraie facture – aucun montant ne concordait.

Trois fichiers sur quinze méritaient donc un second regard, et aucun n'aurait été remarqué par une simple validation de format.

Ce que le contrôle ne fait pas

• C'est un contrôle sommaire. Une valeur est considérée comme imprimée si elle apparaît n'importe où dans le texte de la page – pas forcément à côté du mot « total ».
• Les PDF scannés sans texte ne sont pas vérifiables (résultat -1). Ce n'est pas un indice de fraude.
• Coordonnées bancaires en image dans l'en-tête : le contrôle ne trouve alors aucun IBAN et ne donne qu'une remarque.
• Il ne remplace ni la validation de format ni le rapprochement avec vos données de base. Seule votre comptabilité sait si l'IBAN appartient au fournisseur.

Déroulement recommandé à la réception

1. Valider le format : ValidateInvoicePDF – la facture est-elle valide selon l'EN 16931 ?
2. Comparer PDF et XML : CheckPDFTextAgainstXML – le PDF dit-il la même chose que le XML ?
3. Lire les données : FillZUGFeRD_Structure – reprendre montants, numéro de TVA et IBAN depuis le XML.
4. Comparer avec les données de base : le numéro de TVA et l'IBAN correspondent-ils au fournisseur connu ? Voir facture d'un nouvel expéditeur : authentique ou hameçonnage ? (en allemand)

Termes métier dans cet article : BT-112 BT-115 BT-84 BT-109 BT-110 BT-1