Egypt and Saudi e-invoicing: what is the same and what is not

If you trade in both Egypt and Saudi Arabia, you are subject to two electronic invoicing regimes that were designed independently. They ask for similar information in different shapes, and the temptation is to treat them as two separate problems. That is expensive, and it is not necessary.

It helps to separate what each regime genuinely requires from what is simply its own vocabulary.

What is actually the same

Both require that an invoice carry a verifiable identity of the seller, a structured description of what was sold, the tax treatment line by line, and a reference that ties the electronic document to the commercial one. Both require that a submitted document cannot be changed afterwards. Both expect corrections to be made by issuing a further document rather than editing the original.

That is most of the work, and none of it is jurisdiction-specific. It is the data model: a tax identity for the company, tax categories on each line, a document type that distinguishes an invoice from a credit note, and an immutability rule after clearance.

Where they genuinely differ

• The document format and the field names. Different structures carrying the same facts.

• The timing. One regime clears a document as part of issuing it; the other reports documents after the fact. This changes what the user sees on screen, and how a failure is handled.

• Signing and cryptography. The requirements for how a document is signed, and what is attached to it, are not interchangeable.

• The identifiers. Tax registration numbers, activity codes and unit-of-measure code lists are national and must be stored per company rather than hardcoded.

The design that makes two regimes affordable

Keep one invoice. Keep one set of tax categories on the lines. Keep one submission record with a status and a reason. Then make the format, the signature and the endpoint a plug-in chosen by the company jurisdiction.

The test of whether you have the separation right is simple: adding a third country should mean writing a new format and nothing else. If it means touching the invoice screen, the posting logic or the stock movement, the regime-specific part has leaked into the core.

The non-technical part people underestimate

Both regimes require that your master data be correct in ways that previously did not matter. A customer with no tax registration number, an item with no code, a unit of measure that exists only as a word in a text field - these were tolerable before and are rejections now.

So the first phase of any e-invoicing project is a data clean-up, and it is worth doing before the integration rather than discovering it through rejection messages. Pull a list of customers with no tax number and items with no unit code. That list is the real project plan.

A word on timing

Both authorities have moved in phases, and thresholds have changed more than once. Build for the obligation you have, but do not design as if it is the last one: the parts most likely to change are the format and the timing, which is exactly why they belong behind a boundary rather than in the middle of your invoice.