Quelle valeur prime quand
l'XML de facture ZATCA et le PDF divergent

Une facture ZATCA, ce sont deux enregistrements dans un seul conteneur

Le XML signé est la facture ; le PDF/A-3 est un rendu autorisé à le transporter. ZATCA, la Zakat, Tax and Customs Authority, exige que chaque facture de Phase 2 soit générée et stockée sous forme de XML ZATCA UBL 2.1, ou de fichier PDF/A-3 avec ce XML intégré. Le XML est l'objet qui est signé, puis soit validé par ZATCA avant qu'une facture standard n'atteigne l'acheteur, soit déclaré dans les 24 heures pour une facture simplifiée. Le PDF est la copie lisible par l'humain.

Les ZATCA Detailed Guidelines for E-Invoicing répondent directement à la question courante : si un contribuable souhaite envoyer un PDF, le PDF/A-3 avec XML intégré est obligatoire. En Phase 2, un PDF simple, un fichier Word ou un scan n'est pas du tout une facture électronique conforme. La copie lisible par l'humain doit également être en arabe, toute langue supplémentaire étant autorisée en parallèle. C'est pourquoi le même nom de fournisseur peut apparaître deux fois, une fois en arabe et une fois en anglais, et pourquoi les deux versions ne sont pas interchangeables dans une règle de rapprochement.

UBL 2.1 est la norme XML OASIS qui sous-tend le format. Ses éléments se répartissent en deux familles : cbc pour les valeurs telles que ID, IssueDate et TaxAmount, et cac pour les conteneurs tels que AccountingSupplierParty et InvoiceLine. Les préfixes familiers sont des alias. Un fournisseur peut utiliser différents noms de préfixe pour le même espace de noms, un analyseur doit donc résoudre les espaces de noms plutôt que de faire correspondre la chaîne cbc:. La ZATCA XML Implementation Standard ajoute les règles saoudiennes par-dessus UBL et EN 16931.

PDF/A-3 est une variante de PDF d'archivage qui autorise les fichiers intégrés. Une facture hybride est une page d'apparence normale accompagnée d'une pièce jointe. La pièce jointe est ce que vous analysez ; la page est ce qu'une personne lit. Le code QR est un troisième enregistrement, plus petit : une chaîne Base64 d'enregistrements tag-longueur-valeur, jusqu'à 500 caractères. Les tag 1 à 5 portent le nom du vendeur, le numéro de TVA du vendeur, l'horodatage, le total TVA incluse et le total de TVA ; les tag 6 à 9 portent le hash, la signature, la clé publique et, sur les factures simplifiées, la signature de ZATCA sur cette clé. Le programme de facturation électronique de ZATCA s'appelle Fatoora (فاتورة).

Ce qui arrive réellement dans une boîte de réception comptabilité fournisseurs

L'extension ne vous dit presque rien ; la collection de pièces jointes vous indique ce que vous pouvez analyser. L'ERP d'un fournisseur peut produire un hybride correct et l'acheteur peut tout de même recevoir un PDF aplati. Les portails d'approvisionnement re-rendent les pièces jointes, les passerelles de messagerie les suppriment, et les agents comptables impriment en PDF avant d'archiver. La facture dans la boîte de réception peut sembler parfaite et être structurellement vide. Le rapport annuel 2025 de ZATCA situe le volume de factures électroniques de l'année au-dessus de 8 milliards, donc une boîte de réception mixte n'est pas un cas isolé. Les quatre états ci-dessous nécessitent un traitement différent.

L'inverse se produit aussi. Le forum des développeurs de ZATCA contient un fil d'un fournisseur demandant si des valeurs peuvent être fournies sous forme d'image sur un PDF/A-3. Le fichier déclare la conformité, mais les caractères ne peuvent être ni sélectionnés ni copiés car il n'y a pas de polices, seulement des pixels. Dans ce cas, le XML intégré est la seule couche lisible par machine, et l'OCR devient un recours plutôt qu'une option par défaut. Le fil du forum rappelle utilement que « PDF/A-3 » décrit le conteneur, pas la lisibilité de la page.

