Egypt E-Receipt Requirements: 2026 Compliance Guide

Egypt's e-Receipt system covers B2C sales of goods and services to final consumers by taxpayers specifically named in Egyptian Tax Authority rollout decisions. It is separate from the B2B and B2G eInvoice system. For 2026 compliance, a business should check its registration number in the ETA obligated-taxpayer inquiry, not assume that a general turnover threshold determines whether it is in scope.

ETA's Decision 361 e-Receipt announcement states that the taxpayers named in its attached list had to issue electronic tax receipts for services or goods supplied to final consumers from 15 November 2025. The decision covered the first sub-phase of the ninth main rollout phase. It did not impose the same start date on every Egyptian business.

This distinction resolves a common source of confusion in summaries of Egypt e-receipt requirements. The EGP 150,000 amount that appears in ETA's Receipt v1.2 documentation is a buyer-identification rule for an individual receipt: when a natural person's receipt reaches that amount, the buyer's national ID and name become mandatory. It is not a turnover test for joining the Egypt electronic receipt system, and it does not support the claim that a universal e-Receipt threshold changed on 1 January 2026.

The practical scope test is therefore entity-specific:

1. Confirm that the transaction is a B2C sale to a final consumer rather than a B2B or B2G supply.
2. Search the taxpayer's registration number in ETA's obligation inquiry and retain the result.
3. Identify the decision and effective date that apply to the named taxpayer.
4. Confirm that the taxpayer's branches, issuing systems, and coded goods or services are ready for production use.

The Rollout Is Decision-Based, Not a Single Turnover Test

ETA has introduced the e-Receipt obligation in phases, with each decision identifying the taxpayers covered by that step. Two 2025 milestones orient the current position:

Decision	Rollout step	Effective date	Who entered scope
No. 281 of 2025	Second sub-phase of the eighth main phase	15 September 2025	Taxpayers named in the attached list
No. 361 of 2025	First sub-phase of the ninth main phase	15 November 2025	Taxpayers named in the attached list

A deadline table is not enough to establish an entity's status. Tax teams should retain the ETA inquiry result or the relevant decision and attached list in the compliance file, together with the registration number searched and the date of the check. The inquiry should be repeated after a merger, registration change, branch reorganization, or later rollout announcement rather than copied forward indefinitely from an old implementation memo.

ETA's current published conditions also show why unrelated thresholds are a poor proxy for scope. Entry into the e-Receipt system depends on three connected facts: the taxpayer is already enrolled in the eInvoice system, the ETA president has issued an e-Receipt obligation decision covering it, and its goods and services are coded under the approved rules. Egypt's VAT-registration threshold, the EGP 20 million ceiling associated with the simplified tax regime, and the EGP 150,000 buyer-identification rule answer different questions.

The document route then follows the customer relationship:

• A retail sale or service supplied to a final consumer belongs in the B2C e-Receipt workflow.
• A transaction between businesses or with a government entity belongs in the eInvoice workflow, subject to the applicable tax and document rules.
• A mixed business needs both classifications in its order-to-cash design. The same taxpayer can issue eInvoices for wholesale customers and e-Receipts for consumers.

Teams designing the B2B transmission flow can treat Egypt e-invoice API integration as a separate implementation job. Likewise, Egypt's exported-services e-invoice requirements concern the tax treatment and documentation of cross-border B2B services, not the domestic final-consumer receipt mandate.

---

Prepare the Taxpayer, Branches, POS Devices, and Item Codes

Compliance readiness is a master-data and systems exercise, not simply a search for an "ETA-approved POS." The issuing taxpayer, every branch, each issuing endpoint, and the product or service catalogue must agree with the records and codes ETA validates.

Start with the legal entity and branch inventory. Each receipt carries the seller's Egyptian registration number, registered trade name, branch code, branch address, activity code, and POS device serial number. A branch that is missing, inactive, or paired with the wrong device can cause an otherwise accurate sale to fail validation. Tax should therefore sign off the branch list before technology maps outlets to production credentials.

