Restaurant Systems and Tax Compliance: What KSA and Egypt Require of Your Till

Before you compare restaurant systems by their feature lists, one question comes first: will the document your till prints be accepted by the tax authority in your country? In Saudi Arabia that means a simplified invoice your own system stamps cryptographically and reports to the Fatoora platform within 24 hours. In Egypt it means an electronic receipt issued from a registered device, carrying an identifier derived from the receipt before it on that same device. Digital menus and loyalty points come after that, because neither of them can stop a restaurant from trading.

This guide collects what the Zakat, Tax and Customs Authority (ZATCA) and the Egyptian Tax Authority (ETA) require of a point of sale in a restaurant or café specifically, and what follows from that for the rest of the stack: table ordering, inventory and orders arriving from delivery platforms. Every requirement below comes from the authority's own document, consulted on 21 September 2026.

Are you obliged yet, and how would you know?

Each country uses a criterion different enough to change how you plan.

Saudi Arabia: your revenue sets your date

Phase one of e-invoicing, generating and storing invoices electronically, has applied to everyone subject to the regulation since December 2021. The integration phase arrives in waves ordered by VAT-taxable revenue, and each wave is notified at least six months before its date, as ZATCA's rollout phases page states.

Wave twenty-five is the most recent one announced, and ZATCA set its criterion as VAT-taxable revenue above 187,500 SAR in any year from 2022 to 2025, with integration starting 1 February 2027. A single restaurant trading all year usually clears that threshold, so the practical question is not whether but when. The date that binds you arrives in ZATCA's notice; it is not something you estimate. What actually gets built or changed inside the system at integration is covered in our guide to phase two of e-invoicing.

Egypt: your name on a published decision

Egypt publishes no revenue threshold that pulls you in automatically. The e-invoicing system covers business-to-business trade, and under Minister of Finance Decree No. 323 of 2022 every ETA taxpayer must join it once three conditions are met: an electronic seal or signature, approved codes for every good and service, and electronic integration with the system. The e-receipt, which is the document your restaurant issues because it sells to final consumers, has its own conditions: you must already be on e-invoicing, a mandate decision must be issued by the head of the ETA, and your items must be coded (conditions for joining, ETA, in Arabic).

Those mandate decisions are published by number on the ETA's e-receipt mandate decisions page. They come in main phases and sub-phases, and some are geographic: decision 484 of 2022 for taxpayers in Sharm El-Sheikh, decision 498 of 2023 for the North Coast. The most recent one listed as of 21 September 2026 is decision 361 of 2025, the first sub-phase of the ninth main phase. Each decision comes with an attached list of names, so you check by name rather than by estimate.

That produces a scheduling difference. A restaurant owner in Saudi Arabia reads the date off their own revenue. A restaurant owner in Egypt watches the decisions and knows no e-receipt can be issued before the business is on e-invoicing. The electronic seal and item coding come before any conversation about a till screen, and they are what consumes the time. The integration steps are in our guide to connecting your system to Egypt's e-invoicing system.

What the till actually issues

In Saudi Arabia your system issues two kinds of document, not one. The simplified invoice is the normal case in a restaurant: it is handed to the customer as soon as the transaction completes, then your system reports it to Fatoora in XML within 24 hours, as the Detailed Guidelines for E-Invoicing set out. The document does not pass through ZATCA's stamp here; the cryptographic signature and the QR code are your system's responsibility alone.

A second kind appears when a customer asks for an invoice in their company's name, which happens with event orders and corporate accounts. That is a standard tax invoice, and the same guideline states it must be cleared by the platform before it is shared with the customer. A network round trip now sits in the middle of a sale that used to be instant, and the system needs defined behaviour when the response is slow. If your restaurant offers this, ask about it explicitly, because plenty of restaurant systems handle only the first path well.

That QR code on a simplified invoice is not decoration either. The resolution on controls, requirements and technical specifications fixes its contents at nine fields. Five describe the sale: the seller's name, their VAT registration number, the timestamp, the total including VAT, and the VAT amount on its own. The other four are technical: the hash of the XML, the cryptographic stamp, the public key behind it, and the Authority's stamp on that key.