Vérifiez la pièce jointe, pas le nom du fichier. Ouvrez le panneau des pièces jointes dans un lecteur PDF, ou inspectez l'entrée /AF, extrayez le fichier vers un dossier de travail contrôlé, confirmez qu'il s'analyse comme XML, et laissez les octets d'origine intacts. Si la pièce jointe est manquante, corrompue ou inaccessible, enregistrez cette condition avant d'utiliser la page. Les quatre états ci-dessus ne sont pas équivalents, et traiter une page observée comme une charge utile analysée est le premier endroit où une exception comptable se perd.

Les champs qui déterminent le paiement

La comptabilité fournisseurs a besoin d'une douzaine de champs d'en-tête et de cinq par ligne, et le XML nomme chacun d'eux. Une fois l'artefact trié, la liste des champs est la même, que les valeurs proviennent d'un parseur ou d'une page. Le tableau est une carte de travail, pas le dictionnaire de données complet. Il conserve les champs qui modifient un paiement, une écriture fiscale ou un contrôle de doublon, et laisse de côté ceux qui n'importent qu'à la validation du vendeur. Les chemins sont relatifs à la racine Invoice.

Deux règles rendent cette carte exploitable. Extrayez LineExtensionAmount et PayableAmount dans leurs propres colonnes, même si vous extrayez aussi la quantité et le prix. Recalculer une valeur déjà indiquée dans le document, c'est ainsi que la comptabilité fournisseurs crée un écart qui n'existe pas. Conservez également la chaîne brute à côté de la valeur normalisée. Un numéro de facture avec un zéro initial, une raison sociale arabe et un horodatage en Arabia Standard Time perdent tous de l'information lorsqu'ils sont convertis trop tôt. Les noms arabes peuvent aussi s'afficher dans un ordre visuel différent même lorsque les caractères sont corrects : conservez donc la chaîne brute et définissez le sens d'affichage au lieu de ressaisir la valeur. Si la distinction entre en-tête et ligne est nouvelle pour vous, le guide complet de l'extraction des données de facture couvre le modèle général.

Là où les deux couches divergent réellement

La plupart des divergences ne sont pas des corruptions. Ce sont deux rendus corrects de champs différents. Les cinq cas ci-dessous expliquent la majorité des exceptions de la comptabilité fournisseurs qui ressemblent à des erreurs de données mais sont en réalité des erreurs de mappage.

Une remise de ligne modifie le net de ligne, pas le prix unitaire

La norme d'implémentation de ZATCA définit le net de ligne comme ((prix net de l'article ÷ quantité de base) × quantité facturée) moins la remise de ligne plus les frais de ligne. Une ligne de 10 unités à 100 SAR avec une remise de ligne de 50 SAR a un net de ligne de 950 SAR, tandis que le prix unitaire imprimé reste de 100 SAR. Si le PDF affiche le prix unitaire et le total de ligne mais pas la remise, la page semble arithmétiquement fausse. Elle ne l'est pas. La remise figure dans le XML, à l'intérieur de cac:InvoiceLine/cac:AllowanceCharge.

Si la comptabilité fournisseurs extrait la quantité et le prix unitaire et calcule un total de ligne, elle obtient 1 000 SAR face à un document qui indique 950 SAR. La facture échoue alors à un contrôle qu'elle aurait dû passer, ou un agent ajuste le mauvais champ pour équilibrer. Extrayez le net de ligne déclaré et conservez la remise dans sa propre colonne afin que l'arithmétique puisse être reproduite ultérieurement.

Une colonne calculée est utile pour vérifier. Elle ne remplace pas le net de ligne déclaré par le document.

Un prépaiement scinde le total en deux nombres

