Egyptian e-invoicing: what it demands of the system you already run

The company has a system that works: invoices print, stock comes down, the accountant closes the month. Then issuing electronic invoices through the Egyptian Tax Authority system becomes an obligation on registered companies, so you ask whoever supplies your software, and the quote comes back proposing to replace the whole system.

The question the person paying actually asks is not what the obligation is — they know they have one — but this: what does it demand of the system I already run today? What follows is the answer, in the order the work really comes up. The short version before the detail: the link itself is the smallest part of the project, and your item list is the largest.

The obligation sits on the invoice, not on a particular program

The system does not certify a program and does not forbid one. What it requires is an invoice carrying specific data, signed, submitted, and given a number that comes back and establishes it. The practical consequence is immediate: every system that issues an invoice in your company's name is in scope, not the accounting system alone. If sales invoices come out of the ERP, service invoices are typed by a member of staff into a file, and a branch prints from an old program nobody has touched in years, you have three jobs rather than one. Which is why the first step in the project is not technical: write down every place an invoice leaves the company, who issues it, and from which program.

And a second consequence that matters more to whoever is paying: you are not obliged to change your system. If the system you run issues a sound invoice and the link can be added to it, the decision is the link, not the replacement. Plenty of quotes price a new system because that is the larger sale, not because what you have is incapable of the job. Ask first: can the link be built on what I run now? And if it cannot, what exactly prevents it — the absence of an interface to integrate through, or the fact that the system does not hold data the invoice needs at all? The second is a real reason to replace it. The first is not.

The unified item codes: the work nobody puts in the budget

Every line on the invoice has to carry a code from a unified coding scheme, not the name a salesman types in his own style. This is the point at which these projects stall, and it is the same point that appears in no quotation.

Which code, and who decides it

There are two routes: code your items against a global numbering scheme such as GS1, if your goods already carry those numbers — common with packaged and imported products — or build codes for your own items and register them for approval on the system. The second route is where most companies end up: those selling services, those manufacturing their own goods, those selling items that have no barcode. And the choice leaves a mark: the code that appears on the invoice becomes your language with the authority and with your customer, and changing it a year later is not an edit on a screen.

The mapping is the project itself

Mapping means every item in your system meets one code and one approved unit of measure. And the item list in any company that has traded for years looks like this: the same item written three ways, so it has become three items; dead items that have not sold in years and are still on the list; an item called miscellaneous or other that the seller rings up anything he cannot name against; and mixed units on a single item, between the carton, the piece and the kilo. The mapping exposes all of it in its first week, and it cannot be deferred: an item with no code is a line you cannot issue an invoice with.

Whoever prices the project for you normally prices the link, and leaves this part to you in a single sentence: the code file to be provided to us. Read that sentence as a financial clause rather than a procedural condition, and then ask: who builds the file? Who decides the right code for each item? And how many items do you actually have, as opposed to on paper? A thousand items means weeks of work by somebody who knows the goods and knows the accounts, not a task a programmer finishes in a day. This is the clause that turns into a delay in which each side blames the other, because it was never written into the quote and never had an owner.

Signing: a step in the cycle, and a physical thing that holds the certificate

The invoice is not submitted as bare data; it goes out electronically signed, and the signature needs a certificate issued by an accredited authority and held on a secured device rather than on somebody's desktop. That adds two things to your system: a signing step inside the invoice cycle, and an object that has a place and an owner.

And here the decisions nobody raises in the first meeting show up on the first day of operation:

• Where the invoice gets signed. If your system runs on a server on your premises, this is straightforward. If it runs on a cloud service or an external server, that server cannot see the device holding the certificate in your office, and the job needs a signing component that runs on your side and serves the system. That is not impossible, but it is an extra component that must appear in the quote by name and have somebody maintaining it.
• Who owns the certificate and who holds its code. In your company's name and kept by your company, and you are fine. Registered under the implementer's account, or living in an engineer's drawer, and issuing your invoices depends on his being there. This is the same rule that governs your hardware and licences in a maintenance contract: the account belongs to the company, and the implementer gets access, not ownership.
• The certificate's expiry date. A certificate has a term, and its expiry stops invoicing on an ordinary working day rather than on a date you chose. Put the date in the company calendar and give it a named owner, not a member of staff who remembers it.
• What happens if the device fails or is lost. Ask before it happens: how a replacement is obtained, who obtains it, and what you do with that day's invoices.

Submission and the invoice number: when the invoice has actually been issued

The cycle is not print, then send. The invoice is built, then signed, then submitted to the system, then comes back from it with a status and a number of its own. That number — not your internal serial — is what establishes that the invoice exists at the authority. From which come requirements on your system that are easy to forget until you need them:

• It stores the returned number with the invoice, shows it to whoever needs it, and delivers the invoice to the customer in the required form.
• Every invoice carries a clear status: built, submitted, accepted, rejected. An invoice with no status is an invoice you know nothing about.
• A credit or debit note and a return are tied to the original invoice and its number, because an adjustment refers back to an original and is not submitted as a document hanging in the air.
• Currency and exchange rate are part of building the invoice if you sell in anything other than pounds, not a correction after submission.

The practical test here is one question: do you know, at any moment, how many invoices you issued this month and how many of them are accepted at the authority? If your system does not answer that on one screen, you have a difference whose size you do not know.

