- HOME
- Taxes & compliance
- AR eInvoicing in the UAE: how to issue, track and correct invoices
AR eInvoicing in the UAE: how to issue, track and correct invoices
It is 15:47 on a Tuesday. A UAE supplier's billing system shows the day's tax invoices as "sent". The credit controller opens the ledger to start calls on two invoices that are past their promised payment date.
One of them has no confirmation from the buyer's Accredited Service Provider (ASP), the company that receives eInvoices for the buyer. It also has no confirmation that its tax data reached the Federal Tax Authority (FTA). The invoice left the billing system and reached the supplier's own ASP. Nothing after that has been confirmed. The buyer has not received the structured invoice.
So the credit controller should not call the customer about payment yet. The first job is to find out why the invoice has not been delivered.
That gap between "sent" and a confirmed exchange is where accounts receivable (AR) now works in the UAE. UAE eInvoicing does not remove any AR decision: pricing, credit, collections and disputes all stay. But it adds two events that AR must see and act on. One is the confirmation that the buyer's ASP received the invoice. The other is the confirmation that the FTA received the tax data. This guide shows how to design AR around those events, from customer master data to issue, tracking, correction and cash collection, on top of the UAE 5-corner model.
What changes for a supplier under UAE eInvoicing?
A supplier in scope issues each in-scope invoice as a structured XML file built to the PINT AE specification. It sends the file through its ASP. The invoice counts as delivered only when the buyer's ASP confirms receipt.
Three states now replace the single "sent" flag:
• Sent to your ASP: the invoice has left your billing system.
• Delivered: the buyer's ASP has validated and confirmed the invoice.
• Reported: the FTA has confirmed the tax data your ASP reported.
Each state has its own owner, and AR needs an action for each one.
The deadlines depend on revenue. Suppliers with revenue of AED 50 million or more must appoint an ASP by 30 October 2026, following the Ministry of Finance's May 2026 amendment, and issue eInvoices from 1 January 2027. Suppliers below AED 50 million must appoint an ASP by 31 March 2027 and go live on 1 July 2027. Any business could join voluntarily from 1 July 2026, and Cabinet Decision No. 106 of 2025 states that its penalties do not apply to a business issuing eInvoices on a voluntary basis.
For AR, the scope rule is simple. Business-to-business (B2B), business-to-government (B2G), government-to-business (G2B) and government-to-government (G2G) sales are in scope. Business-to-consumer (B2C) sales are not. Exports to customers outside the UAE are also in scope. Three narrow exclusions apply: airline passenger transport where an electronic ticket is issued, VAT-exempt financial services, and certain government activities carried out in a sovereign capacity.
What must be ready before a supplier issues an eInvoice?
Which customer identifiers does AR need?
A UAE eInvoice cannot be issued cleanly if the customer record is wrong. AR needs three identifiers on file, and they are different fields:
• The customer's Tax Registration Number (TRN), if the customer holds any FTA tax registration for VAT, Corporate Tax or Excise. Not every customer has one. A business below the AED 375,000 VAT registration threshold that has not registered voluntarily, and has no Corporate Tax registration, has no TRN.
• The customer's Tax Identification Number (TIN). If the customer has a TRN, the TIN is its first 10 digits, as section 9 of the UAE Electronic Invoicing Guidelines, version 1.1 (Guidelines v1.1) explains. A customer with no FTA tax registration gets a TIN separately through EmaraTax, the FTA's online portal. Each member of a tax group has its own TIN, taken from its own TRN, not the group representative's.
• The Participant Identifier. This is scheme 0235 followed by the customer's 10-digit TIN. It is the customer's address on the Peppol network, and it is a different field from the TRN printed on the invoice.
Under item 1 of section 12.2 of Guidelines v1.1, the TRN is not mandatory on Commercial Invoices, or on out-of-scope and exempt transactions.
Decide who owns each field. If AR, sales operations and the master data team all edit the same record from different screens, it will drift.
Field | Owner | Source | Check before first invoice |
Legal name | Master data | Trade licence or commercial register | Exact match to the licence |
Address | Master data | Customer confirmation at onboarding | Emirate and country code filled in |
TRN, if held | Tax or AR onboarding | FTA registration certificate | Present and active if the customer has one |
TIN | Systems | First 10 digits of the TRN, or a separate EmaraTax registration | Present on the customer record |
Participant Identifier | Systems | 0235: followed by the TIN | Present before the first invoice |
Default invoice type | Tax or AR | Standard billing or an agreed self-billing arrangement | Matches the customer's VAT position |
Payment terms | Credit | Approved credit policy | Matches the credit limit review |
eInvoice contact | AR | Customer onboarding form | A named person and inbox |
Some customers are not ready to receive eInvoices yet, either because they have no TIN or because they have not appointed an ASP. They need a different routing rule, covered in the special cases section below.
Which document type and tax category apply?
Every document falls into one of the six invoice categories in section 10.1 of Guidelines v1.1. Each has a document type code from PINT AE:
Document | Standard billing | Self-billing |
Tax Invoice | 380 | 389 |
Tax Credit Note | 381 | 261 |
Commercial Invoice (outside the scope of tax) | 480 | Not available |
Credit Note (outside the scope of tax) | 81 | Not available |
Each line also carries one of six tax categories, under section 10.5: standard rate, exempt, outside the scope of VAT, reverse charge, zero rated or margin scheme. When the customer is a Free Zone entity, the Free Zone scenario in section 10.4 requires beneficiary details on the invoice.
The full list of mandatory fields is in the UAE eInvoice format guide, and transaction scenarios such as exports, deemed supply and summary invoices are in the UAE eInvoicing use cases guide. AR does not need to memorise them. It needs to know one rule: the document type and scenario are chosen when the invoice is issued, and they cannot be changed quietly afterwards.
How should the AR workflow run under UAE eInvoicing?
Step 1: What triggers the invoice?
The trigger has not changed. It is still an approved sales order, a subscription, a service confirmation or a manual bill. What has changed is the output. The invoice must be produced as XML to PINT AE, with the customer's Participant Identifier, the right document type code and every mandatory field filled in. Your accounting system should block release until the customer record check and the mandatory field check both pass.
Step 2: What should AR check before sending?
Check the invoice before it leaves your system. Block any invoice that fails the file structure check, has a document type that does not fit the scenario, or has a tax category that does not match the supply. Block duplicate references, with the same document number and customer, at this point. Do not rely on the buyer's side to catch them.
Step 3: What happens when the invoice goes through your ASP?
Your billing system (Corner 1, or C1) sends the invoice to your ASP (Corner 2, or C2). Your ASP validates it, converts it to the UAE standard XML format if it is not already in that format, and sends it to the buyer's ASP (Corner 3, or C3). At the same time, your ASP reports a Tax Data Document (TDD) to the FTA (Corner 5, or C5). This follows section 5.1 of Guidelines v1.1.
Cabinet Decision No. 106 of 2025 penalises a failure to "issue and transmit an Electronic Invoice to the Recipient". So treat an invoice as done when the buyer's ASP confirms receipt, not when it leaves your billing system.
Step 4: Which confirmations should AR monitor?
Two confirmations come back to you. The buyer's ASP confirms that it received and validated the invoice. The FTA confirms that it received the tax data your ASP reported. Your ASP forwards both to you. The Ministry of Finance (MoF) calls these Message Level Status (MLS) messages: an exchange MLS and a reporting MLS.
The buyer's ASP also reports its own tax data to the FTA and receives its own confirmation. That confirmation goes to the buyer, not to you. So AR tracks two confirmations per invoice, not three.
Step 5: Who should fix each type of exception?
If a confirmation is negative, or does not arrive within your agreed time, send the exception to the person who can fix it. That is rarely AR:
• File structure errors go to systems.
• Customer record errors go to master data.
• Document type or scenario errors go to tax.
• A real problem with the supply goes to sales.
Step 6: How should confirmation status feed collections?
Delivery on the network and payment terms are separate things. UAE eInvoicing rules do not set payment terms or the date when ageing starts. Those come from the contract or your standard terms.
Pass the exchange status to collections as information, not as the start of the due-date clock. It tells collections whether the invoice reached the buyer's system. It separates a delivery failure from a payment problem. And it gives both teams one timestamped record. A delivered invoice can still be disputed, short-paid or challenged. Cash application still matches receipts to the invoice reference, as before.
What should AR do for each confirmation status?
Guidelines v1.1 does not define named invoice statuses. The table maps the confirmation events in section 5.1 and section 16.2.4 of Guidelines v1.1 to an owner, a customer message and a collections action.
Event | Owner | Customer communication | Collections action |
Sent to your ASP, no confirmations yet | Systems or ASP operations | None | Do not treat as delivered; watch for the confirmation |
Negative exchange confirmation from the buyer's ASP | Systems or master data | Contact the customer only if the cause is on their side, such as a wrong Participant Identifier; otherwise fix it internally | Pause reminders while the invoice is fixed; the contractual due date is unchanged |
Positive exchange confirmation from the buyer's ASP | AR | Optional acknowledgement | Delivery confirmed; collect on the due date in the contract |
Your reporting confirmation has not arrived | Tax or systems | None; this is not a customer issue | Continue on normal terms while your ASP resolves it |
Positive reporting confirmation for your tax data | Tax | None | Reporting confirmed; normal collections continue |
Commercial dispute raised by the buyer | AR or sales | Log the dispute with the customer | Hold only the disputed line or amount, not the whole account |
Many ASPs show exchange results using the response codes in OpenPeppol's MLS specification: AP or AB when delivery succeeded, and RE when it failed.
A negative confirmation is a technical event. It becomes a customer matter only when the cause sits with the customer. A commercial dispute is the opposite: the network delivered the invoice, but the two businesses disagree about the substance. Show the two separately in the AR view, so collections staff do not mistake a technical rejection for a customer complaint.
How should AR correct an eInvoice?
When can AR fix and resend instead of issuing a credit note?
Guidelines v1.1 describes no way to edit an eInvoice after it has been exchanged. Before the invoice leaves your system, you can still revise it. If the buyer's ASP rejects it, the invoice was never delivered as a valid eInvoice, so you fix the data and send it again.
Once an invoice has been delivered, every correction needs a new document: a credit note to reduce the amount, or an additional invoice to increase it. Keep the original, any credit note and any new invoice together on one customer record.
When does AR need an electronic credit note?
Use an electronic Tax Credit Note (code 381), or a self-billed Tax Credit Note (code 261), when the original Tax Invoice was delivered and the value, quantity, tax category or supply changes. The UAE eInvoicing credit notes guide covers the full decision path.
Situation | Action | Document |
Invoice not yet sent | Revise it before release | The original invoice, same type |
Sent, then rejected by the buyer's ASP | Fix the data and resend through the normal exchange | Same document type; ask your ASP whether to reuse the original number or issue a new one |
Delivered, wrong quantity or price | Issue a credit note, then a new invoice if the supply still stands | 381 (or 261), plus a new 380 |
Delivered, supply cancelled | Issue a full credit note reversing the original | 381 |
Delivered, wrong tax category | Issue a credit note reversing the original and a new invoice with the right category | 381, plus a new 380 |
Out-of-scope supply needs correcting | Issue a credit note outside the scope of tax | 81 |
A negative confirmation does not cancel the supply. It only means the invoice was not delivered or not reported. Whether a credit note is needed depends on the supply itself.
Three rules cover most cases:
Rejected before delivery: fix the data and resend.
Delivered, then the amount changes: issue a credit note to reduce it or an additional invoice to increase it.
Delivered, then disputed: correct it with a credit note or an additional invoice, never by editing the original.
How should AR handle customers who are not ready and other special cases?
Some buyers will not have a Participant Identifier when you invoice them, especially in the early months after Phase 1 go-live. For Tax Invoices, section 10.2.2 of Guidelines v1.1 covers this case. Put the fixed address 0235:9900000098 on the eInvoice. The eInvoice is still issued and reported. Because the buyer cannot receive it through an ASP, also send the buyer a regular Tax Invoice by PDF or paper, through your usual channel.
Two more fixed addresses apply in section 10.4. For an export where the buyer has no Peppol ID, use 0235:9900000099. For a deemed supply, the buyer address is always 0235:9900000097.
If a system failure stops you from issuing invoices, Article 12 of Ministerial Decision No. 243 of 2025 requires you to notify the FTA within two business days. Appendix 3 of Guidelines v1.1 asks businesses to make sure their ASP notifies the FTA of a service disruption in a timely manner. Your own duty stays in place even when your ASP sends the notice.
Cabinet Decision No. 106 of 2025 sets these penalties for AR:
• AED 1,000 per day for late notification of a system failure.
• AED 100 per eInvoice not issued and sent on time, up to AED 5,000 per month.
• AED 100 per electronic credit note not issued and sent on time, with its own cap of AED 5,000 per month.
Keep issued eInvoices, credit notes and associated data for five years after the end of the tax period, or seven years for real estate, under Article 11 of Ministerial Decision No. 243 of 2025 and section 5.4 of Guidelines v1.1. See UAE eInvoice retention periods and audit records for the detail.
Which controls and metrics should AR track?
Measure these before your go-live date, so you can see any drop in performance after the switch:
Metric | Definition | Source | How often |
Time to delivery | Median and 95th percentile hours from building the invoice to the buyer's ASP confirmation | Billing system and ASP log | Daily |
Negative exchange confirmation rate | Share of sent invoices rejected by the buyer's ASP | ASP log | Weekly |
Missing reporting confirmation rate | Share of sent invoices without a reporting confirmation for your tax data | ASP log | Weekly |
First-time clean rate | Share of invoices delivered and reported without any correction | Billing system and ASP log | Monthly |
Credit note ratio | Credit notes per 100 invoices, by root cause | AR module | Monthly |
Days sales outstanding (DSO) | Standard AR definition | AR module | Monthly |
Unconfirmed invoice ageing | Invoices with no positive confirmation, by age | ASP log | Daily |
Keep a dispute evidence pack for each invoice, filed under the invoice reference:
• the XML file and its readable view;
• the exchange confirmation from the buyer's ASP;
• the reporting confirmation for your own tax data;
• a snapshot of the customer record at the time of issue;
• any linked credit notes and new invoices;
• your correspondence with the customer's named contact;
• the internal approval trail for any manual adjustment.
Zoho Software Trading LLC is a Ministry of Finance-accredited eInvoicing service provider for the UAE, with accreditation number 121988, as shown on the MoF register of accredited service providers. AR runs best when the accounting system, the ASP connection and confirmation tracking work together, so each invoice's delivery and reporting status sits on the same customer record that collections uses.
Explore UAE eInvoicing with Zoho Books
Frequently asked questions
Is an eInvoice complete when the billing system says "sent"?
No. In most billing systems, "sent" means the invoice reached your own ASP. A UAE eInvoice is delivered only when the buyer's ASP confirms receipt. Your side of the reporting is complete when the FTA confirms the tax data your ASP reported. Treat "sent" as the start of the process, not the end.
What should AR do when the buyer is not ready for eInvoicing?
For a Tax Invoice, issue the eInvoice with the fixed address 0235:9900000098, and also send the buyer a regular Tax Invoice by PDF or paper. Once the buyer has joined eInvoicing, the electronic exchange is the only channel you need.
Can an issued eInvoice be edited?
No. Once an eInvoice has been delivered, corrections need a new document: a credit note (code 381, or 261 for self-billing), plus a new invoice if the supply still stands.
Does a negative confirmation cancel the sale?
No. A negative confirmation means the invoice was not delivered or not reported. Whether the customer still owes the amount depends on the contract, not on the network status.
Do export invoices need to go through eInvoicing?
Yes. Exports to customers outside the UAE are an in-scope scenario under section 10.4 of Guidelines v1.1. If the foreign buyer has no Peppol ID, use the fixed address 0235:9900000099.
Related guides
• How UAE eInvoicing works: the 5-corner model, end to end
• How UAE eInvoicing changes accounts payable, accounts receivable and month-end close
• AP eInvoicing in the UAE: receiving, matching and processing invoices
• UAE eInvoicing use cases: scenarios, document types and required data
• UAE eInvoice retention: periods, storage and audit records