L'exemple de prépaiement de ZATCA illustre le schéma : 230 SAR TTC, 104 SAR déjà prépayés, 126 SAR à payer. TaxInclusiveAmount vaut 230, PrepaidAmount vaut 104, PayableAmount vaut 126. Les trois sont corrects, et chacun répond à une question différente. Mappez le montant dû à PayableAmount, la valeur de la facture à TaxInclusiveAmount, et l'acompte à sa propre colonne. Si l'ERP ne dispose que d'un seul champ de total, placez-y la valeur de la facture et reportez le montant à payer dans l'échéancier de paiement. Écraser l'un par l'autre masque l'acompte et le paie deux fois.

Une facture en devise étrangère comporte deux totaux de taxe

Lorsque la devise du document n'est pas le SAR, ZATCA exige que TaxCurrencyCode soit SAR et qu'un second total de taxe soit exprimé en SAR. Le PDF n'imprime souvent que la devise du document. Une équipe comptabilité fournisseurs qui convertit le total imprimé à un taux de fin de mois obtiendra un montant de TVA en SAR différent de celui du XML, et l'écart atterrit dans le compte de récupération de TVA. Lisez les deux totaux de taxe, comptabilisez celui en SAR et conservez celui en devise du document pour le grand livre fournisseur.

Le PDF peut contenir des champs que le XML n'est pas tenu d'inclure

La norme ZATCA est un minimum. Sur le forum des développeurs Fatoora, un fournisseur a demandé si les informations supplémentaires imprimées sur le PDF/A-3 devaient figurer dans le XML. La réponse était que les champs hors du dictionnaire de données ne sont pas exigés dans le XML, bien qu'ils puissent être ajoutés s'ils sont conformes à UBL. C'est là que se trouvent souvent les numéros de bon de commande, les références de bon de livraison, les centres de coûts internes et les tampons d'approbation. Ils sont sur la page, pas dans la charge utile.

Pour un pipeline purement XML, c'est une lacune. Le rapprochement à trois voies nécessite le bon de commande, et la planification des paiements nécessite la date d'échéance. Le XML contient cac:OrderReference et cac:PaymentTerms, mais un fournisseur n'est pas obligé de les renseigner sur chaque facture. La conception pratique est une colonne source au niveau du champ : la fiscalité et l'identité depuis le XML, le contexte opérationnel depuis la page, et un état explicite « non présent » lorsque ni l'un ni l'autre ne le fournit.

Un avoir est un nouveau document, pas une facture négative

Un avoir utilise le code de type de facture 381, porte une référence de facturation à la facture qu'il corrige, indique un motif et conserve généralement des montants positifs car le type de document porte le sens. Saisissez-le comme une facture d'achat négative et le signe peut être inversé deux fois : une fois par le type, une fois par votre écriture. Le résultat est un avoir qui augmente le solde.

Compensez l'avoir avec la facture référencée et vérifiez que la référence est résolue. Les lignes directrices ZATCA permettent à un avoir de référencer plusieurs factures d'origine sous forme de plage textuelle, la référence n'est donc pas toujours une clé unique. Lorsqu'il s'agit d'une plage, répartissez l'avoir ou attendez que le fournisseur fournisse une ventilation par facture.

Le tableau ci-dessous transforme les cas courants en feuille de routage.

Le code QR est un contrôle de cohérence, pas un certificat de validation

Faire correspondre un QR à la page prouve que les deux ont été construits à partir des mêmes valeurs ; cela ne prouve pas que la facture a été validée. Les tags 1 à 5 sont les seules valeurs commerciales du code. Il n'y a pas de numéro de facture, pas de ligne d'article, pas de bon de commande et pas de numéro de TVA de l'acheteur. Un QR est un résumé, et un résumé court.

