Égypte — ETA, e-Invoice et e-Receipt

L'Égypte a déployé un système national d'e-invoicing piloté par l'Egyptian Tax Authority (ETA) à partir de novembre 2020, par vagues d'enrôlement sectorielles. Le système, désormais étendu aux receipts B2C, repose sur un schéma JSON propriétaire avec signature électronique HSM.

Timeline réglementaire

• 7 septembre 2016 — Loi 67/2016 sur la TVA. Crée la TVA en Égypte (14 % taux standard) et instaure les obligations de facturation modernes.
• 19 octobre 2020 — Loi 206/2020. Loi unifiée sur les procédures fiscales — base juridique pour l'e-invoicing et l'échange électronique avec l'ETA.
• 1^er novembre 2020 — Décret ministériel 188/2020. Lance le système e-Invoice avec calendrier d'enrôlement par vagues.
• 15 novembre 2020 — Phase 1. 134 grandes entreprises pilotes, obligation de transmettre via le système ETA.
• 15 février 2021 → 15 juin 2022 — Vagues 2 à 7. Élargissement progressif aux mid-market, secteurs spécifiques (banque, pétrole, télécoms), puis ensemble des grandes entreprises.
• 15 avril 2022 — Lancement e-Receipt. Système distinct pour les flux B2C (retail, restauration), avec ses propres vagues.
• 1^er juillet 2023 — Généralisation e-Invoice. Toutes les entreprises assujetties TVA en Égypte doivent émettre via le système ETA. Délai de grâce jusqu'au 1^er janvier 2024 pour les TPE.
• 1^er janvier 2024 — Obligation totale e-Invoice. Toute facture B2B non transmise à l'ETA n'est pas reconnue fiscalement, et la TVA correspondante n'est pas déductible côté acheteur.

Schéma technique

Le format est JSON propriétaire ETA, version courante 1.x. Pas de mapping direct vers UBL ou CII ; l'ETA a conçu sa propre structure. Caractéristiques :

• documentType : I (Invoice), C (Credit Note), D (Debit Note), E (Export).
• issuer.type / receiver.type : B (Business), P (Person), F (Foreigner).
• taxpayerActivityCode : code d'activité économique ETA (basé sur la nomenclature ISIC).
• itemCode / itemType : code produit dans une nomenclature ETA (GS1 GTIN, EGS — Egyptian Goods and Services, ou code interne).
• taxableItems : array de taxes avec taxType (T1 pour TVA, T2 pour droit de timbre…), subType (V009 pour le taux standard 14 %), rate et amount.
• signature : bloc séparé portant la signature numérique CAdES du document, requis pour B2B.

Exemple minimal d'une e-Invoice B2B :

{
  "issuer": {
    "type": "B",
    "id": "100200300",
    "name": "Ediverse Demo Egypt LLC",
    "address": {
      "country": "EG",
      "governate": "Cairo",
      "regionCity": "Maadi",
      "street": "Road 9, Building 12"
    }
  },
  "receiver": {
    "type": "B",
    "id": "200300400",
    "name": "Customer Demo Egypt LLC"
  },
  "documentType": "I",
  "documentTypeVersion": "1.0",
  "dateTimeIssued": "2026-05-16T10:30:00Z",
  "taxpayerActivityCode": "6201",
  "internalID": "EG-2026-00000142",
  "purchaseOrderReference": "PO-2026-091",
  "invoiceLines": [
    {
      "description": "Cloud services May 2026",
      "itemType": "GS1",
      "itemCode": "6201001",
      "unitType": "EA",
      "quantity": 1.0,
      "internalCode": "SVC-CLOUD-001",
      "salesTotal": 50000.00,
      "total": 57000.00,
      "valueDifference": 0.0,
      "totalTaxableFees": 0.0,
      "netTotal": 50000.00,
      "itemsDiscount": 0.0,
      "taxableItems": [
        { "taxType": "T1", "amount": 7000.00, "subType": "V009", "rate": 14.0 }
      ]
    }
  ]
}

Flux de soumission

Le vendeur soumet la facture signée à l'ETA via l'API POST /api/v1/documentsubmissions. L'ETA valide en temps réel (cohérence schéma, signature, mapping codes produits), puis assigne :

• UUID — identifiant interne ETA.
• Long ID — identifiant alphanumérique affiché sur la représentation visuelle de la facture, utilisé pour la consultation publique.
• Submission UUID — référence de la soumission, à conserver par le vendeur.

┌─────────────┐    ┌──────────────────┐    ┌─────────────┐
│ Vendeur EG  │───>│ ETA SDK / API    │───>│ Acheteur EG │
│ (ERP, JSON) │    │ einvoicing       │    │ (download)  │
│ + signature │    │ portal           │    │             │
└─────────────┘    └────────┬─────────┘    └─────────────┘
                            │
                            ▼
                  ┌──────────────────┐
                  │ ETA assigns UUID │  ← rejet possible
                  │ + Long ID         │     en temps réel
                  └──────────────────┘

L'acheteur peut soit télécharger sa facture depuis le portail ETA (mailbox fiscal), soit la recevoir par les canaux usuels avec son Long ID pour contrôle. L'ETA expose une API GET /api/v1/documents/{uuid}/details pour récupération programmatique.

Validation

• Portail ETA e-Invoice : einvoicing.eta.gov.eg.
• Environnement préprod : preprod.invoicing.eta.gov.eg.
• Documentation technique : SDK Postman, schémas JSON et code listes publiés sur le portail développeur ETA.
• ITIDA : itida.gov.eg — autorité de certification des certificats de signature électronique requis par l'ETA.

Pièges courants

1. Codes produits ETA — étape la plus chronophage. Chaque ligne doit porter un itemCode dans une nomenclature reconnue ETA (GS1 GTIN, EGS, ou code interne avec mapping déposé à l'ETA). Le mapping initial des SKU vendeur vers GS1/EGS représente typiquement 40 % du chantier d'intégration.
2. Signature avec certificat ITIDA + HSM. Le certificat doit être délivré par l'ITIDA (autorité agréée), porté sur un HSM (matériel ou cloud certifié). Une signature avec un certificat non ITIDA est rejetée même si elle est techniquement valide CAdES.
3. Rate limiting ETA. L'API ETA limite à 400 requêtes par heure par taxpayer en environnement production. Les batch d'émission doivent gérer ce quota avec backoff exponentiel et file d'attente.
4. Cancellation et rejection. Une facture soumise peut être annulée par le vendeur sous 24h ou rejetée par l'acheteur sous 3 jours. Après ces délais, seule l'émission d'un avoir (Credit Note) corrige l'erreur. Beaucoup d'intégrations oublient ces fenêtres et bricolent des corrections illégales.
5. Arabe + anglais bilingue. Les libellés d'item, adresses et noms doivent être encodés UTF-8 et idéalement portés en arabe + anglais. Un libellé arabe seul peut compliquer la lecture par les intégrations anglophones ; un libellé anglais seul est accepté mais moins idéal côté affichage acheteur égyptien.

Liens transverses

• EN 16931 — comparaison sémantique européenne.
• PEPPOL — référence pour les modèles décentralisés.
• Arabie Saoudite — comparaison clearance Moyen-Orient.
• Émirats Arabes Unis — autre mandat de la région.
• Sources officielles : eta.gov.eg/e-invoice, itida.gov.eg.