Egyptian e-invoicing — what your data needs first

Electronic invoicing in Egypt has moved from optional to a condition of doing business: an invoice that was never submitted is not accepted as a deductible expense document by the buyer — which means companies now press their own suppliers to comply before any authority does.

A data document, not an invoice image

The most common misunderstanding is that electronic invoicing means emailing a PDF. In reality the system receives a structured data document describing the invoice field by field — seller, buyer, and each line with its code, unit, price and tax — which is digitally signed and submitted, after which a unique identifier and a status are returned: accepted, or rejected with a reason.

This has a practical consequence: a system that prints a handsome invoice but does not hold structured line-level data cannot submit, no matter what modules are added later. Readiness begins with data structure.

Four questions that decide your readiness

1. Does every item have a standard code?

Free-text descriptions are not accepted. Each item needs a code from an approved coding scheme — either a GS1 code or a code from the authority's item catalogue. Companies that identify items by free text or by unmapped internal codes face a manual coding exercise across thousands of items.

Start early: add a field for the approved code on the item master, and code the fastest-moving items first rather than working alphabetically.

2. Are units of measure approved?

Units must come from an approved list. "Carton", "sack" and "bundle" are common in warehouses but are not standard units, and each needs mapping to an approved unit with a conversion factor.

3. Is customer tax data complete?

A B2B invoice requires the buyer's tax registration number and registration type. Any business customer without one in the database means an invoice that will be rejected. This is the point that surprises companies most, because the customer record historically held little more than a name and a phone number.

4. Is tax calculated per line?

Many older systems apply tax as a percentage of the invoice total. The system requires tax type and amount to be determined per line, because a single invoice may contain items at different rates or exempt items. A system that does not store tax at line level needs a data-structure change, not a change to the print layout.

E-receipts are a different problem

E-receipts cover sales to end consumers at points of sale. The data is simpler because the buyer is not tax-registered, but the challenge differs: volume and continuity. A retailer issuing thousands of receipts a day cannot stop selling because the connection dropped.

The workable design is a submission queue: the receipt is recorded locally and handed to the customer immediately, then transmitted in the background with retry on failure. Any design that makes the sale depend on a real-time response is not viable in practice.

What we do at this stage

• A readiness review of item, customer and tax data in your current system, quantifying the gaps — how many items lack a code, how many customers lack a tax number.
• Structuring invoice data inside Keystone ERP so that tax, item codes and units are held at line level in the form the system requires.
• Item coding and mapping to approved codes.

A recurring mistake: integrating before cleaning

Companies that start with technical integration before cleaning their data enter an exhausting loop: submit a batch, most are rejected, correct manually, resubmit, repeat daily. The real cost is not development — it is the finance team's hours.

The cheaper order is the reverse: fix codes, units and customer tax data first, after which integration becomes a relatively short technical step.