Egyptian Tax Authority E-Invoicing: The 200-Invoice Rule and What Follows

In Egypt, e-invoicing is not an upcoming deadline. It has been mandatory for every taxpayer registered with the Egyptian Tax Authority since 15 December 2022, and since 1 July 2023 proving a deductible cost and deducting or reclaiming its VAT have depended on holding a valid electronic invoice. Yet most of what circulates about the system in the Egyptian market is incomplete or simply wrong — starting with the "200 invoices" rule, which many read as an exemption. It is not an exemption. This article gathers what you need before choosing your route, taken from ETA's own pages and published forms rather than from vendor blogs.

The 200-invoice rule: both conditions, not either

The version everyone repeats is that a business issuing fewer than 200 invoices a month is not obliged to integrate and may key its invoices into the taxpayer portal by hand. That is half the sentence, and the missing half reverses the meaning.

ETA's portal-issuance request form, published on its own site, has the taxpayer declare two things rather than one: that they have no ERP or invoice-issuing program at all, and that they issue no more than 200 invoices a month. Both conditions. If you own an accounting system that issues invoices — whatever your size, even at ten invoices a month — the route open to you is integration, not the portal.

A third detail is usually forgotten: portal issuance is not a self-service setting you switch on from your own account. The request goes to your tax office and is approved by its head, and ETA reserves the right to act if the signed declaration turns out to be untrue. So "we will stay on the portal" is not an internal decision your finance team makes; it is a status you apply for and wait to be granted.

Why does the distinction matter in practice? Because many small companies bought an accounting system and then assumed their low volume excused them from connecting it. The truth runs the other way: owning the system is precisely what creates the obligation. Both routes and their conditions, with the ETA sources behind them, are set out in our guide to Egyptian Tax Authority e-invoicing.

Two systems, not one

The second common confusion is treating "e-invoice" and "e-receipt" as two names for the same thing. They are separate systems, with separate registrations, and with completely different logic for how the obligation reaches you.

The e-invoice system covers what you sell to other businesses and to government bodies, and it applies to everyone from the date above. The e-receipt system covers sales to end consumers at the point of sale, and it is rolled out in phases through decisions that name sectors and geographic areas — restaurants and cafés, health and telecoms, retail chains, supermarkets and so on.

The essential point: the e-receipt system has no revenue threshold. Your obligation does not arrive because your turnover crossed a number; it arrives because your activity and your area were named in a phase decision. The question to ask is not "how big am I?" but "has my sector appeared on a list?". And a company selling both ways — to businesses and to consumers — has two projects, not one, with two budgets and two schedules.

What applies to you, and what it requires

The table below condenses the routes and their conditions. Read the row that describes you, then read the coding row, because that one applies to everybody without exception.

Obligation or route	Who it applies to	What it requires
E-invoicing (B2B and B2G)	Every company invoicing other businesses or government bodies	Mandatory for all ETA-registered taxpayers since 15 December 2022. From 1 July 2023, deducting costs and deducting or reclaiming VAT depend on holding an electronic invoice
Issuing through the taxpayer portal	A taxpayer with no ERP or invoice-issuing program who also issues no more than 200 invoices a month — both conditions	A written request on ETA's form, approved by the head of your tax office. Owning an ERP obliges you to integrate even below 200
ERP or POS integration via the ETA SDK	Any taxpayer above the portal limit, and anyone running an accounting system who will not key invoices twice	A client ID and two client secrets from the ETA portal, a signing device, and a system that submits signed documents to the API
E-receipt (sales to consumers)	Only taxpayers named in a phase decision, by sector and area — there is no revenue threshold	A registration and a system separate from e-invoicing, plus tracking the phase decisions to learn when you are named
Item coding — required on every route	Every taxpayer issuing documents, through the portal or through an integration	A GS1 GTIN is usable as soon as it is registered; an internal EGS code (EG-TaxID-InternalCode) needs ETA approval before use

Item coding: the difference that reshapes your schedule

Every item you sell must carry a code registered on the taxpayer portal before it can appear on any document. You have two routes: a global GS1 GTIN, or an internal EGS code you build in a format beginning with your tax registration number.

Here sits a detail almost nobody publishes, and it genuinely changes project planning: a registered GTIN is usable immediately, while an internal EGS code is created in a pending state and cannot be used on an invoice until ETA approves it. That asymmetry is not a technicality. It is the difference between a track you can finish yourself in a week and a track that waits on a third party whose pace you do not control.

This is why we start coding on day one of any integration project, before any technical work and before the system choice is settled. It is the longest task, and it is entirely independent of whichever ERP you end up running. For a services company with a short item list it is an afternoon. For a distributor or retailer with thousands of SKUs it is routinely the single largest line in the project — and the one that reveals a product master nobody has looked at in years.

Signing: a specific format and a real throughput ceiling

Each document is serialised into ETA's canonical form, hashed, and signed with a detached CAdES-BES signature. The published specification is SHA-256 with RSA — not ES256, not ECDSA. This is not something to guess at: a subtle deviation in how the document is serialised makes signature validation fail, and it is among the most confusing first errors to debug because the message does not point at the offending field.

