Egypt e-invoicing: what the ETA actually requires

Saudi Arabia, Jordan and the UAE all ask a business to send an XML document, signed or stamped with something the business itself can hold. Egypt's Tax Authority (ETA) asks for a JSON document, signed with a certificate that — by design — normally cannot leave a physical USB token. That one difference shapes the entire integration.

Two obligations, not one

Egypt runs two related but separate digital tax obligations. The e-invoice system covers structured, itemised invoices — the document this guide is about. A separate e-receipt system covers point-of-sale receipts to consumers. They share the same tax authority and the same intent — near real-time visibility into transactions — but they are not the same submission, and treating one as covering the other leaves a gap in whichever one you skipped. Confirm which obligation applies to which part of your business with the ETA; the two have been rolled out on different timelines and to different taxpayer segments.

The document is JSON, and a submission is a batch

The invoice itself is a JSON object, not UBL — Egypt is the outlier of the region on format as well as on signing. And the intake endpoint takes an array: you can submit several documents in one call, and the response separates what it accepted from what it refused. An HTTP 200 on that call means the ETA read the batch, not that it took every document in it.

The signature: CAdES-BES from a token you hold, not one the ETA issues

Every document needs a CAdES-BES signature produced with the taxpayer's own certificate — and that certificate lives on a hardware token, physically at the business's premises, by design. No cloud service can hold it on the business's behalf, because the whole point of a hardware token is that the key never leaves it.

Before signing, the document is rewritten into the ETA's own canonical form: every field name upper-cased, values quoted and escaped in a fixed order, arrays repeating the field name before each element. Two systems building the same invoice have to produce the identical byte string here, because the signature is computed over this canonical text — not over the JSON you send. Sign the JSON directly and the signature will not verify.

In practice this means a local signing service: a small piece of software at the business's premises that can see the hardware token, accepts the canonical text, and returns the signature. The submission calls out to it before it calls the ETA.

What else the document carries

• Issuer and receiver types — the seller is always type "B" (business); the buyer is "B" with a tax number or "P" for a person without one.
• The seller's own invoice number as the internalID — the field the ETA matches a credit note against, not any internal database id.
• Every amount restated in Egyptian pounds, even on a foreign-currency invoice — with the original amount and the exchange rate carried alongside it, not instead of it. A dollar invoice that declares its dollar figures as if they were pounds understates the tax base by the exchange rate on every line.
• A CAdES-BES signature under signatureType "I" — the issuer's own signature, the one every submission needs regardless of document type.
• On a credit note, a reference to the original invoice's own internalID. A note that names nothing is refused as an unlinked negative supply.

Onboarding: the token comes before the software

1. 1Register the business on the ETA taxpayer portal and obtain an OAuth2 Client ID and secret — these authenticate the API call, not the document itself.
2. 2Obtain a signing certificate on a hardware token through a licensed provider. This step has the longest lead time in the entire integration and is worth starting before any code is written.
3. 3Stand up a local signing service that can reach the token and implement the ETA's canonical serialisation — or point Fatouraty at one that already exists.
4. 4Submit test documents against the preprod environment (preprod.invoicing.eta.gov.eg) and read the acceptedDocuments / rejectedDocuments split on every response, not just the HTTP status.
5. 5Move to production hosts only once a standard invoice and a credit note both come back accepted from preprod.

The integration checklist

1. 1Start the hardware-token procurement in week one — it is the longest lead time here, not the code.
2. 2Decide what happens when the token holder is unavailable. A single physical USB token with no backup process is a single point of failure for every invoice the business issues.
3. 3Build the canonical-serialisation step exactly to the ETA's rule, field by field, and test it against a document with nested arrays before trusting it on a real invoice.
4. 4Convert every line to Egyptian pounds at the invoice's own exchange rate, and keep the original currency amount alongside it rather than discarding it.
5. 5Read every response's accepted/rejected split in code, never the HTTP status alone.
6. 6Map credit notes to the seller's own internalID on the original invoice, not an internal record id.
7. 7Confirm separately whether the e-receipt obligation also applies to any point-of-sale side of the business — it is not covered by an e-invoice integration.
8. 8Retain the signed payload, the canonical text it was signed over, and the platform's response together — reproducing a signature after the fact needs all three.

Where teams actually get stuck

• Treating HTTP 200 as filed. It means the batch was read, not that every document in it was accepted.
• Signing the JSON payload directly instead of the canonical serialisation — a signature computed over the wrong bytes fails validation even though the document is otherwise correct.
• Declaring a foreign-currency line's pound amount as equal to its face value, silently understating the tax base by the exchange rate.
• No continuity plan for the hardware token — a lost, expired or inaccessible token stops every invoice the business can issue, not just one.
• Confusing the e-invoice and e-receipt obligations, or assuming one integration satisfies both.

How Fatouraty handles it

Fatouraty builds the ETA's JSON document from the invoice or credit note already in the ledger, converts every line to Egyptian pounds at the document's own exchange rate while keeping the original currency figure alongside it, and computes the canonical serialisation field by field exactly as the authority defines it — rather than signing the JSON directly, which would produce a signature that fails validation.

It calls out to the local signing service the business points it at for the actual signature — it does not and cannot hold the hardware-token key itself — and refuses to transmit at all without a signing certificate on file, the same refusal ZATCA's adapter makes without a stamping key. On the way back, it reads the acceptedDocuments and rejectedDocuments lists rather than trusting the HTTP status, so a batch rejection is never recorded as a filed invoice.

Where to start

Start with the token, not the integration. Contact a licensed provider about issuing the signing certificate the same week you begin — it is the one dependency with a lead time measured in weeks rather than hours, and every other piece of this guide can be built and tested against preprod while it is in progress.