Validateur de factures ZATCA phase 2
Collez ou importez le XML d’une facture électronique saoudienne et voyez ce que la ZATCA rejetterait probablement : règles BR-KSA, numéro de TVA, totaux, QR code et hash de la facture, avec le chemin du champ et la correction pour chaque erreur.
Outil
Fonctionne dans votre navigateur. Le fichier n’est jamais envoyé.
Cet outil comparé au SDK officiel et au Developer Portal de la ZATCA
Utilisez cette page pour une pré-vérification rapide pendant le développement ou le débogage. Pour la vérification de référence avant l’onboarding, utilisez les outils de la ZATCA.
| Ce validateur (Kodenova) | ZATCA Compliance and Enablement Toolbox SDK | |
|---|---|---|
| Ce qui est vérifié | Structure UBL 2.1, règles métier BR-KSA, numéros de TVA, totaux et arrondis, QR code et hash de la facture selon BR-KSA-27. La signature ECDSA et la chaîne de certificats ne sont pas vérifiées. | Selon la ZATCA, le SDK vérifie que les factures électroniques, avoirs et notes de débit générés sont conformes à la réglementation sur la facturation électronique. |
| Où il s’exécute | Dans votre navigateur. Le XML n’est envoyé nulle part. | Téléchargé sur zatca.gov.sa et exécuté sur votre propre machine, avec un manuel d’utilisation. |
| Quand l’utiliser | Pour vérifier rapidement des fichiers XML un par un pendant que vous mappez les champs dans SAP Business One ou votre ERP. | L’étape de vérification officielle avant l’onboarding. La ZATCA précise que réussir ce test ne signifie pas qu’elle a approuvé les factures. |
Source : ZATCA, Compliance and Enablement Toolbox: Download SDK. La ZATCA propose aussi aux développeurs de systèmes un E-Invoicing Developer Portal. Vérifié en octobre 2026.
Erreurs fréquentes et comment les corriger
Dix causes de rejet tirées directement des règles du ZATCA XML Implementation Standard v1.2, chacune avec sa correction.
| Règle | Ce qui ne va pas | Comment corriger |
|---|---|---|
| BR-KSA-40 | Le numéro de TVA du vendeur ne compte pas 15 chiffres ou ne commence pas et ne se termine pas par 3. | Reprenez le numéro de TVA exactement comme sur le certificat d’immatriculation, sans espaces. |
| BR-KSA-27 | Le XML a été modifié, réindenté ou réenregistré après la signature ; le hash ne correspond plus au digest signé ni au QR code. | Signez le XML définitif et envoyez-le octet pour octet, sans modification. Ne changez plus rien après la signature. |
| BR-KSA-26 / 61 | Le hash de la facture précédente (PIH) manque ou n’est pas le hash de la facture précédente de la même unité EGS. | Enregistrez le hash de chaque facture envoyée et utilisez-le comme PIH de la suivante. |
| BR-KSA-33 / 34 | Le compteur de factures (ICV) manque, n’est pas numérique ou a été remis à zéro. | Tenez un compteur continu par unité EGS et n’utilisez jamais deux fois la même valeur. |
| BR-KSA-37 / 66 | Le numéro de bâtiment du vendeur ne compte pas 4 chiffres ou le code postal ne compte pas 5 chiffres. | Renseignez les champs de l’adresse nationale saoudienne dans les données de la société. |
| BR-KSA-63 | Facture standard adressée à un acheteur saoudien sans adresse complète (rue, bâtiment, code postal, ville, quartier). | Complétez l’adresse nationale du partenaire avant de facturer. |
| BR-KSA-06 | InvoiceTypeCode/@name n’est pas un code de transaction à 7 chiffres comme 0100000 ou 0200000. | Associez le bon code à chaque type de document et n’activez que les indicateurs applicables. |
| BR-KSA-68 | TaxCurrencyCode manque, ou il n’y a pas de TaxTotal avec la TVA en SAR. | Envoyez toujours TaxCurrencyCode SAR et un TaxTotal qui contient uniquement le montant de TVA en SAR. |
| BR-KSA-23 / 24 / 69 | Lignes au taux zéro, exonérées ou hors champ sans code d’exonération VATEX-SA. | Ajoutez TaxExemptionReasonCode et TaxExemptionReason dans chaque ventilation des catégories Z, E ou O. |
| BR-KSA-51 / BR-CO-15 | Le montant TTC d’une ligne ou les totaux du document ne tombent pas juste après arrondi. | Arrondissez la TVA de chaque ligne à 2 décimales, puis additionnez les lignes pour obtenir les totaux de l’en-tête. |
Spécifications utilisées par cet outil
- ZATCA Electronic Invoice XML Implementation Standard v1.2 (règles BR-KSA, BR-DEC et BR-CO, hash selon BR-KSA-27)
https://zatca.gov.sa/ar/E-Invoicing/SystemsDevelopers/Documents/20230519_ZATCA_Electronic_Invoice_XML_Implementation_Standard_%20vF.pdf - OASIS UBL 2.1 Invoice Schema (UBL-Invoice-2.1.xsd)
https://docs.oasis-open.org/ubl/os-UBL-2.1/xsd/maindoc/UBL-Invoice-2.1.xsd - W3C Canonical XML 1.1 (C14N 1.1), utilisé pour le hash de la facture
https://www.w3.org/TR/xml-c14n11/
Des copies de ces fichiers sont conservées avec le code source de l’outil, avec leurs empreintes SHA-256. L’outil vérifie selon les spécifications publiées par la ZATCA ; il n’est ni certifié par la ZATCA ni un validateur officiel.
Trois étapes, sans inscription
Collez ou importez le XML
Utilisez le XML signé d’une facture standard (B2B), d’une facture simplifiée (B2C), d’un avoir ou d’une note de débit, ou chargez un exemple.
Lisez le rapport
Erreurs, avertissements et informations sont regroupés, chacun avec l’identifiant officiel de la règle (BR-KSA-…), le chemin XML et la correction à apporter.
Corrigez avant le rejet de la ZATCA
Corrigez le champ dans SAP Business One ou votre ERP, régénérez le XML et vérifiez à nouveau. Téléchargez le PDF pour votre équipe.
Questions sur cet outil
Que vérifie ce validateur ZATCA ?
La structure UBL 2.1 et les règles métier saoudiennes du ZATCA XML Implementation Standard v1.2 : type de facture et code de transaction (KSA-2), UUID, date et heure d’émission, compteur de factures (ICV) et hash de la facture précédente (PIH), numéros de TVA du vendeur et de l’acheteur, champs de l’adresse nationale, date de livraison, codes de motif d’exonération, TVA et arrondis par ligne, ventilations de TVA, totaux du document arrondis à 2 décimales, le QR code et le hash de la facture selon BR-KSA-27.
Comment le hash de la facture est-il calculé ?
Comme le décrit BR-KSA-27 : on retire ext:UBLExtensions, la cac:AdditionalDocumentReference dont l’ID est QR et cac:Signature, on canonise le reste avec C14N 1.1, on calcule le SHA-256 et on encode le résultat en Base64. L’outil compare cette valeur au digest de la signature et au tag 6 du QR code.
L’outil vérifie-t-il la signature cryptographique ?
Non. Il vérifie que le cachet est présent et formellement correct (SignedInfo, SignatureValue, certificat et Signed Properties) et que le digest signé correspond à la facture. La signature ECDSA et la chaîne de certificats ne sont pas vérifiées. Un résultat CONFORME ici n’est donc pas un résultat de clearance ou de reporting de la ZATCA.
Quelle différence entre une facture fiscale standard et une facture simplifiée ?
Le code de transaction dans InvoiceTypeCode/@name commence par 01 pour une facture fiscale standard (B2B), que la ZATCA valide en temps réel (clearance), et par 02 pour une facture simplifiée (B2C), qui doit porter le cachet cryptographique et le QR code et être déclarée sous 24 heures.
Est-ce un validateur officiel de la ZATCA ?
Non. C’est un outil indépendant ; Kodenova n’est pas liée à la ZATCA. La vérification se fait selon les spécifications publiées par la ZATCA. Le contrôle de conformité de référence reste le Compliance and Enablement Toolbox SDK de la ZATCA et son E-Invoicing Developer Portal ; la réponse définitive vient toujours de la plateforme Fatoora.
Ma facture est-elle envoyée quelque part ?
Non. Le XML est lu et vérifié par votre propre navigateur, et le rapport PDF y est aussi créé. Rien n’est envoyé à Kodenova ni à un tiers.
Conçus pour les équipes SAP Business One
La ZATCA phase 2 depuis SAP Business One ?
Nous connectons SAP B1 à la ZATCA : XML, chaîne de hash, signature, QR code, clearance et reporting, avec journaux et nouvelles tentatives. Prix fixe, devis généralement sous 24 heures.