Registration and credentials
The company registers on the e-invoicing system and creates the ERP's credentials on the taxpayer portal — a client ID and two client secrets that the integration authenticates with.
Egypt · Egyptian Tax Authority · e-invoice and e-receipt
Egyptian Tax Authority e-invoicing, in Odoo and in ERPNext
Egypt gives a taxpayer two ways to comply: key documents into the ETA taxpayer portal by hand, or integrate a system with ETA through the published SDK, submitting each document signed and coded to ETA's API. Which one you may use is not a preference — ETA allows portal entry only for a taxpayer who has no ERP or invoice-issuing program at all and issues no more than 200 invoices a month, on a request their tax office approves. Coding applies either way: every item needs a GS1 GTIN or an internal EGS code registered on the portal before it can appear on an invoice. And the Tax Authority accredits no ERP — it has said publicly that no software or intermediary company is approved as a service provider — so any system integrated by the taxpayer against the published SDK is authorised, and neither Odoo nor ERPNext does that on installation.
The short version
The e-invoice system covers what you sell to other businesses and to government. It has applied to all ETA-registered taxpayers since 15 December 2022, and from 1 July 2023 the commercial consequence acquired teeth: proving deductible costs and deducting or reclaiming VAT depend on holding an electronic invoice. A supplier who is not on the system is a supplier whose invoices your accountant cannot use — which is why compliance spreads down a supply chain faster than any deadline pushes it.
The e-receipt system covers what you sell to end consumers. It is a separate system with a separate registration, established by decree in 2022 and extended in 2024, and ETA has rolled it out by naming sectors and areas — restaurants and cafés, health and telecoms, retail chains, supermarkets — rather than by setting a revenue threshold. Your obligation arrives by being named in a decision, so the thing to check is the list, not your turnover. If you sell both ways, you have two projects, not one.
Underneath both is the ETA SDK: the published documentation for the APIs a taxpayer's ERP or POS uses to register its documents. It is open, public and free to read. That is what makes the Egyptian market different from the Saudi one — there is no vendor directory to be listed in, because ETA does not accredit systems at all. It accepts documents that are correctly formed, correctly signed and correctly coded, from whatever produced them.
BDC implements both Odoo and ERPNext, is an official partner of neither, and takes commission from neither.
Portal or integration — and what each obligation requires
The volume threshold, the two routes and the coding rule, in the one place on this page that has to be re-checked when ETA moves. Read the row that describes you and the coding row, which applies to everyone.
| Obligation or route | Who it applies to | What it requires |
|---|---|---|
| B2B and B2G e-invoicing | Every company invoicing other businesses or government bodies | Mandatory for all ETA-registered taxpayers since 15 December 2022. From 1 July 2023, proving deductible costs and deducting or reclaiming VAT depend on holding an electronic invoice |
| The ETA taxpayer portal | Only a taxpayer who has no ERP or invoice-issuing program AND issues no more than 200 invoices a month — both conditions, not either | A written request on ETA's form, approved by your tax office. Owning an ERP at all obliges you to integrate, even below 200 |
| ERP or POS integration via the ETA SDK | Any taxpayer above portal volume, and anyone who already runs an ERP and will not key invoices twice | A client ID and two client secrets issued on the ETA portal, a signing device, and a system that submits signed documents to the ETA API |
| E-receipt, for sales to consumers | Only taxpayers named in an ETA phase decision, by sector and area — restaurants and cafés, health and telecoms, retail chains, supermarkets and so on. There is no revenue threshold | A separate registration and system under Decree 230 of 2022, as amended by Decree 38 of 2024. The most recent decision we found was 361 of 2025, opening the ninth phase |
| Item coding — required on every route | Every taxpayer issuing documents, whether through the portal or through an integration | A GS1 GTIN is usable as soon as it is registered on the portal. An internal EGS code (format EG-TaxRegistrationNumber-InternalCode) must be approved by ETA before any invoice may use it |
Checked against ETA's own pages on 2026-08-08. The 200-invoice rule is not folklore: it is the declaration a taxpayer signs on ETA's portal-issuance request form, and it is a two-part test — no ERP or invoice-issuing program, and no more than 200 invoices a month. Owning an ERP obliges you to integrate regardless of volume, and ETA reserves the right to act if the declaration proves untrue. Two caveats we would rather state than hide: ETA announced the deduction rule twice, first for 1 April 2023 and then for 1 July 2023, and we could not find a decree text fixing either — the later date is the one ETA has repeated since. And the number of days you have to upload a document after issuing it has been changed more than once; check ETA's news before relying on a figure for it.
What an ETA integration actually involves
The parts of the work, in roughly the order they bite. None of them is difficult on its own; the schedule risk is that several of them depend on someone outside your company.
The signing device
ETA requires a hardware security module or token from a licensed certification authority. Size it deliberately: ETA's own guidance puts a USB token at roughly 1.5 signatures a second, which is fine for an office and not fine for a busy retail chain.
Item coding
Every item needs a GS1 GTIN or an internal EGS code. The difference matters to your schedule: a registered GTIN can be used immediately, while an EGS code sits in a pending state until ETA approves it. For thousands of SKUs this is the largest single task.
Units, taxes and tax types
ETA has its own code tables for units of measure and tax types, and your document lines must map onto them. Existing item data almost never maps cleanly on the first pass.
Document structure and signing
Each document is serialised to ETA's canonical form, hashed with SHA-256 and signed as a detached CAdES-BES signature — the published spec is RSA with SHA-256, not ECDSA. Get the serialisation subtly wrong and the signature fails validation, which is a confusing first debug.
Submission and status handling
Documents are submitted in batches and accepted, rejected or held. A real integration has to reconcile ETA's status back onto the invoice in the ERP, not just fire and forget.
Preproduction first
ETA provides a test environment. Everything above is proven there before a single real document is submitted, because a wrongly submitted document is a correction problem, not an undo.
E-receipt, if you sell to consumers
A separate registration and a separate integration for point-of-sale, following ETA's phase decisions. Plan it as its own project rather than an extension of the invoice work.
The claim worth checking
ETA accredits no ERP. There is no approved list to be on.
Vendors in the Egyptian market describe themselves as approved, accredited or certified by the Tax Authority. ETA has publicly denied that any of it is true. It states that no programs and no intermediary companies have been approved as a service provider through which invoices may be sent, other than one licensed company, and that it is not responsible for dealings with anyone claiming otherwise. There is no approved-ERP list because there is no approval.
What ETA does say is authorised is the ordinary case: an accounting or ERP system owned by the taxpayer, modified to integrate with the published APIs. Its own FAQ adds that this requires no additional software or hardware licences at all. Your ERP is simply one of your registered delegates on your digital profile, submitting under your credentials.
That distinction has a sharp edge worth knowing before you sign anything. ETA treats middleware that uploads invoices on a taxpayer's behalf as outside the law. A system running under your own registration and your own client credentials is squarely inside it; a bureau service submitting from its own tenancy is not the same thing, whatever the sales deck calls it. Ask which one you are buying.
So the choice of ERP in Egypt is not a compliance decision. It is an operations decision — and that cuts against our interest as much as anyone's. The real compliance risk is unregistered item codes, an expired signature certificate, rejected documents nobody is watching, and a POS estate never brought into the e-receipt system. All implementation and operations. No product removes them.
"No programs or intermediary companies have been approved as a service provider through which invoices can be sent to the e-invoicing system, except through E-Tax only." ETA adds that relying on intermediary systems that submit on the taxpayer's behalf is a breach of the law, while an ERP owned by the taxpayer and integrated with the system is "a permitted procedure and one of the approved ways of issuing invoices".
Egyptian Tax Authority statement, eta.gov.eg. Translated from the Arabic original; read 8 August 2026.
What each system gives you, and what it does not
An honest starting position for a selection decision. Neither product is compliant on installation, and in Egypt the difference between them is smaller than the difference between two implementations of the same product.
| Area | Odoo | ERPNext |
|---|---|---|
| Where the localisation comes from | An Egyptian fiscal localisation maintained by Odoo, with a dedicated ETA e-invoice integration module. | Community and vendor-maintained ETA apps installed on top of ERPNext. Check which one is current and who is maintaining it. |
| Out-of-the-box compliance | No. Odoo's own documentation is explicit that you must obtain the signature token, register the system on the ETA portal for credentials, and code your products yourself. | No, on the same terms, with the extra step of choosing and validating the app before you depend on it. |
| Item coding | The localisation gives you a field for the ETA item code. Filling it correctly for every product is your work either way. | The same. The coding effort is identical because it is an ETA requirement, not a product feature. |
| E-receipt and point of sale | Depends on the release and the module scope; treat it as a separate piece of work to be scoped, not an assumption. | Usually bespoke or app-dependent. Scope it explicitly before committing to a date. |
| What is always on the implementer | Credentials, signing device, coding, unit and tax mapping, status reconciliation, preproduction testing, and training. | The same list, unchanged. This is the part no product removes. |
Both products change between releases. Verify the current state of the localisation for the exact version you intend to run, and ask to see it submitting a document to ETA's preproduction environment rather than taking a feature list on trust.
How we run an ETA integration
The sequence matters more than the tooling. Most Egyptian e-invoicing projects that miss their date miss it on coding or on the signature device, both of which are started too late.
Start the coding immediately
Before any technical work, we begin GS1 or EGS coding for the item master, because it is the longest task and it is entirely independent of which ERP you end up running.
Order the signature device
On day one, in parallel. It involves a third party, it has a lead time, and no document can be submitted without it.
Register and get credentials
Register on the e-invoicing system and create the client ID and secrets for the ERP on the taxpayer portal.
Map the document types
Invoices, credit and debit notes, exports, branches, and units of measure and tax types onto ETA's code tables. This is where existing data is found wanting.
Prove it in preproduction
Submit every document type you actually issue against ETA's test environment until each one is accepted, including the awkward ones nobody remembered.
Go live, then watch the statuses
Handover includes who checks rejected documents and how often, because an integration that submits but is never reconciled is a compliance gap with a green light on it.
Sources
Every claim above comes from one of these. Where a fact is reported rather than read off an ETA page, this page says so at the point it is used.
- ETA — your guide to the e-invoicing systemhttps://eta.gov.eg/ar/content/e-invoice-services
- ETA — integrating with the e-invoicing systemhttps://www.eta.gov.eg/ar/content/altkaml-m-mnzwmt-alfatwrt-alalktrwynt
- ETA — item coding, including the EGS and GS1 registration routeshttps://www.eta.gov.eg/ar/content/altkwyd
- ETA — request form for issuing invoices through the portalhttps://eta.gov.eg/sites/default/files/2023-01/portal-form.pdf
- ETA — no software or intermediary company is approved as a service provider except E-Taxhttps://eta.gov.eg/ar/news/mnzwmt-alfatwrt-alalktrwnyt-11
- ETA — e-invoicing solution FAQ: integrating an ERP requires no additional licenceshttps://www.eta.gov.eg/sites/default/files/2021-09/e-Invoicing%20Solution%20FAQs.pdf
- ETA — the eInvoicing and eReceipt SDKhttps://sdk.invoicing.eta.gov.eg/
- ITIDA and ETA — digital signature format for the e-invoice system (CAdES-BES)https://www.eta.gov.eg/sites/default/files/2021-09/Digital%20Signature%20Format%20V1.1_final_0.pdf
- ETA — electronic signature, including the cryptographic hardware guidance and the licensed CAshttps://www.eta.gov.eg/ar/content/altwqy-alalktrwny
- ETA — updates to the coding procedure on the portal, April 2021 (the GTIN and EGS approval rules)https://eta.gov.eg/sites/default/files/2021-09/coding.pdf
- ETA — e-receipt obligation decisions, phase by phasehttps://www.eta.gov.eg/ar/content/qrarat-alalzam-baltaml-balaysal-alalktrwny
- ETA SDK — the document submission APIhttps://sdk.invoicing.eta.gov.eg/einvoicingapi/01-submit-documents/
- ETA — your guide to the e-receipt systemhttps://eta.gov.eg/ar/content/e-receipt-services
- ETA — Decision 361 of 2025, first sub-phase of the ninth e-receipt phasehttps://eta.gov.eg/en/node/1294
- Odoo documentation — the Egyptian fiscal localisationhttps://www.odoo.com/documentation/19.0/applications/finance/fiscal_localizations/egypt.html
Last checked against these sources on 2026-08-08
Questions we are actually asked
Direct answers to what Egyptian finance and IT teams ask before starting an ETA project.
Does the Egyptian Tax Authority approve or accredit ERP systems?
No. ETA has publicly stated that no programs and no intermediary companies have been approved as a service provider for sending invoices to the system, other than one licensed company, and that it is not responsible for dealings with parties claiming otherwise. Its own FAQ says integrating an ERP requires no additional software or hardware licences. There is no approved-vendor list to be on. A supplier calling itself "ETA approved" is describing something that does not exist as an ETA process.
Can we just use the ETA portal instead of integrating?
Only if you meet both halves of ETA's test. Its portal-issuance request form has the taxpayer declare that they have no ERP or invoice-issuing program and that they issue no more than 200 invoices a month. Both, not either — if you own an ERP at all, you are obliged to use it for issuing regardless of volume. It is also not self-service: the request goes to your tax office for approval, and ETA reserves the right to act if the declaration turns out to be untrue.
Is Odoo or ERPNext compliant with ETA out of the box?
No, neither is. Odoo ships an Egyptian localisation with an ETA integration module, and ERPNext has community and vendor-maintained apps. In both cases the documentation is explicit that you must obtain the electronic signature device yourself, register the system on the ETA portal to get your client ID and secrets, and code every product with a GS1 or EGS code. The product handles the API conversation; everything that makes the conversation succeed is implementation work.
What is the item coding requirement, and how big is it really?
Every item must carry either a GS1 GTIN or an internal EGS code, registered on the taxpayer portal before it can be used on a document. The two routes behave differently and this affects your schedule: a GTIN can be used as soon as it is registered, while an internal EGS code is created in a pending state and cannot be used until ETA approves it. For a services company with a short item list this is an afternoon. For a distributor or retailer with thousands of SKUs it is routinely the largest task in the project, which is why we start it first — it depends on no technical decision.
How is the e-receipt system different from e-invoicing?
E-invoicing covers sales to businesses and government and applies to every registered taxpayer. E-receipt covers sales to end consumers at the point of sale and applies only if you have been named in a phase decision by sector and area. They also differ technically: receipts are submitted in signed batches within a 24-hour window, and each till maintains its own chain, every receipt referencing the previous one from that same terminal. Separate registration, separate portal, separate work. If you sell both ways, budget for two projects.
What are the penalties for not being on the system?
ETA's published position is blunt: failing to issue electronic invoices and receipts is treated as tax evasion under the Unified Tax Procedures Law, not as an administrative slip. Alongside that sit consequences that bite sooner — costs and expenses not recognised in your return, VAT not deductible or refundable, no import or export through the customs platform, and no dealings with government bodies. Specific figures circulate widely online; we have not found them stated on an ETA page, so we do not repeat them here.
Why do these projects slip?
Almost always for one of two reasons, and neither is the ERP. Item coding is started too late and turns out to involve cleaning a product master nobody has looked at in years. Or the electronic signature device is ordered late, and since nothing can be submitted without it, the whole schedule waits on a third party. Both are avoidable by starting them on day one, before the technical design is even finished.
Our invoices are being rejected by ETA. What is usually wrong?
In order of frequency: an item code that is not registered on the portal, a unit of measure or tax type that does not map to ETA's code tables, a customer tax registration number that is missing or malformed, and a signature that fails validation because the document was serialised slightly differently from ETA's canonical form. All four are fixable, and all four are found faster in preproduction than in production.
Can BDC certify us as ETA compliant?
No, and neither can anyone else, because ETA issues no such certificate to implementers. What we can do is code your items, configure and integrate the system, prove every document type in ETA's preproduction environment and hand over with documented training. BDC implements both Odoo and ERPNext, is an official partner of neither, and takes commission from neither, so which system we recommend is not decided by a licence we would earn on.
Find out how far you are from submitting
A short review of your item master, your document types and your current system, and a straight answer on how long an ETA integration would really take you.
Request an e-invoicing readiness review