Egypt's e-invoicing mandate through the Egyptian Tax Authority (ETA) works the same way Nigeria's FIRS and Rwanda's EBM do: an invoice is not legally valid the moment it is saved in your ERP, it becomes valid the moment ETA accepts it and hands back a UUID. There is no Acumatica-native ETA connector, and there shouldn't be — this is jurisdiction-specific tax law bolted onto a generic AR process, which is exactly the kind of requirement Acumatica expects you to solve with a customization project and an external middleware layer, not a screen it ships out of the box.
What ETA actually requires
ETA's e-invoicing system requires every B2B invoice to be built against a defined schema, digitally signed with a certificate issued to the taxpayer, and submitted to ETA's API before it is legally issued. ETA validates the document, assigns a UUID, and returns a signed response — that UUID (and the QR code derived from it) is what has to appear on the printed or emailed invoice. An invoice that hasn't been through this round trip is not a compliant tax document, regardless of what your Acumatica AR module thinks its status is. That single fact drives almost every design decision in the integration: nothing generates a final, presentable invoice document until ETA has responded.
Hooking the AR invoice release event
The natural integration point is invoice release — the same event that posts the invoice to GL is where you push the ETA submission job. In practice this means a graph extension on the AR invoice entry that, on release, does not print or email anything immediately. Instead it queues a background task that builds the ETA payload, submits it, and only updates the invoice with UUID/QR data once ETA has confirmed. Coupling submission to release synchronously is tempting but wrong — ETA's response time is not something you want blocking a user's screen, and it turns a slow API into a slow release process for every invoice in the batch.
public class ARInvoiceEntry_ETAExt : PXGraphExtension
{
protected virtual void ARInvoice_RowPersisted(PXCache cache, PXRowPersistedEventArgs e)
{
var doc = (ARInvoice)e.Row;
if (doc == null || e.TranStatus != PXTranStatus.Completed) return;
if (doc.Released != true) return;
// Do not submit synchronously - enqueue and let a background
// processor build the ETA schema, sign it, and submit.
ETASubmissionQueue.Enqueue(doc.DocType, doc.RefNbr);
}
} Mapping the AR invoice to ETA's schema
ETA expects line items coded against Egypt's GS1-based item coding (GPC/EGS codes), the taxpayer's registered TIN, and a fixed tax-type breakdown per line, none of which line up one-to-one with a standard Acumatica Stock Item or AR Invoice line. In practice this means carrying an EGS/GPC code as a custom field on the Stock Item (or a mapping table keyed off Inventory ID) that the transform layer reads at submission time — the same shape of problem as mapping eBay listing IDs to inventory items, just with a tax authority instead of a marketplace on the other end. Get the mapping wrong on a handful of SKUs and ETA doesn't reject the whole invoice quietly — it rejects the line, which means someone has to reconcile a partially accepted document days later.
ETA requires invoices to be signed with a certificate tied to the taxpayer's registration, not a generic code-signing cert. Most implementations don't do this signing inside Acumatica at all — they hand the built JSON document to an accredited middleware provider or PSP that holds the signing certificate and handles the ETA submission protocol, and Acumatica only needs to call that provider's API and store what comes back. Treat certificate custody and rotation as the middleware vendor's problem unless you have a specific reason to hold it yourself.
Retry and reconciliation at month-end volume
ETA's API, like every government tax portal under month-end load, is not going to be reliably available at the exact moment a client releases their last 400 invoices of the month. Building the submission as a synchronous, one-shot call means that outage becomes your outage. The job queue needs its own retry policy with backoff, and — more importantly — a reconciliation report showing which released invoices do not yet have a UUID, so accounting can see "pending ETA submission" as a distinct, visible state rather than discovering three weeks later that a batch of invoices was never actually valid.
{
"issuer": { "type": "B", "id": "TAXPAYER-TIN" },
"documentType": "I",
"documentTypeVersion": "1.0",
"invoiceLines": [
{
"itemCode": "EG-GPC-XXXXXXXX",
"quantity": 2,
"unitPrice": 150.00,
"taxableItems": [{ "taxType": "T1", "rate": 14 }]
}
],
"totalAmount": 342.00
}What happens before the UUID comes back
Printing or emailing an invoice before ETA has responded produces a document that looks final but isn't a valid tax invoice — the QR code and UUID it's missing are the whole point of the mandate. The safest pattern is to gate the print/email action on the presence of the UUID field, so a user physically cannot hand a customer an invoice that hasn't cleared ETA. It's a small UI constraint, but it's the one thing standing between "compliant" and "we sent an invoice to a client that the tax authority never saw."
A credit note or cancellation isn't just an Acumatica-side adjustment — ETA requires the reversal document to reference the original invoice's UUID and go through its own submission and acceptance flow. Treating a credit note as purely an internal AR transaction, without submitting it to ETA, leaves your Acumatica records and your ETA-registered tax history out of sync.
Wrapping up
There's no packaged Acumatica-to-ETA connector for the same reason there isn't one for FIRS or EBM — the schema mapping, certificate custody, and submission protocol are specific to Egypt's tax authority and don't belong baked into a generic ERP release. Hook AR invoice release as an async trigger, transform to ETA's schema using a real item-code mapping instead of guessing, lean on an accredited middleware provider for signing and submission, and build reconciliation reporting so a slow ETA API at month-end shows up as a visible queue of pending submissions rather than a silent gap in your compliance record.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.