An e-invoice in Egypt is a tax document your company issues in a signed digital format and sends to the Egyptian Tax Authority's system at the moment of issue, where the system checks its data and registers it before it counts. You have two ways to issue it: enter invoices by hand on the system's portal if you issue only a few, or connect your accounting system or ERP to the official APIs so that every invoice is sent automatically. Either way, success depends on the quality of your data before the technology: item codes, customer tax numbers and the signing certificate.
This guide explains who must use the system, compares the available issuing methods in one table, and sets out what your system needs before integration and the integration steps themselves. It then covers cancellations and rejections, and ends with a pre-go-live checklist and how we work on this at HBS.
What is e-invoicing in Egypt and who must use it?
As things stand (November 2026), the Egyptian Tax Authority (ETA) runs two linked systems: the e-invoice for business-to-business transactions, and the e-receipt for sales to end consumers. E-invoicing was rolled out in phases until Decision No. 323 of 2022 required every registered taxpayer without an earlier mandate to issue invoices electronically from 15 December 2022. The e-receipt is imposed through decisions that name the taxpayers in each phase, and you can check your own position through the ETA e-receipt obligation inquiry service.
The same decision sets the basic technical requirements: an e-seal certificate for signing, item coding under GS1 or EGS, and then either integrating your system with the platform or using its portal if you have no invoicing system. If you want to automate what happens after issue, such as invoice matching and reconciliation, we covered that in our guide to AI for finance and e-invoicing.
What are the ways to issue e-invoices from your company?
The choice depends on how many invoices you issue each month and on the system you issue them from today. This table sums up the common options:
| Method | Who it suits | What you need | Main risks |
|---|---|---|---|
| Manual entry on the ETA portal | A company that issues few invoices and has no invoicing system | A portal account, a signing certificate and item codes | Data-entry errors and duplicated work between the portal and the accounting software |
| Ready-made accounting software with built-in integration | A company with standard processes using software that genuinely supports the system | Setting up the integration inside the software and reviewing item codes and customer data | Dependence on the vendor for every update the system requires |
| ERP or custom system integration via API | A company that issues invoices from its own system or in large volumes | A signing, submission and status-tracking module tested on the official test environment | Weak error handling and no tracking of each document's status |
| A middleware layer across several systems | A company that issues invoices from more than one source, such as a sales system and an online store | Standardising data from every source before signing and submission | Conflicting numbers between sources if clear rules are missing |
If you are still deciding between ready-made software and a custom system in the first place, make e-invoicing support a fixed criterion in the comparison we set out in custom system vs ready-made software.
What does your system need before connecting to the e-invoicing platform?
Most delays in integration projects do not come from writing code. They come from data and procedures that were not ready. Prepare these items before any developer starts:
- A taxpayer account on the platform. The official developer portal starts with registering the taxpayer profile and then the administrator account, which invites other representatives and registers ERP and POS systems.
- System access credentials. When you register your system you receive API access credentials that are configured inside the system and used at every login, so treat them like sensitive passwords.
- An e-seal certificate. As things stand (November 2026), the issuer must digitally sign every document with an X.509 certificate, and that signature is what proves the invoice came from you and was not altered afterwards.
- Item codes. Every item or service on an invoice needs a GS1 code or an internal EGS code that your company registers on the platform. Start early, because a long item list takes time to review and approve.
- Customer data. The tax registration number and full address of every business customer, data that is missing in most older systems.
- Reference tables. Activity types, tax types, units of measure, branches and currencies are all defined in the official code tables, and your system must use them exactly as published.
How does e-invoice integration via API work, step by step?
The platform's APIs are REST-based and exchange data in JSON, and documents can be in JSON or XML. In a well-integrated system, each invoice follows this sequence:
- Log in and get a session token. Your system calls the identity service and receives an access token for the following requests. As things stand (November 2026), the official integration practices recommend keeping the token for its default lifetime of 60 minutes instead of requesting a new one for every call.
- Build the document from system data. Seller, buyer, item and tax data are assembled in the required format, and the system checks they are complete before anything is sent.
- Sign. The document is signed with your company's e-seal certificate.
- Submit. One document or a batch of documents is sent in a single request, and the platform returns an ID for that submission.
- Wait for the result. Part of the processing happens later, not instantly. The recommended approach is for your system to expose an endpoint that receives the platform's notifications when each document's status changes. Polling the submission status is the second option, because it adds load on your system.
- Update the internal record. Your system stores each invoice's status and its platform reference next to the original invoice, so the accountant sees on one screen what was accepted, what was rejected and why.
One of the most important rules in the practices guide is that you resubmit only when the submission APIs return an error. Resending a document that was already accepted is automatically flagged as a duplicate submission, and repeated resubmission can lead the platform to throttle your requests. Your system therefore needs clear retry logic and a log of every attempt.
How do you handle cancellations, rejections and corrections after submission?
As things stand (November 2026), an accepted invoice is never deleted or edited. It is managed through specific actions offered by the e-invoicing APIs:
- Cancellation by the issuer. Allowed within a period the ETA sets for each document type in line with the law. Once that period ends, the invoice is corrected with a credit note based on the original invoice.
- Linked documents. You cannot cancel an invoice that another document, such as a credit note, refers to until you cancel that document first.
- Rejection by the recipient. Your customer can reject an invoice they consider incorrect, the issuer can decline that rejection, and the recipient can likewise decline a cancellation.
- Notifications. Acceptance, rejection and cancellation events reach your system if you provide a notification endpoint, which is what keeps an invoice's status in your system matched to its status on the platform.
In practice, agree with your sales and finance teams on who holds the right to cancel, who reviews rejected invoices every day, and what the approved action is in each case.
What are the common mistakes in e-invoice integration projects?
- Treating the integration as a purely technical task. Integration exposes every gap in item and customer data, and without cleaning it the platform will reject many invoices.
- Requesting a new login token for every invoice. This goes against the official practices and slows submission down.
- Unconditional automatic resubmission. It creates duplicate submissions and can get your requests throttled.
- Stopping at a successful submission. An accepted request does not mean every invoice in it is valid, because the final status of each document arrives later.
- Ignoring credit notes and returns. Many systems are built for the invoice alone and then stumble at the first return.
- Leaving the certificate and credentials with one person. Any absence of that person stops invoicing across the whole company.
What should you test before going live?
As things stand (November 2026), the ETA provides a test environment separate from production, with its own internally issued certificates, and the developer FAQ warns against installing its root certificate on production machines. Run this full list on the test environment before your first real invoice:
- A standard invoice to a business customer with every tax type you actually use.
- A credit note and a debit note linked to an earlier invoice.
- An invoice in a foreign currency if you sell in anything other than Egyptian pounds.
- Cancelling an invoice and confirming the notification reaches your system and updates its status.
- A deliberately wrong invoice to confirm the error message reaches the user in words they understand.
- A dropped connection during submission to confirm the system does not send the invoice twice.
- A month-end reconciliation between the total invoices in your system and what the platform shows.
How does HBS approach e-invoice integration?
At HBS we start from the source of the invoice, not from the platform. We map where your invoices come from today, who issues them and the state of your item and customer data, then recommend the right method from the table above. Sometimes the answer is that your current software is enough once it is set up properly, and we say so plainly. If you need a custom integration, we design a separate module for signing, submission and status tracking, test it on the official test environment before go-live, and hand over its documentation.
An example from our work shows why data comes before integration. In the LDY CMS dashboard we built for Labib Demian Youssef & Co., the sales team issues quotes from a single product catalogue, with line items, discounts, 14% VAT as things stand (November 2026), and payment and delivery terms, and accepted quotes move on to sales orders, all under a permissions matrix and a full audit log. That kind of structured data, one item with one code, one customer with one record, and every change logged against the person who made it, is the foundation any successful e-invoicing integration needs.
Legal details and fees in this article reflect the situation in November 2026 and may change; check the official source before you decide.
If your company is required to issue e-invoices and you are not sure where to start, or your current integration keeps throwing errors, tell us how you issue invoices today and from which system. Our team will sit down with you in a free discovery session and recommend the method that fits, and you can learn more about HBS API and systems integration services.
