Your accountant tells you that invoices now have to reach the Tax Authority electronically. You call the company that supplied your software and are told, reassuringly, that the system supports e-invoicing. Six weeks later the finance team is still printing invoices, keying them a second time into a government portal by hand, and arguing about why forty items in the catalogue will not save.
"We support e-invoicing" is not a feature. It is a claim about six separate things, and a supplier can believe all six are handled while only two of them are. What follows is what Egypt's electronic invoice and electronic receipt systems actually require of a business's software, which part of the work is a data problem rather than a software problem, and what to ask before you accept anyone's answer.
Two systems, not one
The Egyptian Tax Authority runs two related things that get collapsed into a single phrase.
- The electronic invoice (e-invoice) covers documents issued between registered businesses, and to government bodies.
- The electronic receipt (e-receipt) covers sales to the end consumer, issued from a point of sale.
They share a family of schemas, the same signing mechanism, and the same idea of validation at the authority. They differ in what must be registered, in what the customer receives, and in what your system has to do at the moment of sale. A company with retail branches and a wholesale arm needs both, and they are two pieces of work rather than one.
The legal footing is the Unified Tax Procedures Law (Law 206 of 2020) and the decisions issued under it, which oblige a registrant to issue an electronic tax invoice or an electronic receipt when selling a good or supplying a service. Deadlines have moved more than once and the covered population has widened in stages, so rather than fix on a date that will be wrong shortly, take the general position: if you are registered, the obligation is already yours or will be, and paper is no longer accepted as support for a deductible cost or for input tax. That last consequence is what actually changes behaviour. Your customers will demand a valid electronic document from you, because without one they cannot deduct.
What a compliant document actually is
It is not a PDF, and it is not an invoice attached to an email. It is a structured document — JSON or XML built to the authority's own schema — carrying, at minimum:
- identification of issuer and receiver, including tax registration numbers;
- every line item bearing a code from an approved coding system: a GS1 global product classification code, or a code registered for your own items under the Egyptian coding system;
- a tax breakdown per line, using the tax types, subtypes and units the schema defines;
- totals that reconcile exactly, to the rounding rules the schema specifies;
- a digital signature applied with an electronic seal certificate issued by an accredited certification authority.
The document is then submitted, validated, and returned with a unique identifier the authority assigns. Until that happens it is not issued in the authority's eyes, however respectable it looks on paper.
Two consequences follow immediately, and both surprise people.
The first is that your invoice number is no longer the identifier that matters. Three identifiers now coexist: your internal number, the authority's identifier, and — in a rejection or a credit note — a reference back to the original document. A system that stores only an invoice number has to store and search all three, because all three are what gets asked for.
The second is that the invoice has become data before it is a document. Anything your team used to correct by typing over a printed layout — a discount explained in a free-text note, a customer name spelled whichever way — now has to be right in a field, in a form the schema will accept.
The long pole is your catalogue, not your software
The most common reason this takes three months instead of three weeks has nothing to do with programming. It is that nobody has codes for the items.
Every line has to carry an approved code. Traded goods can often be mapped to the GS1 classification. Everything else — services, assembled products, anything particular to your business — is registered under the Egyptian coding system against your own registration, and receives codes that way.
Which means somebody inside your company has to go through the catalogue item by item and decide what each thing actually is. Businesses discover at this point that the same product appears three times under three spellings, that units of measure were never applied consistently, and that a third of the list has not been sold in four years. None of that is the supplier's work and no quote covers it. Plan the staff time, and start it while development is still running rather than after.
The software takes a month. The catalogue is the project.
A second data problem sits beside it. A business-to-business document needs the buyer's registration details, correct. If your customer file has been filled in casually for ten years, that is a cleaning exercise and a round of telephone calls, and it belongs to you as well.
How the integration actually works
The mechanism is published by the authority, and it is worth understanding at the level of what has to exist, because that is what tells you whether a supplier is quoting for the whole job.
- The company registers a profile with the authority and creates an administrator account on its platform.
- Every system that will submit documents is registered separately — the accounting or ERP system, and each point-of-sale device, identified by serial number and tied to the registration number and to the branch it stands in.
- Each registered system is issued credentials of its own.
- The company obtains an electronic seal certificate from an accredited certification authority. Where that certificate lives matters more than it sounds. A USB token works when a person is present to sign a few documents. A system that signs continuously, across branches, unattended, needs the certificate in a hardware security module or an approved signing service. Choosing the token because it is cheaper and simpler is a decision the counter staff feel every day after go-live.
- At run time the system authenticates against the authority's identity service, receives a session token, builds the document, signs it, and submits it over a protected channel.
- The authority validates and either accepts — returning the identifier and a status — or rejects with errors. Status can be polled, or received through notification callbacks.
None of that is exotic. What makes the difference between a system that works and one that merely sends is everything underneath.
The hard part is failure
A sale and a submission are two different events. Building as though they were one is the most common way this goes wrong.
At the counter there is a customer waiting. The line may be down, the authority may be slow or unreachable, the signing device may be busy, the document may come back rejected because a code was wrong. If your system makes the sale wait for the authority, your shop stops when the internet does. If it lets the sale proceed, you now own a queue — and a queue has to be built properly:
- Durable, not in memory. A submission waiting its turn must survive a restart, a crash and a power cut.
- Retried with backoff, and exactly once. A retry that sends the same sale twice creates a duplicate at the authority, which is considerably harder to undo than to prevent.
- Visible. Someone in finance needs a screen showing what is pending, what failed and why — in sentences, not error codes — and a way to resubmit once the cause is fixed.
- Reconciled. Once a day, what your ledger says you issued and what the authority holds should be compared, and the difference should be zero or explained.
- Aware of the clock. A buyer can reject a document, and a seller can cancel one, only within limited periods; after that the correction is a credit or debit note rather than a cancellation. Your system has to know which operation is still available, and your team has to see the time remaining.
That last point is where a great many "compliant" systems are quietly not. They can send. They cannot tell you what became of what they sent.
Four ways to become compliant
| Route | What it suits | What it costs you | Where it breaks |
|---|---|---|---|
| Key documents into the authority's own portal or app | A small registrant issuing a few documents a month | Staff time per document, and a second place where your numbers live | The moment volume rises or a second branch opens |
| A middleware provider between your system and the authority | A business with an existing package that has no module and no appetite to change it | An ongoing service relationship, and your invoice data passing through a third party | Middleware cannot invent a code your data model never produced |
| A compliance module for the package you already run | A business already standardised on a mainstream accounting package | Depends entirely on whether the module is maintained by the vendor or by a partner | Upgrades — an unmaintained compliance module ages badly |
| Built into your own system | A business whose invoicing is genuinely part of its operation, or one already running a custom system | Development, plus responsibility for keeping up with schema changes | Nothing, while it is maintained; everything, once the people who built it are gone |
Worth saying plainly: if you issue a handful of documents a month, the first row is the right answer and no software project is justified. That row is not the lesser option, it is the correct one for a large number of businesses, and a supplier who cannot say so is selling rather than advising.
What to ask a supplier who says they support it
- E-invoice, e-receipt, or both? Open each one and show me.
- Which document types — invoice, credit note, debit note, export, and the receipt types we issue?
- Where does signing happen — token, hardware module, or a signing service — and what happens when it is unavailable?
- Show me the pending queue. What does finance see when a submission fails?
- The internet at a branch is down for an hour. Walk me through what happens at the till, and what happens afterwards.
- When a document is rejected, who learns of it, how, and what is the path to fixing it inside the system?
- How does the system handle a buyer rejecting a document, and the cancellation window?
- How are item codes stored and mapped, and who maintains them when we add products?
- When the authority changes the schema or adds a required field, who updates this, under what agreement, and how fast has that happened before?
- Show me the reconciliation between our ledger and what the authority holds.
Questions five, six and nine separate suppliers who have run this in production from suppliers who have read the documentation. For the rest of what to check before signing, how to choose a software company covers the ground.
It is an accounting question before it is a compliance question
Compliance is the visible part of something larger: the authority now holds a structured copy of your sales. Anything your books cannot explain is visible from outside them.
That raises the standard for whatever sits underneath. Invoices that post to entries rather than living in a separate list of invoices. Tax computed as part of the entry that records the sale, not added in a spreadsheet at month end. Periods that close and stay closed. Inventory that moves with the entry that caused it to move. A business running on a spreadsheet and a printer can be made to emit compliant documents and still be unable to answer the first question that follows from them.
If the system you have cannot do those things, the e-invoicing requirement is the occasion rather than the problem. What a custom system costs covers what drives the number if you decide to replace rather than patch, and ready-made ERP or a custom system covers the decision this usually forces alongside it.
Where to start
Start with the catalogue and the customer file, because they sit on the critical path whatever you end up building, and because they are yours to do. Softwiro builds accounting systems on double entry, with tax handled inside the entry rather than beside it — contact us if you want the compliance path for your business written down before anyone prices a build.