Egypt ETA E-Invoicing and E-Receipt

The problem

The Egyptian Tax Authority (ETA) does not accept a printed invoice as proof of anything. It expects a structured JSON document, signed with your company's certificate, submitted to the ETA API, and answered with a UUID and a long ID that must be retained against the transaction. The e-receipt track adds a second, separate pipeline for retail and cash sales, with its own submission model and its own tolerance for volume.

SAP Business One has no idea any of this exists. Out of the box, OINV and ORDR hold everything a tax document needs — the Business Partner, the tax registration number, the line-level item, quantity, unit price, discount and tax code — and none of it in the shape ETA wants. There is no signing step. There is no item-code taxonomy mapping. There is no place to store the returned UUID, no place to record a rejection reason, and no way to see at a glance which of last week's invoices actually cleared.

So teams do it by hand: export to Excel, re-key into the ETA portal, paste the UUID back into a Remarks field, and reconcile at month end by eye. That works until volume rises, until a code mapping changes, or until an auditor asks you to prove that every posted A/R Invoice has a matching accepted submission.

What ECOSIRE builds

We build a SAP Business One add-on that closes the gap between your marketing documents and the ETA API, so submission is a consequence of posting rather than a separate clerical job.

Document generation from real B1 objects

The add-on reads posted A/R Invoices, A/R Credit Memos and A/R Down Payment Invoices through the Service Layer (/b1s/v1/Invoices, /b1s/v1/CreditNotes) or the DI API, depending on what your deployment and volume call for. Header data comes from the Business Partner master (OCRD) — tax registration number, branch, address components — and line data from INV1, including item code, description, quantity, unit of measure, unit price, discount, and the tax amounts resolved by your B1 tax codes. We map each of these into the ETA document structure, including the taxTotals and taxableItems breakdown per line, and the invoice-level totals ETA reconciles against.

Item coding: GS1 or EGS

ETA requires every line to carry a recognised item code — a GS1 GTIN or an EGS code registered against your taxpayer profile. We add User-Defined Fields on the Item Master (OITM) to hold the code type and the code value, plus a User-Defined Table holding the mapping catalogue so it can be maintained in bulk rather than item by item. A validation step blocks submission of a document whose lines are not fully coded, and reports which item codes are missing, so the failure surfaces before the API call rather than as a rejection afterwards.

Signing

ETA e-invoices must carry a valid signature produced with your certificate. We build the signing step as a discrete, swappable component — HSM/USB token or a service-based signer, depending on how your certificate is held — so the canonicalisation and signature construction sit in one place and can be adjusted without touching the document mapper. The signed payload is retained alongside the submission record for audit.

Submission, polling and status

Submissions run as a scheduled service and as an on-demand action from the document. Each attempt writes a row to a User-Defined Table holding the internal document key, the submission timestamp, the ETA UUID, the long ID, the returned status, and the full error payload when the document is rejected. UDFs on the invoice surface the UUID and current status on the document itself so the AR team can see state without leaving the form. Because ETA processes asynchronously, a poller re-checks documents that were accepted-for-processing until they resolve, and flags anything that stalls.

E-receipts

The receipt track is built as a parallel pipeline against the same coding catalogue, sourced from your POS or cash-sale documents, with its own submission cadence and its own retention table. Receipts and invoices share the item mapping and the signing component but do not share a queue — one backlog cannot block the other.

Operational surfaces

We add a UDO-based cockpit for the finance team: a list of unsubmitted documents, a list of rejections with their reasons, a retry action, and a reconciliation view comparing posted A/R documents in a date range against accepted ETA submissions. Where you want printed or emailed output carrying the ETA reference and QR, we build it as a Crystal Report layout bound to the invoice, so it prints from the standard B1 preview and print flow.

Who this is for

Companies running SAP Business One in Egypt that are inside the ETA mandate and are currently bridging the gap with manual portal entry or spreadsheets. It suits organisations with more than a trivial invoice volume, with multiple branches or activity codes, or with a retail arm that also needs the e-receipt track. It is equally relevant to a group whose Egyptian entity sits inside a multi-country B1 landscape and needs the localisation contained to that company database.

Compatibility

Built for SAP Business One 10.0 on either Microsoft SQL Server or SAP HANA, on-premise or hosted. The add-on is delivered per tenant and installed into your company databases; nothing is shared between customers.

How delivery works

1. Scoping call. We walk your live setup: B1 version and platform, document types in scope, tax code configuration, how your certificate is held, whether e-receipts are in scope, branch and activity-code structure, and how your item catalogue is organised. We agree what is in the first release and what is deferred.

2. Fixed quote. You receive a written scope and a fixed price before anything is built. No hourly drift.

3. Build. We develop against your configuration, mapping your tax codes and your item catalogue rather than a generic sample. Typical lead time is two to four weeks depending on scope — this is built to order, not pulled off a shelf.

4. Install in test, then production. We install into your test company database first and run real documents through it with your finance team against the ETA preproduction environment. Only after you sign off does it go into the production company database.

5. Support. A support window is included from go-live, covering defects, configuration questions, and adjustments to the code catalogue as your item master grows.