Egyptian e-invoicing: what it demands of the system you already run
The obligation lands on the invoice, so every system that issues one is in scope. The largest part of the project is not the link…
Odoo implemented from scratch: the modules chosen and set to the way you work, screens and reports customised, new modules programmed, and your balances, items and customers migrated.
Odoo is an open source ERP built out of modules: accounting, stock, sales, purchasing, HR and point of sale. We implement it from scratch, program what your business needs and cannot buy off the shelf, and move your data into it.
Odoo is not one program but a set of modules; you switch on the ones you need. The common mistake is switching everything on at the start: every module adds screens, fields and permissions for a member of staff to fill in, until the system weighs more than the work, people stop entering anything, and nobody trusts the numbers. We begin with what you need now — usually accounting, stock and sales — and leave the rest for later.
Odoo comes in two editions. Community is open source with no licence fee, and covers accounting, stock, sales and purchasing. Enterprise is a per-user subscription carrying modules and features Community does not have. The choice has a consequence: build your business on a feature that exists only in Enterprise and you stay tied to the subscription, while starting on Community and needing that feature later makes the move a project in itself. We settle the edition before the first installation.
Installation is the easiest part of the project. The effort is in moving what you already have, and in matching the system to the way the work really runs. Opening balances have to balance, item codes are usually duplicated or spelled several ways, and the stock in the books does not equal the stock in the warehouse. That is a clean-up before the migration, and whoever skips it moves his mess into a new system and then decides the system is the problem.
Every change in the code becomes something to review at every upgrade. Heavy customisation turns an upgrade into a project of its own and keeps you on an old version, so we ask first: do we change the system, or change the procedure? And a module written for a process nobody has written down will be written again. Write the procedure first — who does what and who signs — and then we program it in our software development department.
Issuing electronic invoices through the Egyptian Tax Authority portal is a legal obligation on companies, and we implement that link: registering the unified item codes, signing the invoice, submitting it and receiving its number, and handling whatever is rejected rather than leaving it hanging where nobody sees it. The link is half the work; the other half is your system producing correct invoice data the first time, and that starts with the item code and the customer tax details, not with the link.
We are not tax advisors: your accountant settles the rates and the treatment, and we implement what he settles.
We sit first with the people who use the system daily, not with management alone, and write down the cycle as it runs: who raises the purchase order, who receives, who prices. Then we fix the modules and the edition, and stand up a test environment to work in rather than your live data.
Then the migration: we take your files, clean them and load them into the test environment, and you check your own balances and items before anything is signed off. Then the customisation, the programming and the reports, then a period with both systems running in parallel until you trust the numbers, and then the switch. Handover includes the code we wrote and its documentation.
We are in New Maadi, beside the Technology Village, and we work across Cairo and Giza and the industrial zones around them — Obour, Tenth of Ramadan, Sixth of October and the Fifth Settlement. Writing the cycle down and reviewing the balances happen at your site.
We are not a tax adviser and not an accounting practice. We build the system on a chart of accounts and a tax treatment your own accountant approves, and we do not rule on either. And we do not start programming a module against a verbal procedure nobody has written down.
Odoo is also not always the right answer. If what you need is sales, stock and accounts for a single company, our own United POS (حسابي) is closer to your size, and if the requirement is payroll and attendance alone then ZHR is enough. We say so and lose the sale. An ERP earns its trouble when the operations branch out and departments have to talk to each other.
The obligation lands on the invoice, so every system that issues one is in scope. The largest part of the project is not the link…
Get in touch with our team for a free consultation and a detailed quotation within one working day.