An ERP can act as the issuing endpoint. ETA's POS FAQ says a single-branch accounting system can be registered as a software POS. Where a centralized ERP issues for several sales outlets, each outlet must be registered as a separate POS so the receipt identifies the correct source. The implementation design should preserve that identity even if all transactions pass through one middleware service.

Product master data requires the same discipline. Receipt v1.2 uses GS1 or EGS item codes, along with controlled values for activity, unit type, payment method, currency, buyer type, tax type, and tax subtype. Before go-live, test that the codes used at checkout are authorized for the taxpayer and that the ERP does not replace them with internal descriptions during transmission.

The issuing channel then authenticates for B2C submission. The access token must identify the taxpayer that owns the POS, while the receipt's issuer and device data must match that authorization. Re-authentication matters after ETA changes a permission or activates a late-submission request because an old token will not carry the updated claims.

For taxpayers covered by Decision 361, ETA also called for compliance with its technological operating conditions and registration on the Fatoortak Hemayetak We Gayzetak incentive portal from the decision's effective date. These are distinct from coding and device registration and should appear as separate items in the implementation plan.

Electronic sealing or signing needs equally careful scoping. ETA publishes technical material for signing receipt batches, but its SDK has also documented deployment-dependent signature validation. Teams should implement the current production requirement and certificate configuration confirmed by ETA for their channel rather than copy the eInvoice signing rule into the e-Receipt design or treat a signature printed on paper as the technical control.

What a Compliant Electronic Receipt Must Contain

A compliant receipt has two overlapping data layers. The first records the commercial and tax event a customer and auditor need to understand. The second lets ETA validate the issuer, sequence the document, and trace corrections. A field marked optional in the ETA Receipt v1.2 specification should not automatically be treated as optional under the law or for a particular transaction.

Data group	Principal Receipt v1.2 content	Control purpose
Issuance	UTC issue date and time, receipt number, sale or return type, version	Establishes when and how the document was issued
Seller and source	Registration number, trade name, branch code and address, device serial number, activity code	Ties the receipt to an authorized taxpayer, branch, and POS
Buyer	Buyer type, ID, name, mobile or payment reference where applicable	Identifies the customer when the transaction or buyer type requires it
Items	Internal code, description, GS1 or EGS code, unit, quantity, unit price, gross sale, discounts, net sale, tax, final line total	Supports item-level tax calculation and reconciliation
Receipt totals	Total sales, commercial and item discounts, net amount, tax totals, total amount, payment method	Rebuilds the financial result from the lines
System controls	UUID, previousUUID, and referenceOldUUID when correcting an invalid receipt	Preserves uniqueness, sequence, and correction history

ETA's legal minimum-data guidance for final-consumer receipts includes the seller's name, address, and registration number; the receipt's serial number and issue date; the issuing branch; buyer details where required; a description, quantity, and value for the goods or services; the Central Bank exchange rate for a foreign-currency receipt; tax category and amount; total value; and payment method. A price display that lacks the required data is not a substitute for a valid receipt.

Receipt v1.2 refines how buyer identification works. Buyer type B denotes an Egyptian business, P a natural person, and F a foreigner. For type B, the business registration number and name are required by the schema. For type P, the national ID and name become mandatory when totalAmount is EGP 150,000 or more. This is a rule about identifying the buyer on a high-value receipt, not a test for whether the seller must join the system.

The amount mapping must be reproducible. At line level, total sale reflects quantity multiplied by unit price; discounts lead to net sale; taxes and other permitted pricing elements produce the final line total. At receipt level, total sales, commercial discounts, item discounts, net amount, tax totals, and total amount should reconcile to the underlying lines. Finance testing should use transactions with discounts, multiple tax treatments, foreign currency, and returns rather than approving the mapping from a single cash sale.

The system fields provide the audit spine. The UUID is a 64-character SHA-256 value generated from normalized receipt content. previousUUID points to the last receipt or return issued by the same POS; only the first document from that POS uses the permitted empty value. referenceOldUUID is used when corrected content creates a new UUID after validation failure, allowing the replacement to be found through the invalid document's identity.

