Egypt E-Invoicing (ETA): How to Integrate Your System with the Tax Authority Portal (2026 Guide)

"How do I connect my system to the e-invoicing platform?" is a question we hear weekly from finance and IT managers in Cairo, Alexandria and Tenth of Ramadan — usually right after discovering that the accounting program they have run for years knows nothing about the Egyptian Tax Authority. A clerk prints the invoice, retypes it on the ETA portal, and two days later half the documents are rejected over a wrong item code or a one-piastre rounding difference.

This guide covers Egypt's e-invoice and e-receipt systems practically: the difference between them, how integration works from your system to the unique identifier (UUID) that comes back, your four options, where these projects really fail, and a go-live checklist. It is written for owners, finance managers and IT leads, not only developers.

At Jad Digital (جاد للتطوير الرقمي) we build custom ERP and accounting systems that integrate with the platform, and integration layers on top of existing systems for clients who would rather keep their software. One note first: the phases, obligated categories and compliance details change by decisions from the authority, so confirm your company's current status and obligations on the Egyptian Tax Authority's portal or through your tax office rather than on what a colleague told you last year.

The authority handles two different document types, each with its own platform and technical requirements. Confusing them is a common reason companies build something that does not fit their activity.

An e-invoice is a structured digital document — not a PDF or a scan — carrying seller and buyer details with their tax registration numbers, the lines with their codes, and the taxes and discounts. It is signed electronically and submitted before it counts as valid. Companies use it with other companies and with government entities, and the buyer relies on it to prove purchases and claim input tax. Plainly: your corporate customer will ask for a validated e-invoice, and without it your supply and collection cycle stalls.

The e-receipt is what a shop, restaurant, pharmacy or clinic issues to a walk-in consumer through a point-of-sale system. The logic differs: far more documents, much smaller values, submission usually in batches, and a QR code on the receipt so it can be verified. A company serving both audiences — a distributor with a retail outlet — needs both systems, not one.

• You can no longer issue a paper invoice and settle it later; the document becomes official the moment the platform accepts it.
• Every product and service needs a recognised code, and that alone is a data project before it is a software project.
• Corrections are no longer made with an eraser; you fix documents with a credit or debit note linked to the original.
• Your accounting system must track each document's state — submitted, accepted, rejected, cancelled — and show it to finance.
• The internal workflow changes: who approves an invoice, who may submit it, and who chases rejections.

Integration is not one button. It is a chain of six steps, and any weak link surfaces later as a wave of rejections.

It starts with your company account on the platform, under which you register the "ERP" that will submit documents. Registration produces credentials your system uses to obtain a short-lived access token before each submission. An early decision matters here: one system for the whole company, or one per branch or activity? That choice shapes permissions and your ability to trace errors once volumes rise.

Every line needs a code: a global GS1 code if your product is genuinely barcoded, or an internal EGS code registered and mapped to the authority's approved classification. This is the longest step in almost every project we have seen. A company with thousands of items in an old program, full of duplicates and inconsistent names, must clean its item list before coding it. Start on day one, in parallel with the technical work — otherwise the code is ready while the data is not.

No document is accepted without a signature from an accredited provider. Smaller companies use a USB token tied to one machine: simple, but it locks invoicing to one device and one person, and stops when that person is on leave. Multi-branch companies, or anyone sending thousands of documents, use an HSM or a central signing service so the server signs without human intervention. If you intend to automate fully, decide this early — it changes the architecture.

Your system builds the document in the required format: seller and buyer data, document and activity type, lines with codes, quantities and approved units of measure, taxes and discounts, plus currency and exchange rate for foreign-currency invoices. It is then signed and sent to the platform's API. Large multi-line invoices expose construction errors first, so test those early rather than a tidy two-line sample.

Submission is not the end. The platform validates and responds: accepted, accepted with warnings, or rejected with a stated reason. An accepted document gets a unique identifier (UUID) and a public verification link. Your system must store that identifier with the invoice and surface rejections on a daily working screen for finance, not bury them in a log nobody opens.

Returns, later discounts and corrections all happen through documents linked to the original by its unique identifier. There is also a window in which a document can be cancelled, or rejected by the other party, after which it is final. Your design must express these rules explicitly instead of letting an employee delete an invoice that was already issued and accepted.

You issue from your current program and key the document into the portal by hand. No development, and workable for a very small monthly volume. But it means double entry, a chance of error on every document, and a possible mismatch between your books and the authority's records. Any growth in volume makes it cost more time than it saves.

A layer reads approved invoices from your system's database or a structured export, converts them, signs and submits them, then writes back each document's status and identifier. This is the most common option for companies on an old or closed accounting program that cannot be modified. It does not touch the existing system or disrupt daily work; the drawback is maintaining two systems and updating the middleware whenever the specification changes.

Some ERP and accounting products in the Egyptian market ship with a ready module. Good if your operations are standard and you are willing to change systems. The decisive questions: is the module included or a separate subscription, who updates it when the specification changes, and does it support e-receipts too or only e-invoices? We compare the two approaches in ready-made vs custom accounting software.