Egypt differs in a detail that is easy to miss. The receipt UUID is a SHA256 hash of the normalised receipt content, 64 characters long, and its calculation includes the UUID of the previous receipt issued by the same POS device, as the ETA SDK's receipt issuance FAQ explains. Every device has a precondition of its own: it must be registered and linked to the issuer's registration number before the receipt is issued, and if the device has been retired the whole submission is rejected, not just that document.

Voids and refunds: the habit the rules forbid

What collides with compliance in restaurants is a daily habit at the till: the order changes, so the invoice is voided and reprinted, and sometimes the issuance time is edited so the sale lands in a different shift.

ZATCA's resolution names this in its annex of prohibited functionalities. A compliant solution must not allow generated invoices, their notes or their logs to be altered or deleted, must not produce inaccurate timestamps, must not reset the invoice counter, and must not generate more than one invoice sequence at a time. The same resolution requires a tamper-resistant counter that cannot be reset or reformatted, whose value is recorded in every document, alongside embedding each invoice's hash in the next one, which is the mechanism that exposes any deletion or substitution in the chain.

Credit notes are the sanctioned alternative. ZATCA's detailed guideline explains that it is issued to refund a buyer or to correct information on an invoice generated with an error, that it follows the format of the invoice it relates to, and that it must reference the original invoice.

Egypt reaches the same place with different tools. An incorrect sales receipt is resubmitted with a new identifier while the old one is carried in a dedicated field, and the previous receipt's identifier stays as it was so the chain does not break. The SDK fixes two correction windows: 96 hours for an amendment with a reference, and 72 hours for one without. A return receipt has a maximum of 540 days from the date of the sales receipt.

On the screen the cashier actually uses, this means no delete button. It means a button that opens a correction document, with a recorded reason, behind a permission not everyone standing at the till holds, and a sequence column in the database that is never renumbered. Ask the vendor to show you that screen during the demo rather than in the documentation.

Losing connectivity or power at peak time

This is the first scenario to ask about, because it happens every month.

In Saudi Arabia the resolution requires the solution to keep working when the connection drops: invoices and notes are queued and reported once connectivity returns. The detailed guideline breaks the cases down. If ZATCA's servers are unresponsive, your system keeps retrying at regular intervals until it succeeds, while keeping evidence of the attempts. If you cannot report within 24 hours, you notify ZATCA through a dedicated form on its website. If power is lost or the device breaks, you report the failure, continue trading, and regenerate once it is fixed.

There is also a middle state that is easy to ignore: a response of accepted with warnings. The document goes through and the sale completes, and what the guideline asks is that the warnings be investigated and amended on the next invoice. If your system does not gather those responses into a report your accountant sees, you will find them months later.

Egypt uses the same 24-hour window, and beyond it there is a formal route called a late submission request, though it is not an open door: the number of requests allowed per year is capped, each request has a window in days that sets how old a document may be, and the system has to re-authenticate to get an updated token before it can use one. A single submission has limits too: 500 receipts and 1.5 MB at most, and 300 line items per receipt. Those numbers matter precisely after a long outage, when hundreds of receipts are waiting at once.

Both countries lead to the same design conclusion: a submission queue with a retry policy, matched by a log that stores the authority's response to every document. Above both, monitoring that warns the manager before the deadline passes rather than after.

The rest of the stack is built on the till, not beside it

QR table ordering is an order-entry channel, not an independent source of documents. If the menu app issues its own "invoice" outside the registered unit's sequence, you have created a second sequence, which ZATCA's resolution prohibits outright. The correct path is for every order, whether from the table, the till or the app, to end in the same document.

Linking inventory to sales follows the same rule: the items deducted with every sale are the same coded items that appear on the document, and anything else builds two reports that never reconcile. The principles of stock control and counting are in our warehouse management guide, and the path from till to accounts in our POS system guide.

Loyalty needs the customer identified, and here an Egyptian detail is worth noting: the validation rules in the SDK make the national ID mandatory for a buyer of type person once the receipt total reaches 150,000 EGP, for receipt versions 1.2 and newer. Not an amount that recurs over a meal, but a plausible one for an event or catering. Branches have a condition too: the issuer branch id is a required field, and a branch that ceases activity with the ETA stops issuing receipts.

Delivery platform orders: where they land and how to reconcile them

Orders from external platforms are what eats your accountant's time every month.

