ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

Arabie Saoudite — ZATCA et FATOORA

L'autorité ZATCA a déployé un mandat e-invoicing en deux temps : Phase 1 « Generation » en décembre 2021, puis Phase 2 « Integration » déployée par vagues depuis janvier 2023, avec un format UBL 2.1 enrichi, signature XAdES et QR code TLV obligatoires.

Timeline réglementaire

  • VAT Law Royal Decree M/113 du 28/05/1438 H (2017). Introduction de la TVA en Arabie Saoudite au 1er janvier 2018, puis portée à 15 % en juillet 2020.
  • ZATCA Resolution 0010 du 12 décembre 2020. Pose le cadre de la facturation électronique avec un déploiement en deux phases.
  • 4 décembre 2021. Mise en service de la Phase 1 Generation. Toutes les entreprises résidentes assujetties TVA doivent émettre des factures électroniques structurées avec QR code (UBL 2.1 ou XML PINT minimal).
  • ZATCA Resolution 2-7-3 du 24 mai 2022. Annonce la Phase 2 Integration avec FATOORA, déploiement par vagues à partir de janvier 2023.
  • 1er janvier 2023. Démarrage de la Phase 2 pour la Wave 1 : entreprises résidentes au chiffre d'affaires > 3 Md SAR sur 2021.
  • Avril 2023. Wave 2 (CA > 500 M SAR).
  • Vagues 3 à 19, 2023-2026. ZATCA publie chaque trimestre la vague suivante par seuil de chiffre d'affaires descendant (annonce typiquement 6 mois avant la mise en service).
  • Wave 19 (annoncée mi-2026). Élargissement aux contribuables résidents avec CA > 750 000 SAR sur 2024-2025.

Schéma technique

Le format est UBL 2.1 avec un SA Profile qui ajoute plusieurs blocs spécifiques :

  • InvoiceTypeCode codé sur deux dimensions : le code UN/CEFACT (388 pour facture standard, 381 pour avoir, etc.) et un attribut name à 7 chiffres qui encode 4 informations binaires (B2B/B2C, exportation, summary, etc.).
  • UUID, ICV (Invoice Counter Value) et PIH (Previous Invoice Hash) pour la chaîne d'intégrité — chaque facture est liée par hash à la précédente, formant une chaîne immuable.
  • Extension UBL portant la signature XAdES-EPES, le QR code TLV encodé en base64, et l'horodatage du cryptographic stamp.
  • PartyIdentification CRN (Commercial Registration Number) et PartyTaxScheme CompanyID au format saoudien (15 chiffres commençant par 3).

Exemple minimal d'une facture B2B Phase 2 ZATCA (signature et QR omis pour la lisibilité) :

xmlzatca-phase2-ubl.xml
<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
         xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2">
  <cbc:ProfileID>reporting:1.0</cbc:ProfileID>
  <cbc:ID>SME00000001</cbc:ID>
  <cbc:UUID>3cf5ee18-ee25-44ea-a444-2c37ba7f28be</cbc:UUID>
  <cbc:IssueDate>2026-05-16</cbc:IssueDate>
  <cbc:IssueTime>10:30:00</cbc:IssueTime>
  <cbc:InvoiceTypeCode name="0211010">388</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>
  <cbc:TaxCurrencyCode>SAR</cbc:TaxCurrencyCode>
  <cac:AdditionalDocumentReference>
    <cbc:ID>ICV</cbc:ID>
    <cbc:UUID>10</cbc:UUID>
  </cac:AdditionalDocumentReference>
  <cac:AdditionalDocumentReference>
    <cbc:ID>PIH</cbc:ID>
    <cac:Attachment>
      <cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">NWZlY2ViNjZmZmM4...</cbc:EmbeddedDocumentBinaryObject>
    </cac:Attachment>
  </cac:AdditionalDocumentReference>
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PartyIdentification>
        <cbc:ID schemeID="CRN">1010001234</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>310122393500003</cbc:CompanyID>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>ediverse Demo Co. Ltd.</cbc:RegistrationName>
      </cac:PartyLegalEntity>
    </cac:Party>
  </cac:AccountingSupplierParty>
</Invoice>

Flux de soumission

En Phase 2, deux flux distincts :

  • B2B clearance : la facture est envoyée à FATOORA via POST /invoices/clearance/single. FATOORA valide, signe et retourne la facture cleared invoice (avec signature ZATCA en plus de celle de l'émetteur). Le vendeur livre cette version à l'acheteur, pas l'originale.
  • B2C reporting : la facture est émise localement puis envoyée à FATOORA en asynchronous reporting via POST /invoices/reporting/single sous 24 heures. Pas de signature ZATCA retournée — la facture livrée au consommateur est la version locale.
textflux-fatoora.txt
┌────────────┐    ┌──────────────┐    ┌────────────┐
│ Vendeur SA │───>│ FATOORA      │───>│ Acheteur SA│
│ (ERP +     │    │ (ZATCA)      │    │ (ERP)      │
│ unité E-2) │    │ clearance B2B│    │            │
└────────────┘    └──────┬───────┘    └────────────┘


                ┌─────────────────┐
                │ B2B: clearance   │  ← cryptographic stamp
                │  réponse signée  │     + QR code (TLV)
                │ B2C: reporting   │
                │  sous 24h        │
                └─────────────────┘

Validation

  • Portail ZATCA Sandbox : sandbox.zatca.gov.sa — environnement de test pour la Phase 2.
  • FATOORA Compliance and Enablement Toolbox (SDK) — outils Python et C# publiés sur le portail développeur ZATCA pour valider la conformité.
  • Documentation ZATCA : zatca.gov.sa — Systems Developers.
  • QR Decoder TLV — utilitaire ZATCA pour valider la structure du QR code (9 TLV obligatoires).

Pièges courants

  1. Chaîne d'intégrité ICV + PIH. Chaque facture émise par une unité de facturation (e-invoice solution) doit contenir l'ICV (compteur) et le PIH (hash de la facture précédente). Une rupture (ICV non séquentiel ou PIH incorrect) bloque toute la chaîne suivante. Toute architecture multi-unité doit isoler les compteurs par EGS (E-Invoice Generation Solution).
  2. QR code TLV strict. Les 9 TLV doivent figurer dans l'ordre fixé par ZATCA. L'omission d'un seul champ ou un encodage Length erroné fait échouer le check côté FATOORA et côté lecteur consommateur.
  3. Reporting B2C sous 24 heures. Le délai de 24 heures court à compter de la date d'émission, pas de la fin de la journée comptable. Un job de nuit qui rapporte au-delà de 24h depuis la première facture du jour est en infraction.
  4. Format InvoiceTypeCode à deux dimensions. Le couple InvoiceTypeCode + name="NNNNNNN" est subtil : le name encode Self-billed, Third-party, Nominal, Exports, Summary en bits. Une confusion entre UN/CEFACT 388 vs 380 ou un name mal encodé est l'erreur la plus fréquente de la migration Phase 1 → Phase 2.
  5. Onboarding par certificat ZATCA. La signature exige un certificat délivré par ZATCA via une procédure d'onboarding API en trois étapes (CSID compliance, CSID production, request signing). Une perte ou rotation de certificat sans CSR à jour bloque l'émission : maintenir une rotation planifiée.

Liens transverses