Egypt's e-receipt system: what it actually asks of a restaurant till

Most restaurant owners meet the e-receipt system the way you meet a pothole: suddenly, and with a deadline attached. The instinct is to treat it as a piece of paperwork — something an accountant handles, or a module a vendor switches on.

It is not that. It is a set of demands on how your till records a sale, and a till that records sales carelessly cannot be made compliant by adding anything on top.

First, the two systems are not the same thing

Egypt runs two related but separate systems, and conflating them wastes weeks.

• The e-invoice (الفاتورة الإلكترونية) covers business-to-business transactions. Your supplier issues you one. If you cater an office party and invoice a company, you issue one.
• The e-receipt (الإيصال الإلكتروني) covers business-to-consumer sales at the point of sale — a guest eating a meal and paying at the till. This is the one that governs the great majority of a restaurant’s transactions.

A restaurant with a delivery arm, a catering line and a dining room may well touch both. Work out which of your revenue streams is which before you ask anyone for a quote, because the answer changes what you are buying.

What the system actually wants

Strip away the acronyms and the mandate asks for four things.

1. A registered device. Each till point is registered with the tax authority through its POS portal, and devices go through technical and security review. An unregistered or rejected device is not a small configuration issue — it is a till that cannot legally issue.

2. A signed submission. Receipts are signed electronically — via an e-signature or e-seal — so the authority can establish that the record genuinely came from you and has not been altered. Somebody has to own that credential, know where it is physically kept, and know what happens when it expires.

3. Coded items. This is the step that surprises people. Every item you sell has to carry a code the authority recognises, mapped to the correct tax treatment. A menu of a hundred and eighty items, each needing a code and a tax classification, is not an afternoon’s work — and it is the task that most commonly turns a deadline into a crisis.

4. Near-real-time transmission. The receipt is sent to the authority as the sale happens, and the customer’s copy carries a QR code so the record can be verified against the authority’s own system.

The part nobody budgets for: coding the menu

If you take one practical thing from this article, take this one.

Start the item coding before you start anything else. It is the only part of the project whose length is set by your menu rather than by your vendor’s calendar, and it is the part that cannot be rushed at the end.

Some rules that save rework:

• Code the item you sell, not the ingredient you buy. A plate of grilled chicken is a sellable item with a tax treatment. The chicken in your store is inventory, and it is not what a receipt reports.
• Decide your treatment of service charge first. It is not tax, it does not behave like tax, and a receipt that blends the two produces a figure that cannot be reconciled by anyone later.
• Give combos and modifiers their own thinking. An upsized drink, a side swap and a meal deal all have to resolve to something codeable. Leave them to the last week and you will discover the exceptions at the worst possible moment.
• Do it once, centrally. If you have three branches with three slightly different menus, this is the moment that costs you — or the moment you finally unify them.

What it demands of your POS, whatever brand it is

These requirements outlive any particular deadline, and they are worth applying as a test when you choose a system:

Notice that none of these are “e-receipt features”. They are ordinary good record-keeping — which is exactly the point. Compliance is not a module; it is a consequence of a till that was honest about what happened.

The question your vendor demo will not answer: what happens when the line drops

Transmission is near-real-time. Egyptian internet is not.

This is the gap that turns a compliant system into a queue of angry guests, and it is worth pressing hard on before you sign:

• Does the till keep selling when the connection goes, or does it stop?
• Are unsent receipts queued and transmitted automatically when the line returns, or does someone re-key them?
• If a submission is rejected by the authority, does the system tell you, and can it be corrected and resent — or does it fail silently and surface at month end?
• When you replace a broken till, who re-registers the device, and how long does the restaurant wait?

A vendor who has run this in a real restaurant answers these quickly and specifically. A vendor who has only read the specification answers them in the abstract. The difference is audible.

GoSufra is built for this shape of problem: the till keeps taking orders when the connection drops and the queue catches up afterwards, sales carry their real payment method, numbering is sequential by design, and the sales and tax detail exports as data rather than as a monthly PDF. That is the foundation any submission integration has to sit on — and a system that cannot produce clean, sequential, exportable sales data cannot be made compliant by bolting one on.

What to do this month

1. Establish your actual position. Which phase applies to your business, by size and activity? Ask your accountant, and confirm through the tax authority directly rather than through a vendor’s marketing page. The authority runs a hotline on 16395 and an e-receipt mailbox at eReceipt.hd@eta.gov.eg.
2. Start the item coding. Today, not after the vendor is chosen.
3. Settle the service charge question with your accountant, in writing.
4. Count your till points and confirm each one can be registered.
5. Decide who owns the e-signature — and where the credential physically lives.
6. Test your current export. Can you produce a complete, itemised, sequential month of sales as data right now? If not, that is your real problem, and it exists with or without the mandate.

A necessary caution

The phases, thresholds, deadlines and penalties of this system have moved repeatedly as the rollout has widened, and they are administered by the Egyptian Tax Authority under Egypt’s tax procedures legislation — not by software vendors, including us. Nothing in this article establishes what applies to your specific restaurant on a specific date.

Two things, though, are safe to act on now. Coding your menu is work you will have to do under any version of the rules. And a till that records every sale in sequence, with its real payment method and its tax and service charge on separate lines, is the only starting point from which compliance is a configuration rather than a rebuild.