A rejected invoice is the case that decides whether a system is usable

Every link works when the data is sound. The difference between a system you can work with and a system that lands you in trouble shows up in the invoice that gets rejected. And rejection happens for very ordinary reasons: an unapproved item code, a unit of measure that does not match what is required, missing tax details for the customer, a line whose arithmetic does not balance. These are not rare cases but daily work in the first months of operation.

The danger is not the rejection. It is a rejection nobody sees. An invoice that was rejected and left hanging in a log nobody opens is an invoice that was never issued: the goods went out, the customer took delivery, stock came down, and the document does not exist at the authority. The difference surfaces months later in a review, and correcting a document four months old is far harder than correcting it on the day.

What has to appear on the screen

• A status visible on the invoice itself, on the screen the person who issued it looks at, not in a separate log the programmer opens.
• One list of everything not accepted, which opens and counts: the rejected, the pending, and whatever was never submitted at all.
• The text of the rejection reason as it came from the system, not a generic error message. The reason is what tells you the problem is an item code and not the network.
• Resubmission after correction without rebuilding the invoice from scratch, and without a second round of manual entry.

And who watches it every day

The organisational half here matters more than the programming half: a named person who opens the not-accepted list every working day and clears it, and a monthly reconciliation between what your system says it issued and what is actually accepted at the authority, before the accountant closes the month rather than after. A system that submits and never reviews what was rejected is not half a solution; it is a deferred problem that grows with time.

Customer tax data has to be right before the invoice, not after

An invoice has two parties, so it carries your details and your customer's. And most of the early rejections come from the second party: a tax registration number missing or mistyped, a name that does not match the registered one, or a customer entered in your system under the name the salesman says rather than the legal name. A correction after issue is a document to amend and review; the right field at the moment the customer is created costs a minute.

What that asks of your system:

• Fields for the tax details in the customer record itself, not in a notes box that only whoever remembers it reads.
• A check when the customer is created: a customer you will invoice does not open with details missing.
• Cleaning up existing customers before go-live, starting with the ones you invoice most. The whole list is a large job, and the first twenty customers solve most of the problem.
• A customer type held in the system, because what the invoice carries differs between a registered company and a final consumer. And that is for your accountant to settle, not you and not the programmer.

An automated link or manual entry: the cheaper option can be the right one

The system accepts direct entry on its portal just as it accepts an automated link from your own system. The link is not a virtue in itself; it is a solution to volume and to human error. If you issue a handful of invoices a month to a fixed set of customers, manual entry is a sound decision: it costs you a member of staff's time instead of a software project, and it does not add a component to your system that you maintain and retest after every upgrade.

The equation turns over with volume: many invoices, or branches issuing at the same time, or a need for stock to come down and the entry to post along with the invoice in one step. Here manual entry is not cheaper, because it is data typed twice, and twice means a divergence between your system and the authority with no way of knowing which side is right. The simple rule: if double entry is bearable by eye, start there. If you need a reconciliation to discover the difference, you need a link.

What decides the size of the job at your end

There is no single figure for this project, and anyone who gives you one before seeing your item list is giving you marketing rather than an estimate. What really moves the size:

• The number of items and the state of the list. The largest factor by a clear margin, and the only one you can improve yourself before anybody starts.
• How many systems issue invoices. Every additional system is an additional link and an additional mapping.
• What your system is, and whether a link already exists for it. A widely used system with a ready solution is not the same as a program written specially for you years ago whose source nobody at your end holds.
• The state of the customer data. A thousand customers with incomplete tax details is work, not a field to fill in.
• What you need after the invoice. Returns, credit and debit notes and amendments are cases that all have to work, not the plain invoice on its own.
• Who will run this at your end. An accounts team that knows its own items shortens the project; its absence lengthens it and leaves the implementer deciding things that are not his to decide.

Start from the item list: a checklist before the first meeting

All of the above stands on a clean list of items and customers, and that is the part you can start today with no supplier and no quotation. What follows is what makes any quote you receive afterwards cheaper and more honest:

• Print your item list in full and go through it with the eye of somebody who knows the goods, not somebody who knows the program.
• Merge the duplicates, retire the dead ones, and give every item one name written one way.
• Give every item one clear unit of measure, and settle how the carton converts into the piece.
• Close the door on creating items: one person opens a new item against a written rule, not everybody in front of a sales screen.
• Take your fifty largest customers by invoice volume and complete their tax details under the legal name rather than the name everybody uses.
• Count the places an invoice leaves the company, who issues it, and from which program.
• Ask your accountant what applies to your company in particular: which documents you issue, what follows from the type of customers you have, and which dates and procedures apply to you. Those answers are yours, they change, and they are not taken from an article.

Who implements and who decides

At ZEMAVO we implement the link to the electronic invoicing system on Odoo and on our own system, Hesaby: registering the unified item codes, the signing step, submission and receiving the invoice number, and handling whatever is rejected rather than leaving it hanging where nobody sees it. And we are not tax advisors: the rates, the treatment and the document type are settled by your accountant, and we implement what he settles.

And the sentence we say before the contract rather than after: the link may well be finished before your item list is, not after it. If you want this project shorter and cheaper, start with the list before you start with the quote.