Building integration inside a custom system — or a custom ERP that includes it from the start — fits when operations are not standard: instalment sales, contracts and progress billing, manufacturing with work orders, or contract pricing per customer. It also fits when invoices must be generated automatically by an existing system such as your online store or branch platform. We break that decision down in custom ERP vs off-the-shelf and deliver it as part of our ERP and business systems.

Ask three questions: how many documents do you issue monthly, can your current system be modified or does it expose an API, and who owns updates when the specification changes? Those answers settle the choice in most cases, and protect you from buying a solution bigger or smaller than you need.

The problem is rarely the code. These are the causes we have most often seen stall a project or trigger rejections right after go-live.

• Item codes that are not ready. Duplicates and descriptive names with no consistent coding mean repeated rejections. Cleaning and coding precede development.
• Non-standard units of measure. "Carton", "sack" and "bundle" are not standard units; every internal unit needs mapping to an approved one with a clear conversion factor.
• Rounding and tax calculation. A one-piastre gap between the sum of lines and the invoice total is a very common rejection. Calculate tax with one logic in one place, never re-implemented separately in the UI, the reports and the document.
• Incomplete buyer data. A corporate customer's tax registration details belong in the customer record, validated, not typed in a hurry at invoicing time.
• Timing and sequencing. Back-dated documents, submissions after the allowed window, or serials duplicated across branches are internal design problems, not integration problems.
• Cancelling with the old mindset. Finance teams are used to "editing the invoice" and need explicit training on credit and debit notes and on the cancellation window.
• Outages and submission queues. A serious solution queues documents, retries automatically and logs every response. Never assume the connection is up.
• Signing certificates expiring. Certificates expire, and an unnoticed expiry stops invoicing for a full working day. Set a renewal alert early and name an owner.

Before you rely on the platform during a real working day, confirm these points:

• The taxpayer profile is active, the system registered, and credentials stored securely — not in a file on someone's desktop.
• Every product and service is coded, and every internal unit of measure mapped to an approved one.
• Customer records are complete with the tax details required for corporate clients.
• The signing certificate works, the authorised person is named, and a backup exists when they are away.
• Every document type you genuinely issue is tested: standard invoice, discounted invoice, credit note, debit note, foreign-currency invoice, and export documents if any.
• A daily screen shows rejections and reasons, with a named owner who clears them.
• A written procedure covers a dropped connection or a rejection with a customer waiting.
• Backups of submitted documents and their identifiers exist independently of the system.
• Finance and sales are trained on the new sequence, not only on the screens.
• Your obligations and the phase applying to your activity are confirmed from the authority's portal, not from old information.

A company selling to distributors and retail chains, issuing hundreds of documents a month from an old accounting program that cannot be modified. The practical answer was middleware reading approved invoices from the program's database, converting, signing and submitting them, and writing the UUID and status back to a side table shown on a simple finance screen. The largest part of the project was not the integration — it was cleaning and coding an item list that had accumulated over years.

A factory selling wholesale under supply contracts and progress billing, where the invoice must link to the work order and to stock movement. Middleware was not enough, because the document must be generated by the workflow rather than copied into it. We built a custom ERP covering inventory, work orders and pricing with integration as a native part of it, connected to a customer management module for tracking orders and quotes — the idea we explain in what is a CRM system.

A clinic chain serves consumers, not companies, so its core need is the e-receipt tied to the booking and billing system, while handling insurance cases and contract pricing that make the receipt value differ from the listed price. What the clinic system itself needs is covered in clinic management systems in Egypt. The shared lesson: integration starts with your invoicing process, not with the API.

These questions quickly separate a vendor who has built integrations from one who promises them. The broader criteria for choosing a technology partner — references, process, ownership, transparency — are covered in our pillar guide on choosing the best software company in Egypt.

• Is integration included in the price or a separately billed module, and who pays for updates when the specification changes?
• Does the solution support both e-invoices and e-receipts, or only one?
• How does it handle credit notes, debit notes, returns, and the other party rejecting a document?
• What happens when the internet drops — is there a queue, automatic retries and a response log?
• Do we own the credentials, certificates and database, or are they in the vendor's name?
• Can we export every document with its identifier if we change vendors later?
• Who supports us on month-end closing days, and what response time is committed in writing?

Many clients sell in both markets and expect one solution. The principle is similar — a structured document, a cryptographic signature, submission to a government platform, validation — but the details differ completely: formats, signature type, the simplified-invoice and QR logic in Saudi Arabia, and the coding and validation rules. In practice that means one system with two separate compliance layers, not a modified copy of one. We covered the Saudi side in ZATCA e-invoicing and your ERP.

We start with a session over the real documents: a sample of every invoice and receipt type the company issues today, the item list exactly as it is with all its flaws, and a map of who issues, who approves and who reviews. From that we decide the right option — middleware over an existing system, or integration inside a custom one — and plan the coding work in parallel with development.

We then run on a test environment with real documents before go-live, and hand over with a rejection monitoring screen, a written procedure for exceptions, and training for finance on the new sequence. Credentials, certificates, database and source code stay in the company's name, not ours — a point to insist on with any vendor.