Utilisés comme contrôle à la réception, les tags 1 à 5 restent utiles. Normalisez avant de comparer : le numéro de TVA en chiffres, l'horodatage comme un instant, car Arabia Standard Time et UTC peuvent décrire le même moment, et les montants à deux décimales. Une divergence signifie généralement que le QR appartient à une autre facture, ou que la page a été reconstruite après la génération du code. Dans les deux cas, il vaut la peine de s'arrêter.

Les tags 6 à 9 ne peuvent pas être vérifiés à l'œil nu ni par un scanner de téléphone. Leur vérification nécessite le XML signé, la forme exacte au niveau de l'octet sur laquelle la signature a été calculée, la chaîne de certificats et une vérification de révocation. Un scan qui affiche neuf champs a affiché neuf champs. Il n'a pas vérifié la signature.

Les équipes AP reçoivent des informations contradictoires à ce sujet. Sur le forum des développeurs Fatoora, un praticien AP a écrit : « L'équipe d'assistance ZATCA dit qu'il est obligatoire de scanner les codes QR des factures fournisseurs. Je pose ma question du point de vue des comptes fournisseurs. » La réponse du responsable de la communauté était que le scan est un contrôle facultatif, et qu'une facture qui a été transmise ou validée avec succès satisfait déjà aux exigences de facturation électronique. Le même fil indique que l'application ZATCA ne peut pas scanner les codes en dehors de l'Arabie saoudite, ce qui pose un problème pratique pour un centre de services partagés situé dans un autre pays.

La position praticable : utilisez le QR comme contrôle par échantillonnage et comme vérification de l'intégrité des pièces jointes. N'en faites pas un passage obligé pour chaque facture, et ne considérez pas un scan comme une preuve de validation. La preuve, c'est le XML validé ou transmis, conservé avec sa réponse.

Un QR copié peut figurer sur une page manipulée. Comparez les valeurs ; ne traitez pas le carré comme une preuve.

Un flux de travail en six étapes qui résiste aux exceptions

Le flux de traitement des factures fournisseurs électroniques saoudiennes doit produire une ligne par ligne de facture, un libellé de source pour chaque champ et un état d'exception que personne ne peut écraser discrètement. Les étapes sont volontairement banales. C'est cette banalité qui rend le résultat défendable six ans plus tard.

Trois propriétaires, trois questions. Le commis aux comptes fournisseurs est responsable de la correspondance commerciale et de la requête fournisseur. Le responsable de l'ERP ou de l'intégration est responsable de la pièce jointe, de l'espace de noms et de l'analyseur. Le responsable fiscal saoudien est responsable de la catégorie de TVA, de la preuve de dédouanement et de la décision de conservation. Un seul indicateur « valide » fusionne ces réponses en une seule et masque l'équipe qui doit agir. Stockez les états séparément : analysé, échec de schéma, valeurs divergentes, preuve cryptographique non vérifiée, blocage comptes fournisseurs, approuvé pour paiement.

Ce que l'extraction visuelle peut et ne peut pas faire ici

Un outil d'extraction visuelle lit la page, pas la pièce jointe, il appartient donc au côté PDF de ce flux de travail. C'est la partie que couvre ImageToTable.ai, et c'est un rôle plus restreint que « l'extraction de factures ZATCA ». Il reste utile à trois endroits.

Le premier est le champ qui n'existe que sur le PDF. Lorsque l'ERP analyse le XML, la page peut encore être le seul endroit où apparaissent le numéro de bon de commande, le bon de livraison ou l'approbation interne. Custom Column Extraction vous permet de saisir les noms de colonnes souhaités, tels que « PO Number », « Payment Due Date » et « Delivery Note », et le modèle trouve les valeurs par le sens plutôt que par des coordonnées fixes. Les noms de colonnes que vous saisissez deviennent les en-têtes du tableau de sortie.