The printed receipt should also carry ETA's QR code. Its content includes a share URL for the receipt-details page, the seller's registration number, and the receipt total. The QR code connects the customer-facing document to the electronic record; it does not replace accurate printed fields or a successful submission.

---

Issuance, Returns, Rejections, and Late Submission

The ETA receipt-issuance FAQ documents different relationships for sales, returns, invalid submissions, and corrected resubmissions. Once a receipt has been validly submitted, the repair path is not to overwrite or delete it in the ERP.

A sale uses the applicable sale-receipt type. A return uses the corresponding return type and must carry the original sale receipt's UUID in referenceUUID. ETA does not permit a return receipt without its reference document, so a generic negative posting with no link to the original sale is not an adequate substitute. Partial-return design should retain both the reference and the returned line and amount detail.

Every POS also maintains a sequence through previousUUID. Assume three documents are issued as R1, R2, and R3. R2 points to R1, and R3 points to R2. If R2 fails validation, R3 does not simply change its historical link because a later correction is submitted. The sequence as issued remains part of the evidence, and the invalid document is repaired through the correction fields.

When correcting R2, the source content is fixed and a new content-derived UUID is generated. The corrected receipt keeps R2's original previousUUID, which points to R1, and puts R2's invalid UUID into referenceOldUUID. This preserves a searchable link between the failed and corrected versions. Reusing the invalid UUID after changing content would break the UUID calculation; changing unrelated later receipts would distort the POS chain.

Internet availability does not have to stop customer issuance. ETA's current offline-issuance guidance allows a receipt to be issued offline, accumulated locally, and sent when connectivity returns. The current rule allows 24 hours for submission. An offline queue therefore needs age monitoring, retry controls, and an alert well before the deadline. "Stored on the till" is not the same as "received and validated by ETA."

Older documents require a controlled late-submission route. The taxpayer first obtains an active late-submission request, then the POS or ERP re-authenticates so its token reflects the permission. ETA controls the request quota, active period, and oldest acceptable issue date. Those settings belong in configurable integration logic and an operating procedure, not as constants copied from a one-time project document.

Receipts may travel in a batch, but validation is still meaningful at receipt level. Operations should retain the submission identifier, receipt UUID, status, validation messages, acknowledgement time, retry attempt, and final outcome. A batch marked unsuccessful must not lead staff to resend every receipt blindly: already valid documents, invalid documents requiring correction, and transmissions whose status is genuinely unknown require different actions.

Verify a Receipt After Issuance

"Lookup" can refer to three different controls. Keeping them separate prevents a valid taxpayer search from being mistaken for proof that a particular receipt reached ETA.

Check	Question answered	Evidence to retain
Obligation inquiry	Is this registration number covered by an e-Receipt rollout decision?	Inquiry result, applicable decision, and check date
Submission acknowledgement	Did ETA receive and validate this receipt?	Submission ID, UUID, status, messages, and acknowledgement time
QR or share-link check	Does this printed receipt resolve to its electronic details?	UUID, issue time, seller registration number, total, and details-page result

The obligation inquiry belongs in the entity's tax-scope file. It does not search an individual receipt. Conversely, a valid receipt-details page proves a document-level record but does not replace the business's evidence that it completed onboarding and registered the issuing branch and device.

ETA's receipt specification instructs the taxpayer to place a QR code on the printed receipt. The code includes a share URL built from the receipt UUID and UTC issue time, followed by the total and seller registration number. This supports receipt-level checking without requiring the customer or reviewer to enter the taxpayer's ERP. A failed QR lookup should be investigated against the exact UUID and timestamp before concluding that the sale was never submitted.

For the issuer, the system response is the stronger operating evidence. ETA's guidance describes confirmation through channels including the ERP, email, and SMS. Finance should retain the structured submission response and validation result alongside any notification because an email or screenshot may omit the specific status and error data needed to resolve an exception.

A minimal verification record contains:

