Simplified Tax Invoice Removal in the UAE

The short invoice still exists, but its use is narrower

Cabinet Decision No. 100 of 2025 amended Article 59 of the VAT Executive Regulation. It did not erase the simplified tax invoice. The document still carries the supplier’s name, address and TRN, issue date, description, total consideration and VAT in AED. The real change is the permitted use: the simplified form is tied to an unregistered customer or a registered customer whose consideration does not exceed AED 10,000.

That matters because a till receipt is not automatically wrong, and it is not automatically enough. A Dubai retailer needs to identify the customer status and the value of the supply before deciding which invoice path to use. The reverse-charge mechanism is a separate exception. Where it applies, do not stretch the simplified-invoice permission to cover the transaction.

• Article 59(2) lists the fields a simplified tax invoice must contain.
• Article 59(5) limits when that short form may be issued.
• The AED 10,000 test is tied to a supply’s consideration.
• Reverse-charge transactions need their own evidence route.

Start with the customer record, not the printer setting

Start with the customer record, not the printer setting. A grocery shop serving walk-in consumers will often issue simplified invoices because its customers are not registrants. A wholesaler selling to a VAT-registered hotel has a different question, even if the amount on the paper looks similar. The customer’s TRN, the contract and the order value change the required route.

The AED 10,000 test is per supply, so a business should not split one commercial order merely to keep each receipt below the line. That is a control question for the sales ledger and contract, not a formatting trick. If the customer gives a TRN after the sale, preserve the original transaction record and ask the accountant whether a corrected tax invoice or credit-note process is required.

The customer-status check should happen at onboarding and again when a wholesale order is raised. A saved TRN is useful, but the order, invoice and customer file still need to match. If the sales team cannot tell whether the recipient is registered, route the transaction for review before the receipt is finalised. That creates less work than reconstructing a sale later.

• Walk-in consumer sales and B2B sales need separate test cases.
• The customer master file should preserve registration status.
• Orders, invoices and receipts should tell the same story.
• Returns and discounts must not hide the final consideration.

The point-of-sale system is only one part of the file

Your review should cover the fields produced by the point-of-sale system, the customer master file, the sales ledger and the document archive. Compare a printed receipt with the Article 59(2) fields. Then compare a B2B tax invoice with its sequential number, dates, description, value and VAT. Keep the actual sample exports. A screenshot of a settings page proves little.

The e-invoicing layer adds another object. The Ministry of Finance portal describes an e-invoice as structured data exchanged and reported electronically, and says a PDF, scan, image or email is not an e-invoice. Your provider may call a PDF export compliant, but the format and exchange path must be tested against the UAE standard, not the sales pitch.

• Retain a sample from the till and the accounting system.
• Check customer data before checking invoice styling.
• Test credit notes, refunds and discounts as separate flows.
• Keep the provider’s field mapping with the implementation file.

Test the invoice routes before renewing the till

If you are deciding whether to renew or replace the till, begin with a transaction sample from one normal week. Pull consumer sales, B2B sales, returns, discounts and any reverse-charge entry. Mark the customer status and the invoice type for each sample. This is where a short review can expose a bad default, such as every customer being treated as unregistered.

Next, give the provider four tests: generate a simplified invoice for a consumer, a full tax invoice for a registrant, a supply above AED 10,000, and a credit note after a return. Save the output and the source data. Ask who owns the mapping when a field is missing. Record the answer in the implementation file so the next change does not reopen the same question.

Do not accept a green status light as the test result. The retained sample should show the raw transaction, the customer status, the document produced and the ledger entry. If the vendor cannot provide that chain, record the limitation and keep the current control in place until an accountant confirms the replacement process.

• Pull the sample from live sales data, not a demo account.
• Test both the printed document and the ledger posting.
• Save failed outputs beside the corrected outputs.
• Assign an owner for each unresolved field.

The arithmetic is simple; the evidence makes it usable

Example: a shop records a taxable sale of AED 8,000. At the standard 5% VAT rate, VAT is AED 400, so the customer-facing total is AED 8,400, calculated as AED 8,000 + AED 400 = AED 8,400. If the customer is not a VAT registrant, the Article 59 route can support a simplified invoice. The arithmetic is simple; the customer classification and stored receipt make the position defensible.

The FTA-hosted Executive Regulation sets the fields and the AED 10,000 test, but it does not specify how every mixed basket, loyalty discount or legacy POS export should be mapped during a software transition. That is the boundary of the evidence. We would not replace a POS solely because it prints a simplified invoice. We would first test the source data, because a perfect template cannot repair a wrong customer record.

• Work rises with the number of tills and sales channels.
• A damaged customer master file needs more checking.
• Missing exports make testing slower and less certain.
• Returns, discounts and B2B flows add separate review work.