Egypt ETA E-Invoicing & E-Receipt Compliance

The problem

Egypt's ETA mandate is stricter than most e-invoicing regimes in two ways that break generic tax modules. First, every document must be cryptographically signed before submission, using a hardware token or HSM holding your certificate — which means the signing step cannot live inside a cloud ERP process and has to be orchestrated across a boundary. Second, every line item must carry a code from an approved coding scheme: either a GS1 GTIN or an EGS code registered against your taxpayer profile, with the internal item code mapped to it. A payload that is structurally valid but carries an unregistered item code is rejected, and so is one whose canonical serialization does not match what was signed.

On top of that, e-invoice and e-receipt are two different obligations with different structures, different volumes and different submission rhythms. B2B invoicing is document-by-document with a UUID, a long ID and a status that can move to rejected days later. Retail receipts are high-volume, near-real-time, and aggregated for reporting. Tax treatment adds table-driven complexity: value-added tax alongside table tax types, withholding, and discount and commercial-discount handling at both line and document level, all of which the authority cross-checks against totals.

Generic tax localization in an ERP produces a tax-coded invoice. It does not produce a canonically serialized, signed payload with registered item codes, a UUID register, a rejection queue and a receipt stream. That gap is why Egyptian teams end up running a separate desktop signing tool with a spreadsheet next to it.

What ECOSIRE builds

ECOSIRE builds this as a NetSuite customization in your own account with SuiteScript 2.1, handed over as an SDF project and an unmanaged bundle. Signing is handled by an on-premises signing agent you control, which the NetSuite side calls over an authenticated channel — because your certificate must not leave your custody.

Coding scheme and master data

We add a code-mapping custom record that ties every sellable NetSuite item to its GS1 GTIN or EGS code, with the scheme type, activity code and registration status recorded per item. Fields are applied to Inventory Item, Non-Inventory Item, Service Item and Kit/Package records, and a unit-of-measure mapping record translates your NetSuite units into the authority's accepted codes. Entity-level fields on Subsidiary, Customer and Vendor hold taxpayer registration number, national ID or passport identifier for individuals, activity code and address structure in the shape the payload requires. A readiness Suitelet lists every item and entity that cannot yet be submitted, which is where the real preparation work sits.

Payload build and canonical serialization

A payload builder assembles the document from the transaction: issuer and receiver blocks, line items with the registered code and scheme type, unit value and quantity, discount and commercial-discount handling, and the tax array covering value-added tax and the applicable table tax types. Totals are computed and cross-checked against the line detail before anything is sent, because a totals mismatch is a guaranteed rejection. The builder then produces the canonical serialization the authority requires for signing — this is the part naive implementations get wrong, and it is implemented and tested explicitly rather than approximated.

Signing and submission

A Map/Reduce script sends the canonical form to your signing agent, receives the signature, attaches it to the document and submits over N/https with a cached authentication token held in a custom record. Submissions are batched where the interface permits and sized to stay inside payload limits. The returned UUID, long ID, submission UUID and timestamp are written back to the transaction and to a UUID register custom record. A Scheduled script polls document status, so a document that is later rejected by the authority — or cancelled or rejected by the receiver inside the permitted window — moves to that state in NetSuite instead of silently staying "sent".

E-receipts

Receipts are a separate stream with their own record, its own submission cadence and its own aggregation for reporting. Point-of-sale and external retail systems feed it through RESTlets over SuiteTalk REST, so a till does not need a NetSuite UI session, and receipt status is queryable back the same way. Volume handling, retry and back-off are designed for the receipt rhythm rather than reusing the invoice queue.

Status, rejection and audit

Every document carries an explicit state: not submitted, signed, submitted, valid, invalid, rejected, cancelled. Rejections are decoded against an error-code dictionary held as data, surfaced on the transaction, and collected into a work queue with age, because an unresolved rejection is an unfiled document. A full request and response log — including the canonical form that was signed — is retained per document, which is precisely what a tax audit asks to see. Custom roles separate submit, cancel and view rights, and access to the raw payload log is restricted.

Output

The UUID, long ID and a QR code for the validated document are rendered onto the Advanced PDF/HTML template so the customer-facing document is the compliant one, with distribution triggered by acceptance rather than by invoice creation.

Who this is for

Egyptian NetSuite tenants inside the ETA mandate, and OneWorld groups where Egypt is one subsidiary and the group needs the obligation met without standing up a parallel system. It suits businesses with a real item catalogue that must be code-registered, businesses running both B2B invoicing and retail receipts, and businesses that currently sign documents in a desktop tool disconnected from the ledger.

How delivery works

1. Scoping call. We review your subsidiaries, document types, item catalogue, coding-scheme registration status, tax treatments in use, retail systems and how your signing certificate is held today. We look at your sandbox. 2. Fixed quote and scope document. A written scope names every record, field, script, role, template and mapping we will build, the signing-agent architecture, acceptance criteria, and the registration and master-data work that is yours. The price is fixed against that scope. 3. Build. Development happens in your sandbox as an SDF project, against the authority's pre-production environment with your test credentials and a test signing setup. 4. Install in test, then production. End-to-end validation in sandbox with your own transactions, your own item codes and real signing. Production install follows sign-off, in a window you nominate, with a documented rollback path. 5. Support window. A defined post-go-live period covers defects, error-code and schema changes encountered in that window, and handover. Ongoing support beyond it is a separate agreement.

Nothing here is pre-built or instantly downloadable. Typical lead time from signed scope to production install is two to four weeks, and the largest variable is how much of your catalogue is already code-registered.