Egypt — ETA, e-Invoice and e-Receipt

Egypt deployed a national e-invoicing system driven by the Egyptian Tax Authority (ETA) from November 2020, in sectoral onboarding waves. Now extended to B2C receipts, the system relies on a proprietary JSON schema with HSM electronic signature.

Regulatory timeline

• 7 September 2016 — VAT Law 67/2016. Creates VAT in Egypt (14 % standard rate) and establishes modern invoicing obligations.
• 19 October 2020 — Law 206/2020. Unified Tax Procedures Law — legal basis for e-invoicing and electronic exchange with the ETA.
• 1 November 2020 — Ministerial Decree 188/2020. Launches the e-Invoice system with a wave-based onboarding schedule.
• 15 November 2020 — Phase 1. 134 large enterprise pilots, mandatory transmission via the ETA system.
• 15 February 2021 → 15 June 2022 — Waves 2 to 7. Progressive extension to mid-market, specific sectors (banking, oil, telecoms), then all large enterprises.
• 15 April 2022 — e-Receipt launch. Separate system for B2C flows (retail, food service), with its own waves.
• 1 July 2023 — e-Invoice generalisation. All VAT taxpayers in Egypt must issue via the ETA system. Grace period until 1 January 2024 for very small businesses.
• 1 January 2024 — Full e-Invoice obligation. Any B2B invoice not transmitted to the ETA is not fiscally recognised, and the corresponding VAT is not deductible for the buyer.

Technical schema

The format is a proprietary ETA JSON, current version 1.x. No direct mapping to UBL or CII; the ETA has designed its own structure. Features:

• documentType: I (Invoice), C (Credit Note), D (Debit Note), E (Export).
• issuer.type / receiver.type: B (Business), P (Person), F (Foreigner).
• taxpayerActivityCode: economic activity code ETA (based on the ISIC nomenclature).
• itemCode / itemType: product code in an ETA nomenclature (GS1 GTIN, EGS — Egyptian Goods and Services, or internal code).
• taxableItems: array of taxes with taxType (T1 for VAT, T2 for stamp duty…), subType (V009 for the 14 % standard rate), rate and amount.
• signature: separate block carrying the CAdES digital signature of the document, required for B2B.

Minimal example of a B2B e-Invoice:

{
  "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 }
      ]
    }
  ]
}

Submission flow

The seller submits the signed invoice to the ETA via the API POST /api/v1/documentsubmissions. The ETA validates in real time (schema consistency, signature, product code mapping), then assigns:

• UUID — internal ETA identifier.
• Long ID — alphanumeric identifier shown on the visual representation of the invoice, used for public lookup.
• Submission UUID — reference of the submission, to be kept by the seller.

┌─────────────┐    ┌──────────────────┐    ┌─────────────┐
│ EG supplier │───>│ ETA SDK / API    │───>│ EG customer │
│ (ERP, JSON) │    │ einvoicing       │    │ (download)  │
│ + signature │    │ portal           │    │             │
└─────────────┘    └────────┬─────────┘    └─────────────┘
                            │
                            ▼
                  ┌──────────────────┐
                  │ ETA assigns UUID │  ← real-time
                  │ + Long ID         │     rejection possible
                  └──────────────────┘

The buyer can either download the invoice from the ETA portal (fiscal mailbox), or receive it through usual channels with its Long ID for verification. The ETA exposes an API GET /api/v1/documents/{uuid}/details for programmatic retrieval.

Validation

• ETA e-Invoice portal: einvoicing.eta.gov.eg.
• Preprod environment: preprod.invoicing.eta.gov.eg.
• Technical documentation: Postman SDK, JSON schemas and code lists published on the ETA developer portal.
• ITIDA: itida.gov.eg — certification authority for the electronic signature certificates required by the ETA.

Common pitfalls

1. ETA product codes — the most time-consuming step. Each line must carry an itemCode in an ETA-recognised nomenclature (GS1 GTIN, EGS, or internal code with a mapping registered at the ETA). Initial mapping of supplier SKUs to GS1/EGS typically represents 40 % of the integration project.
2. Signature with ITIDA certificate + HSM. The certificate must be issued by ITIDA (approved authority), carried on an HSM (hardware or certified cloud). A signature with a non-ITIDA certificate is rejected even if technically valid CAdES.
3. ETA rate limiting. The ETA API caps at 400 requests per hour per taxpayer in production. Batch issuance jobs must handle this quota with exponential backoff and a queue.
4. Cancellation and rejection. A submitted invoice can be cancelled by the seller within 24h or rejected by the buyer within 3 days. Past these deadlines, only issuing a Credit Note corrects the error. Many integrations forget these windows and patch illegal corrections.
5. Bilingual Arabic + English. Item labels, addresses and names must be UTF-8 encoded and ideally carried in Arabic + English. An Arabic-only label can complicate reading by English-speaking integrations; English-only is accepted but less ideal on the Egyptian buyer's display.

Cross-links

• EN 16931 — European semantic comparison.
• PEPPOL — reference for decentralised models.
• Saudi Arabia — Middle East clearance comparison.
• United Arab Emirates — another mandate in the region.
• Official sources: eta.gov.eg/e-invoice, itida.gov.eg.