Le deuxième est l'exception sans XML. Lorsqu'un fournisseur envoie un PDF simple ou un PDF/A-3 composé uniquement d'images, il n'y a rien à analyser. La page devient la source. Le traitement par lots gère un dossier de mises en page fournisseurs mixtes en une seule passe et fusionne les lignes en une seule feuille de calcul, ce qui fait la différence entre une file d'exceptions exploitable et une pile de conversions ponctuelles.

Le troisième est la comparaison visuelle. Review Mode avec mise en évidence Bbox vous permet de survoler une cellule et de voir la région sur la page d'origine qui l'a produite, et de cliquer sur une région pour revenir à la cellule. Pour une facture ZATCA, c'est ainsi qu'un commis compare le montant payable imprimé avec la valeur XML sans imprimer la page et utiliser une règle. La valeur d'origine de l'IA est conservée et peut être restaurée si une modification était erronée. Pour les numérisations uniquement d'images et les mises en page bilingues denses, un Model Tier plus élevé utilise un modèle de vision plus puissant. Le niveau standard couvre la plupart des tableaux imprimés ; le cas difficile est une impression numérisée avec un petit texte arabe et un tampon sur le total.

Les limites comptent tout autant. Il n'ouvre pas le XML intégré, ne valide pas le tampon cryptographique, ne vérifie pas le hachage du code QR, n'intègre pas un fournisseur à ZATCA et ne dépose rien. Une extraction visuelle d'un PDF/A-3 est une observation de la page rendue, pas une analyse de la charge utile signée. Étiquetez-la comme telle dans la sortie. Si la page omet une ligne de remise, l'observation l'omettra aussi, et c'est la vérification arithmétique de l'étape 4 qui détecte la différence.

La même distinction s'applique à d'autres marchés. Le système de factures qualifiées du Japon n'a pas de charge utile XML obligatoire, la couche visuelle est donc souvent la seule source, c'est pourquoi la même discipline s'applique aux factures qualifiées japonaises. Le mandat allemand fait du fichier structuré la facture, ce qui modifie l'ordre de réception pour les factures fournisseurs allemandes. Une équipe qui gère les deux a besoin d'une carte de champs et de deux règles de réception.

L'archive fait partie de l'extraction

Le tableur n'est pas la facture, et un PDF seul ne constitue pas l'enregistrement qu'un auditeur peut valider. L'article 66 du Règlement d'application de la TVA saoudien exige que les factures, livres, registres et documents comptables soient conservés pendant au moins six ans à compter de la fin de la période fiscale à laquelle ils se rapportent. Les registres d'actifs immobilisés couvrent la période d'ajustement de l'article 52 plus cinq ans, soit 11 ans pour les biens mobiliers et 15 ans pour les biens immobiliers. Les registres doivent être en arabe et conservés dans le Royaume, sous forme électronique ou physique, avec un accès depuis un terminal situé dans le Royaume.

Conservez le XML reçu, ou le conteneur PDF/A-3 intact, plutôt qu'une simple copie extraite de la pièce jointe. Conservez la réponse de validation ou de déclaration pour les factures standard, car c'est la preuve que la facture a été acceptée. Conservez le compteur de factures et la chaîne de hachage précédente intacts ; une lacune constitue en soi une preuve. Conservez les avoirs avec les factures qu'ils corrigent, la modification étant interdite.

L'enregistrement d'extraction possède ses propres champs : hachage du fichier source, type de source, version de l'analyseur ou du modèle, version du jeu de règles, source au niveau du champ, valeur normalisée, valeur brute et état d'exception. Réexécuter un analyseur ou un modèle ultérieurement nécessite les mêmes octets. Si vous écrasez l'original par une valeur normalisée, vous avez détruit la preuve dont vous auriez besoin pour défendre la ligne.

D'autres modèles de validation vont dans le même sens. Le système KSeF polonais attribue un identifiant sans lequel la facture n'existe pas légalement, et les factures CFDI mexicaines associent un fichier structuré à une représentation imprimable. Dans chaque cas, l'archive est l'artefact structuré plus la réponse de l'autorité, et non le PDF.

