Egyptian e-invoicing, built in — and what it will not send

Mapping your products and units onto the Tax Authority’s codes is the work. Blocking a malformed document before it is submitted is the point.

Built against the Tax Authority’s own schemas

Egyptian e-invoicing is not a checkbox. A document either matches the shape the Tax Authority publishes or it is rejected, and the mapping from your own products and units onto their codes is the work.

What has to be mapped

Three things, per company: products onto EGS or GS1 codes, units of measurement onto the Authority’s unit list, and taxes onto their type and sub-type. The system holds that mapping and validates against it BEFORE anything is submitted.

A malformed document is blocked, not sent

The validation gate refuses to submit a document that would be rejected. That is deliberate: a rejected submission is a queue to clear and a customer to call back, and finding the problem at the till is cheaper than finding it at the Authority.

It never sends an unsigned document

Signing needs the company’s own e-seal. Where the signer is not configured the system raises rather than sending anything unsigned — there is no mode in which it quietly submits and hopes.

What prints on the invoice

A real QR and the submission UUID, once the document is accepted. Where a document was not submitted, or was rejected, the printed invoice says so in words — it does not print a QR that leads nowhere. An invoice carrying a fake code is worse than one carrying none.

Off by default

The module ships switched off and needs the customer’s own client credentials and their e-seal to do anything at all.