UAE E-Invoicing for Retail

A retail POS is optimised for sub-second checkout latency, not for XML generation and network submission. If you tried to submit every receipt to the FTA network at time of sale, you would either slow the lane down (unacceptable) or lose the compliance obligation on retries (unacceptable). The correct pattern is asynchronous: POS emits its usual daily settlement, and the settlement is post-processed into PINT-AE for the subset of transactions that require it.

TrustBill's POS bridge watches for supported POS export formats — Micros, Squirrel, Lightspeed, Odoo POS, and generic CSV/JSON — and processes them nightly (or hourly for high-volume chains). For each transaction: if it has a TRN or exceeds AED 10,000, it becomes a PINT-AE invoice submitted through the accredited ASP path. If not, it stays in the POS as a simplified receipt. No manual sorting needed.

Edge case: split-tender receipts (cash + card + gift card in one transaction). PINT-AE handles this cleanly with cac:PaymentMeans repeated per tender type, but many POS exports collapse tender types into a single line. TrustBill's bridge unpacks common POS export formats into their component tender rows before conversion.

A retail chain with 10 branches wants FTA-visible per-branch analytics — knowing that Dubai Mall generated 40% of tax revenue is useful for both compliance defence and operational planning. Under UAE VAT law, HQ is the VAT-registered legal entity; branches share the HQ TRN. PINT-AE reflects this: cac:AccountingSupplierParty carries the HQ TRN on every invoice from every branch.

Where to put the branch identifier: never in cbc:ID (that's the invoice number and must be unique). The compliant patterns are (a) cbc:Note with a machine-readable branch code prefix, (b) a UBL extension namespace attribute, or (c) the invoice's cac:AccountingSupplierParty/cac:PostalAddress carrying the branch's physical address. Option (c) is what the FTA analytics team appears to use for their internal dashboards.

Do not create separate TRNs per branch just to make analytics easier. That would trigger inter-branch supplies to become taxable events (they're currently ignored as intra-entity movements) and cost the chain far more in VAT reconciliation than any analytics benefit is worth.

A retail return that was originally a simplified B2C receipt is handled inside the POS — no PINT-AE. But if the original sale was a full tax invoice (B2B, or over AED 10,000), the return must be issued as a PINT-AE credit note (cbc:InvoiceTypeCode="381") referencing the original invoice's UUID in cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID.

The most common retail failure is netting a return against a new sale in the same receipt — e.g. customer returns AED 300 of goods and buys AED 500 of new goods, POS prints one receipt for AED 200. Under PINT-AE this is two separate documents: a credit note for AED 300 and a new invoice for AED 500. The net receipt is a customer convenience, not a legal document.

TrustBill's POS bridge detects mixed return-plus-sale receipts and generates the two PINT-AE documents automatically, keeping the printed net receipt for the customer.

Gift-card sale is out of scope for UAE VAT — no supply of goods or services has happened; the card is a stored value instrument. Under PINT-AE, do not submit a gift-card sale as an invoice. Store it in the POS as a stored-value liability.

Gift-card redemption is when PINT-AE applies. The redemption invoice carries the goods being purchased as normal PINT-AE lines, with the gift-card portion of the payment appearing as cbc:PrepaidAmount at the header level (not as an AllowanceCharge discount — the redemption is a payment, not a price reduction).

Loyalty points redemption is similar: points-as-currency use appears in cbc:PrepaidAmount. Points-as-discount use (where redeeming reduces the price rather than paying it) appears as cac:AllowanceCharge. Getting these two treatments right matters for VAT — the discount treatment reduces taxable base; the payment treatment does not.