• receipt UUID and receipt number;
• seller registration number, branch code, and POS serial number;
• issue date and time in UTC;
• receipt total and document type;
• submission and validation status; and
• the acknowledgement or receipt-details evidence used for the check.

ETA documentation supports QR share-link verification, but it does not establish anonymous bulk downloads, receipt packages, or a fixed portal-retention period. Teams should confirm those retrieval capabilities for their configured environment rather than infer them from the share route.

---

Reconcile POS, ERP, and ETA Records at Month-End

The finance control cycle must reconcile three populations: sales and returns recorded by the POS, postings in the ERP or general ledger, and documents accepted or rejected by ETA. Daily matching catches operational faults while they are still recoverable; month-end then confirms that the complete period agrees.

Start at the most granular level available. Compare document counts and values by business date, branch, POS, and status before rolling them into one company total. A balanced national total can conceal an omitted branch and an equal-value duplicate elsewhere.

The UUID is the strongest receipt identity because ETA treats it as unique across the system. Receipt number can be a useful business key, but it should be paired with branch or POS identity where uniqueness is not global. Issue time and amount fields help diagnose mismatches; total amount alone is too weak because many retail transactions share the same value.

The value reconciliation should preserve the calculation layers:

• total sales before discounts;
• commercial and item discounts;
• net amount;
• tax totals by type and subtype;
• final total amount and payment method; and
• sale and return values shown separately before netting.

This structure distinguishes a missing document from a mapping defect. For example, matching final totals with different tax totals points to classification or tax-code logic, while matching POS gross sales but lower ERP net sales may indicate a discount posting problem. An unmatched return should be traced to its referenceUUID, not cleared against the day's aggregate sales.

Maintain an exception register rather than editing differences out of the reconciliation. Useful classes include:

Exception	Evidence to inspect	Closure evidence
Missing or inactive branch or device	Registered master data, token claims, validation message	Registration correction and accepted receipt
previousUUID sequence break	Receipts before and after the gap, POS queue	Document disposition and restored monitored sequence
Duplicate or repeated submission	UUID, item and amount attributes, submission history	Valid document identified and duplicate resolved
Invalid receipt resubmitted	Original UUID, referenceOldUUID, corrected payload	New accepted UUID linked to the invalid one
Delayed submission	Issue time, queue log, ETA receipt time	Accepted status or approved late-submission evidence
Unmatched return	referenceUUID, original sale, returned lines	Return matched to the original receipt
POS-to-ERP difference	Receipt lines, tax mapping, journal entry	Corrected posting with approval trail

Every exception record should also identify its owner, age, root cause, corrected UUID where applicable, and closure evidence.

When paper or image receipts from third parties or legacy systems must join the analysis, the separate workflow to scan receipts into Excel can create structured comparison data. That capture step does not issue an ETA receipt, change its validation state, or replace the original electronic record.

Retention should cover more than the customer copy. Preserve receipt payloads, ETA acknowledgements, validation errors, corrected versions, return references, source sales records, reconciliation workpapers, and sign-off under the entity's Egyptian tax-record policy. Egyptian VAT materials generally require books, records, supporting documents, and invoice copies to be retained for five years after the end of the relevant fiscal year. Because the governing provisions and the entity's tax profile matter, the responsible Egyptian tax adviser should confirm the applicable period rather than relying only on a portal's online availability.

The financial exposure is also concrete. In its guidance on legally required final-consumer receipt data, ETA states that failure to include those data in a paper or electronic receipt violates Article 37 of the Unified Tax Procedures Law and attracts the Article 71 fine of EGP 20,000 to EGP 100,000. Other failures may have separate consequences, so this range should not be described as the maximum exposure for every form of noncompliance.

A month-end control file should contain:

• the applicable decision or dated obligation-inquiry result;
• the approved taxpayer, branch, POS, and item-code inventories;
• evidence that representative receipt schemas and calculations passed testing;
• daily submission monitoring and ETA acknowledgements;
• sale, return, invalid-document, and correction histories;
• the POS-to-ERP-to-ETA reconciliation; and
• named ownership, ageing, remediation, and sign-off for every unresolved exception.