Questions fréquentes

Puis-je extraire les lignes d'un code QR ZATCA ?

Non. Les tags 1 à 5 contiennent le nom du vendeur, son numéro de TVA, l'horodatage, le total TVA incluse et le total de TVA. Il n'y a ni numéro de facture, ni identifiant d'acheteur, ni détail des lignes. Utilisez le code pour recouper ces cinq valeurs, pas pour construire un tableau de lignes.

Toute facture PDF/A-3 est-elle un hybride contenant du XML ?

Non. Le PDF/A-3 est un conteneur qui autorise les fichiers intégrés ; il ne garantit pas que le fournisseur en ait ajouté un, que la pièce jointe soit lisible ou que la page ait été générée à partir de celle-ci. Ouvrez la collection de pièces jointes et analysez le fichier avant de traiter le PDF comme une source structurée.

Quel total comptabiliser lorsqu'une facture comporte un prépaiement ?

Comptabilisez la valeur de la facture à partir de TaxInclusiveAmount et payez le montant dû à partir de PayableAmount. Conservez PrepaidAmount dans sa propre colonne et rattachez-le à la facture de prépaiement. Ne fusionnez pas ces trois valeurs dans un seul champ « total » et n'écrasez pas la valeur de la facture avec le montant à payer.

Le PDF/A-3 est-il la facture légale ?

Non. Le XML signé est la facture. Le PDF/A-3 est la copie lisible par l'humain autorisée à le contenir. Pour une facture standard, conservez le XML validé ou l'hybride validé, et archivez le conteneur plutôt qu'un PDF réenregistré.

Puis-je utiliser l'OCR sur une facture ZATCA ?

Oui, lorsqu'il n'existe aucun XML exploitable. Un PDF composé uniquement d'images, un scan ou une photo peuvent être lus visuellement, mais le résultat est une observation de la page, non une analyse de la charge utile signée. Consignez la méthode, appliquez les mêmes contrôles de normalisation et d'arithmétique, et recoupez les cinq valeurs du code QR lorsqu'elles sont lisibles.

Comment traiter un avoir qui référence plusieurs factures ?

Traitez-le comme un nouveau document de type 381 avec une référence de facturation, et non comme une facture d'achat négative. Si la référence est une plage, répartissez l'avoir sur les factures d'origine ou attendez que le fournisseur fournisse un détail par facture. Imputez-le aux factures qu'il corrige et archivez-le avec elles.

ImageToTable.ai analyse-t-il le XML UBL intégré ou vérifie-t-il le code QR ?

Non. Il lit la page PDF, l'image ou le scan et extrait les colonnes que vous définissez, y compris les champs présents uniquement sur la page imprimée. Il n'ouvre pas la pièce jointe XML intégrée, ne valide pas le cachet cryptographique, ne vérifie pas le hachage du code QR, n'enregistre pas un fournisseur auprès de ZATCA et ne soumet pas de déclaration. L'analyse du XML et la vérification de la signature relèvent de votre ERP ou de votre couche d'intégration.

Combien de temps faut-il conserver une facture fournisseur saoudienne ?

Au moins six ans à compter de la fin de la période fiscale concernée, en vertu de l'Article 66 du Règlement d'application de la TVA. Les registres d'immobilisations courent sur la période d'ajustement plus cinq ans, soit 11 ans pour les biens mobiliers et 15 pour les biens immobiliers. Conservez ensemble le XML ou le conteneur PDF/A-3 intact, la preuve de validation ou de déclaration et les avoirs.

La ligne qui résiste à la question

La facture qui survit à un audit est celle où chaque ligne peut nommer le champ dont elle provient, l'artefact qui la sous-tend et le contrôle qui l'a validée. Une fois cette cartographie établie, l'écart entre le PDF et le XML cesse d'être un mystère et devient une file d'attente avec un responsable.