Signing also needs a physical device: an HSM or a token from a licensed certification authority. And here is a number worth putting into your plan early — ETA's own guidance rates a USB token at roughly 1.5 signatures per second. That is perfectly fine for an office issuing dozens of invoices a day, and not fine for a retail chain issuing thousands of documents in a peak hour. Choosing the device is a capacity decision, not a purchase. And because it involves a third party with a lead time, ordering it late is the second most common cause of delay in these projects after coding.

"ETA approved" describes something that does not exist

Many vendors in the market describe themselves as approved, accredited or certified by the Tax Authority. ETA has publicly denied it: it states that no software and no intermediary company has been approved as a service provider through which invoices may be sent, other than one licensed company, and that it takes no responsibility for dealings with anyone claiming otherwise. There is no approved-systems list to be on, because there is no approval.

What ETA does explicitly describe as permitted is the ordinary case: an accounting or ERP system owned by the taxpayer and modified to integrate with the published APIs. Its own FAQ adds that this requires no additional software or hardware licences.

The distinction has a sharp edge worth knowing before you sign a contract. Middleware that uploads invoices on the taxpayer's behalf is treated as outside the law. A system running under your registration and your credentials is squarely inside it; a bureau service submitting from its own tenancy is not the same thing, whatever the sales deck calls it. So the question to put to any vendor is simple: whose credentials are my invoices submitted under?

Is Odoo or ERPNext compliant on install?

No, neither is. But the two are not equally unready, and it is only honest to say so plainly.

Odoo ships a first-party Egyptian fiscal localisation, maintained by Odoo itself, including an ETA e-invoice integration module. ERPNext has no ETA integration in its core at all; what exists are community apps installed on top of it, the most mature of which requires an ITIDA-certified HSM, while the request for native support in the product has been open since 2022 without being delivered.

That asymmetry favours Odoo on this specific point, and we state it as it is. BDC implements both Odoo and ERPNext, is an official partner of neither, and takes commission from neither. We have no interest in tilting the comparison beyond what the facts require.

Even so, a localisation does not make you compliant. Odoo's own documentation is explicit that you must obtain the signing token, register your system on the ETA portal to get the client ID and secrets, and code your products yourself. The product handles the conversation with the API; everything that makes the conversation succeed — coding, units of measure, tax types, reconciling acceptance and rejection statuses — is implementation work. If you are still choosing between the two, the wider comparison is in our practical Odoo versus ERPNext comparison, and the delivery detail for each is on our Odoo implementation and ERPNext implementation pages.

If you sell to consumers: a second project, not an extension

The e-receipt system belongs to the point of sale, and it differs technically from the invoice system: receipts are submitted in signed batches, and each till keeps its own chain in which every receipt references the previous one from that same terminal. In this context your POS estate is not an accessory to your accounting system; it is an independent party with its own registration and its own behaviour.

So the first practical question for retail and restaurants is whether your point of sale is connected to your accounting at all, or is an island whose data is exported by hand at close of day. The answer sizes the work before ETA even enters the conversation — we set out the difference in what changes when your POS talks to your accounts. And for retailers starting from scratch, we built Dokani, our point-of-sale and stock system, to be connected to accounting from day one rather than wired up afterwards.

Why you will not find penalty figures here

This section is short but deliberate. Specific penalty amounts for not joining the system circulate widely in the Egyptian market, copied from article to article until they look documented. We looked for them on ETA's pages and could not find them published there in a form we could cite, so we do not repeat them.

What is actually stated is enough. ETA's published position is that failing to issue electronic invoices and receipts is dealt with within the tax evasion provisions of the Unified Tax Procedures Law, not as a minor administrative slip. Alongside that sit commercial consequences that bite sooner than any fine: costs and expenses not recognised, VAT that cannot be deducted or reclaimed, and dealings with government bodies blocked. Those alone explain how fast compliance spreads through a supply chain — a supplier who is not on the system is a supplier whose invoices your customer's accountant cannot use.

The order that works

1. Start coding immediately: before any technical work and before the system decision. With a large item list, separate early what will take a GTIN from what will need EGS approval.
2. Order the signing device the same day: in parallel. Size it against your peak issuance, not your average.
3. Register and obtain credentials: the client ID and two secrets from the taxpayer portal, in your own name.
4. Map the document types: invoices, credit and debit notes, exports, branches — plus units of measure and tax types onto ETA's code tables.
5. Prove everything in preproduction: every document type you actually issue, including the awkward ones nobody remembers until they appear.
6. Go live, then watch the statuses: name who reviews rejected documents and how often. An integration that submits but is never reconciled is a compliance gap with a green light on it.

In summary

The Egyptian system is clearer than it looks; what is written about it is not. The practical summary in four sentences: the 200-invoice rule is two conditions rather than one, and owning a system obliges you to integrate at any volume. E-receipt is a second system with no revenue threshold. Coding and the signing device are what actually delay these projects, not the choice of ERP. And there is no "ETA approved" system you can buy your way to compliance with.

For a longer map with the ETA sources linked directly, all of the above is set out in more detail on our page covering Egyptian Tax Authority e-invoicing in Odoo and ERPNext, which carries the date it was last checked against ETA's own pages.