When an e-invoice is rejected by the Egyptian Tax Authority, the finance team reads it as a tax issue. In our implementations, the cause is almost always upstream: a product without a GS1 or EGS code, a customer without a valid tax id, an address missing a field the portal requires. The fix is in master data, not in the tax return.
The seven we see most
- Products without an approved item code, or with a code of the wrong type for the product category.
- Customers with a national id where a tax registration number is required, or the reverse for individuals.
- Branch addresses that do not match the branch registered with the Authority, down to the governorate field.
- Unit of measure codes that are not in the ETA list, usually because a local unit was typed by hand.
- Discounts applied at document level where the schema expects them per line, or the other way round.
- Currency and exchange rate fields left empty on foreign-currency invoices.
- Credit notes issued without a reference to the original document’s UUID.
Fix it where it starts
Each of these is a validation rule that Odoo can enforce at the point of entry: a product cannot be saved without an item code, a customer cannot be set to B2B without a tax number, an invoice cannot be confirmed with an unmapped unit. We configure those rules during implementation. That is what we mean when we say the implementation is led by accountants: the system refuses the error instead of recording it.
The receipt mandate
For retail and food and beverage clients, the B2C receipt mandate adds a second stream with its own device registration and its own timing. It is part of the standard implementation for those sectors, and it is tested in the sandbox with the same rigour as invoices.
A rejected e-invoice is the Authority telling you what your master data looked like a month ago.