Integrating an ERP with Egypt's e-invoice and e-receipt systems

Executive summary

• The e-receipt system is an extension of the e-invoice system and both run on the same platform: invoices for business-to-business (B2B) sales, receipts for sales to final consumers (B2C) through points of sale, each with its own registration path in the same digital profile.
• The ERP is registered as one of the taxpayer's delegates on that profile, after the taxpayer obtains an e-seal certificate, and gets its own Client ID and Client Secret for a one-hour access token.
• Every invoice and every credit or debit note is signed with the e-seal certificate before submission, as paragraph 5 of article 43 of the regulations to Law No. 206 of 2020 requires; technically, a CAdES-BES signature over a SHA-256 hash of its canonical form.
• Cancellation is the seller's right once the buyer approves; rejection is the buyer's, each within a period a decision of the Head of the Authority sets and the regulation does not fix, and a document can be rejected only once.
• Item coding is a condition of a valid document: the international GS1 standard (paid, linked to the GPC classification automatically) or the free Egyptian EGS standard, which the taxpayer maps to level 4 of GPC and which needs the Authority's approval within 15 days.
• Receipts must reach the system within 24 hours of issuance; a point of sale cannot submit anything before it is registered and activated.

Registration and delegation

For a business already under the invoice or receipt mandate — the legal side sits in e-invoicing in Egypt — integration starts outside the ERP itself. The taxpayer obtains an e-signature certificate with an e-seal carrying its tax registration number from a licensed provider, registers its digital profile on the Authority's portal with it, and invites a first administrative delegate by national ID, name and login email. The ERP is then added inside that profile as a delegate, issued a Client ID and Client Secret for an OAuth 2.0 request that returns a one-hour bearer token, renewed before it expires rather than after.

Signing, submission and validation

Paragraph 5 of article 43 requires the taxpayer to sign its invoices with the e-signature certificate and send them immediately on drafting, within the period a decision of the Head of the Authority sets: technically, hashing the document's canonical form with SHA-256, then applying a CAdES-BES signature with the e-seal certificate and embedding it in the document. Documents go up in batches through one interface, which immediately returns a submission ID and a unique ID per accepted document; each document then passes, separately, the validators the Authority has enabled — eight in the SDK's list: structure, core fields, signature, national ID above a set threshold, issuer and receiver validity, any referenced document, the codes used, and the calculation formulas. Its status is then submitted, valid or invalid; the receiver only sees it once it turns valid, rejected or cancelled.

Coding goods and services

Using unified codes is itself a condition under paragraph 2 of the same article. The Authority follows two standards: GS1, a unique international 13-digit code per item that carries a fee, or the free Egyptian EGS standard, built as "EG" + the taxpayer's registration number + an internal item code. A GS1 code is linked to its GPC classification automatically; an EGS code must be mapped by the taxpayer to level 4 of the global GPC classification — an 8-digit code starting with 1000 from the left.

EGS codes are sent singly or in a batch and cannot be used on any document before the Authority approves them. A wrong item code invalidates only that document, and the notice to the taxpayer names the item at fault.

Cancellation, rejection, and credit and debit notes

"The buyer may reject the invoice within the period that a decision of the Head of the Authority sets, counted from its issue date. The seller may also cancel the invoice within the period that a decision of the Head of the Authority sets from its issue date, after the buyer approves the cancellation" (article 43, executive regulations of Unified Tax Procedures Law No. 206 of 2020).

Cancellation belongs to the seller alone and rejection to the buyer alone. The regulation fixes neither period and leaves both to a decision of the Head of the Authority; the system sets the limit for each document type and returns it through the Get Document Type API, so an ERP should read the current limit at run time, not assume one. A cancellation request is not one-sided: the buyer is notified and approves it explicitly or by not objecting, or objects, in which case the document stays valid on the system; the buyer can object to cancellation of the same document only once. Once both windows close, an invoice is corrected by a credit or debit note — a separate document that refers to the original invoice by its unique ID on the system and changes nothing but the amounts: it adds no new lines, and the credit notes on one invoice cannot together exceed its value. All the preceding controls of article 43, coding and signing among them, apply to these notes.

The e-receipt: point-of-sale registration and real-time submission

Registering a point of sale is a separate step from invoicing, even though both sit in one digital profile. Once its devices are inspected and approved on site, the taxpayer registers them under "points of sale" in its profile and keeps the Client ID and Client Secret issued for each device; no receipt is accepted from a device, on any channel, before it is activated. Submission is meant to be real-time: a receipt must be transmitted within 24 hours (UTC) of issuance, and the Authority may take legal action where receipts are not sent in real time, unless the taxpayer gives a reason it accepts on the technical facts of the case. Once that window passes, the only route is a late-submission request through the portal.

What this requires

• Confirm, through the Authority's two inquiry services, whether and from when the business falls under the e-invoice and e-receipt mandate decisions, before starting the integration.
• Obtain the e-seal certificate and register the ERP as a delegate on the digital profile, separately from the points of sale.
• Build the item-mapping file against EGS or GS1 codes linked to GPC, and secure the Authority's approval of the EGS codes before issuing begins, not during it.
• Run the full submission-and-validation cycle on the test environment before going live, even where not mandatory.
• Build a way to receive or poll for status notifications, so rejected or cancelled documents are caught before they are posted.
• Assign a named internal or external team to the integration; the Authority does not require the taxpayer to use any particular provider.

The firm's ERP Consulting Department assesses a taxpayer's ERP readiness for this integration, builds the item-mapping file against its codes, and oversees testing on the Authority's test environment before go-live.

Mahmoud Nassef — Chartered Accountant (Egyptian Register), Founder Partner

Member, Egyptian Society of Accountants & Auditors
Member, Egyptian Tax Society
Member, Egyptian Society for Public Finance and Taxation

Partner profile · Book a consultation

Disclaimer: This bulletin is prepared for general information on the legislation in force at the date of its publication. It does not constitute a professional opinion or tax or legal advice on any particular matter, and it should not be relied upon in place of advice based on an examination of the circumstances of each case. Nassef & Partners International accepts no responsibility for any action taken, or refrained from, in reliance on its contents. The positions stated remain subject to subsequent legislation and decisions.