Published documentation shows the shape of the integration. The Talabat POS integration documentation, which covers Delivery Hero's middleware APIs, splits the endpoints into two categories: those called by the POS plugin and maintained by the platform, and those implemented by the POS provider to receive orders and updates. An incoming order reaches your system through a webhook, and so does a cancellation notice, alongside endpoints for submitting the catalogue, updating item availability and pulling order reports.

Its how it works page adds a practical point: building your own plugin suits POS companies, not restaurant owners. You connect through your POS provider if it is already integrated. So the right question for a vendor is not "do you support delivery?" but "which platforms do you have a working plugin with today, and since when?".

Then comes the case that breaks the accounts: cancellation. The cancellation notice arrives as an event, and your system has to translate it into the correct action based on what actually happened, because an order with no document issued yet is a different case from one whose document was issued and reported. Who issues the document on platform orders, and on what basis the commission is calculated, are questions to settle with your accountant and with the wording of the platform contract; what concerns you technically is that every sale keeps exactly one document inside your system's sequence, and every cancellation leaves a documented trace.

As for the commission itself: delivery platforms operating in Egypt and the Gulf do not publish official rate cards. The rate is set in the partnership contract and varies with the agreement. The figures circulating in marketing articles disagree widely and rest on no source from the platform, so do not price against them. What you can build is a daily reconciliation between the order report the platform provides and your own documents, per branch, so the gap you discuss with them is a number rather than an impression. The operational side of building your own delivery is covered in our guide to developing a delivery app in Saudi Arabia and Egypt.

What to ask a vendor before you sign

These questions come straight out of the requirements above, and a single vague answer is worth pausing on:

• In which country has the system actually been certified, and which customer is running it in production today rather than in a test environment?
• Show me the screen for voiding an invoice that has already been issued. Does it open a correction document, or delete?
• What does the system do when the internet drops for two hours at peak time, and how does it warn before the 24-hour window closes?
• Where are the authority's responses to each document stored, and how do I see documents accepted with warnings?
• Can the system issue a standard tax invoice to a customer asking in their company's name, and what happens if clearance is slow?
• How does it handle several tills and several branches in terms of sequencing and branch id?
• Which delivery platform does it have a working plugin with, and how is a cancellation from that platform recorded?
• If I change vendors in two years, in what format do I export my data and my documents?

Frequently asked questions

Is it enough to buy a system labelled "ZATCA compliant"?

That label alone is not enough, because the obligation sits with the business, not the software. Ask to see a unit actually running in production at a customer in Saudi Arabia, and have the vendor explain how each unit in your restaurant is onboarded and what the system does when the platform rejects a document.

My restaurant is in Egypt and no e-receipt mandate has reached me. Should I wait?

Do not wait on the part that takes time. You cannot issue electronic receipts before a mandate decision is issued by the head of the ETA, but joining the e-invoicing system and coding your items come before that and involve real procedures and delays. Start there and keep watching the decisions page.

I have a branch in Cairo and one in Riyadh. Can one system serve both?

It can, provided the system separates the tax document layer from the rest of operations. Menu, inventory and loyalty look similar in both countries, but the document format, the signature and the submission path differ, and each country has its own sequence and registered devices. Ask the vendor how they keep the two apart inside the same product. Add a branch in the UAE and it is a third layer again: documents travel through an accredited service provider rather than a direct connection to the authority, and sales to individual consumers stay outside the regime until the minister issues a decision, while business invoices are inside it, as detailed in our guide to UAE e-invoicing.

Building a restaurant system that issues its documents from a single sequence, and that handles clearance, reporting and network outages, is part of Snaabble's custom systems work. If you are reviewing an existing system or thinking about building one, write to us about where you stand today and we will come back within 24 hours with an initial plan and an estimate of time and cost, at no cost and with no commitment.

Sources

Everything above comes from the following documents, all consulted on 21 September 2026:

• Zakat, Tax and Customs Authority: rollout phases, the wave 25 criterion announcement, the Detailed Guidelines for E-Invoicing, and the resolution on controls, requirements, technical specifications and procedural rules.
• Egyptian Tax Authority: conditions for joining the e-invoice and e-receipt systems, e-receipt mandate decisions, your guide to the e-receipt system, and the receipt issuance FAQ in the SDK.
• Talabat / Delivery Hero: POS integration documentation and the how it works page.