Egyptian e-invoicing (ETA) inside a custom ERP: what the integration actually needs

Egyptian companies above the registration threshold must submit invoices electronically to the Egyptian Tax Authority. Most ERPs bolt this on as an export. In the smart home ERP I built, it is a first-class part of the finance module. These are the decisions that mattered.

Submissions are their own table, not a flag on the invoice

An invoice can be submitted, rejected, corrected, and resubmitted. If that history is a status column on the invoice, you lose the rejections and cannot answer what was sent when. The finance migration therefore adds an e-invoice submissions table that references the invoice and records each attempt with its outcome, so the invoice itself only ever reflects the latest accepted state.

VAT registration is data

The first version hard-coded 14% VAT in two places, the advance invoice path and the final invoice path. That is wrong for a company that is not VAT-registered: it issues documents charging a tax it may not collect. The fix moved both the rate and the registration status into company settings, applied only when registered, and was caught while writing the operating guide, not by a test. Write the operating guide early; it finds the bugs a test suite does not know to look for.

Model the whole money picture or the numbers lie

E-invoicing only covers sales. The owner's real question was how much money do we have, and the system could not answer it because supplier payments had no home (the payments table required a customer), overheads had no category, and there was no opening balance. Petty cash was one technician's float, not the company account. Step 14 added company cash as its own model with views on top, and only then did the reports add up.

Checklist for anyone adding ETA to their system

• Keep a submission log table with one row per attempt and the authority's response.
• Store the tax rate and registration status in settings; never in code.
• Make invoice numbering sequential and gap-free per document type, because the authority and the auditor both expect it.
• Record payments and allocations separately from invoices so partial payments and advances reconcile.
• Give every outbound payment a destination and category before you build any cash report.

None of this is exotic. It is the difference between an invoice screen and a finance module a company can be audited on.