What the FTA Receives: The UAE Tax Data Document
In UAE e-invoicing the Federal Tax Authority gets a Tax Data Document for each invoice. What it holds, who files it, which types exist, and what you keep.
The UAE Tax Data Document is the report that a service provider files with the Federal Tax Authority (FTA) for each e-invoice or credit note. It is a document in its own right, defined by its own OpenPeppol specification, and it holds two things: a short summary of the invoice and the full invoice file itself. The business does not write it. Its service provider does.
This page explains what the document contains, who files it, what its types mean and what a business should keep. The structure below was read on 11 November 2026 from OpenPeppol's UAE Tax Data Document 1.0.4 (the rule sheet and published examples, downloaded 8 October 2026). Release notes date version 1.0.4 to 29 July 2026, maintained by the UAE Peppol Authority.
What is the fifth corner?
In an ordinary Peppol exchange there are four corners: the seller, the seller's access point, the buyer's access point and the buyer. The UAE adds a fifth: the Federal Tax Authority. The FTA does not sit between buyer and seller. It receives a report of each transaction, in addition to the invoice travelling to the buyer. Our readiness guide gives the overview in one table row. This page is the detail.
If you have read how Oman does it, the shape is familiar: the Oman five-corner explanation and the Oman tax data document deep-dive describe the same idea under a different authority. The UAE document is its own specification, with its own identifiers and rules, so do not carry Oman field names across.
What does the Tax Data Document contain?
The rule sheet's checks show the structure. A Tax Data Document is made of four parts.
A header that identifies the report. It uses the customization identifier urn:peppol:taxdata:ae-1 and the business process urn:peppol:taxreporting. It has its own issue date, which must not carry a time zone, and its own issue time, which must carry one. It has a type code and a scope code, covered below.
The parties to the report. The reporter has an endpoint with a scheme identifier. The receiver has an endpoint that must be under scheme 0242, the scheme for service provider identifiers, because the receiving end is the Authority's corner, addressed as a provider. Exactly one reporter's representative identifier must be present, also under 0242. That identifier is the service provider acting for the reporter.
The reported document. A summary of the invoice, required in every case except a failed transmission. Under the rules it must give the invoice number, the UUID, the issue date, the type code and the document currency. It must have the seller, and the buyer unless the transaction is an export. It must give the VAT total for each currency used, the total without VAT, and the invoice total with VAT in AED as custom content.
The source document. The invoice or credit note itself, as the UBL XML, embedded. Rule ibr-tdd-57 requires either a UBL 2.1 Invoice or a UBL 2.1 Credit Note.
So the Authority does not receive only a summary. It receives the summary and the full file, in a form it can read directly. That is why an error in the invoice is also an error in the report, and why the field rules in the mandatory fields of a UAE e-invoice matter beyond the buyer's inbox.
Who sends it?
The service provider. The business issues the invoice; its provider reports it. That follows from the rule that a reporter's representative must be present and must be a provider identifier. It is also why the UAE system turns on provider accreditation: the Ministry publishes a list of Accredited Service Providers, and choosing one is the step that comes before any of this.
Two sides can report. The document has a reporter's role with two values, 01 and 02. GoRoute's reading of the specification is that the seller's provider files under one and the buyer's provider under the other. We did not find the role definitions stated in plain words in the files we read, so treat that as our reading and confirm the split with the provider you choose.
What are the document types?
The type code has four allowed values in the rule sheet, and the code list is closed: any other value fails.
| Code | Meaning | When it appears |
|---|---|---|
| S | Submit | The first report of an invoice or credit note |
| R | Resubmit | A corrected report after one was rejected |
| W | Withdraw | A report taken back after it was filed |
| F | Failed transmission | A report with no reported document, because the invoice could not be delivered or accepted |
The scope code takes three values: D, IP and INP. The rule sheet defines the list but not, in the files we read, what each value means in plain words, so we do not define them here.
The F type is the only one allowed to omit the reported document (rule ibr-tdd-22).
When is it sent, and how fast?
The UAE Peppol Authority's specific requirements, called PASR, set time limits for the status messages and for the report. GoRoute's engineering notes record 10 minutes for a status message and 15 minutes for the report. We did not re-read the PASR text itself on the day. Confirm the figures against it before building anything on them.
What does not depend on those figures: a business should expect the report to follow the invoice within minutes, not days. That is what "near real time" means in the readiness guide's table.
What does the business keep?
The report is the provider's to file, but its outcome is the business's to know. Keep three things together for each invoice: the invoice file as issued, the UUID, and whatever the provider returns about the report's result. When a report is rejected, a finance team needs to see that against the invoice without asking.
The document does not change what an invoice must contain, and it does not replace any other record you keep for VAT purposes. How long records must be kept is not covered here. Do not infer a retention period from this page.
What is outside this page?
How an FTA portal login or EmaraTax enrolment works is not covered: it is a procedure on the authority's side and we did not read it. How a correction travels is in credit notes and corrections under UAE e-invoicing. Which ERP fields feed this report is in UAE e-invoicing from Oracle, SAP and Dynamics.
GoRoute is not on the Ministry's list of Accredited Service Providers. It is a certified Peppol Access Point, POP000991.
Where to go next
Start with our UAE e-invoicing page for the dates. To see how a provider connects an ERP and watches report status, take the GoRoute tutorials or the developer documentation. To talk through your own setup, book a call.
Sources: OpenPeppol, UAE Tax Data Document 1.0.4 (rule sheet and examples, downloaded 8 October 2026; release notes dated 29 July 2026); OpenPeppol, PINT AE Billing 1.0.4; UAE Ministry of Finance, list of Accredited Service Providers. The PASR figures are from GoRoute's engineering notes and were not re-read at the source. Prepared by Lisa Thompson, GoRoute's AI marketing operations manager; reviewed by Dr. Syed Raza.
Frequently asked questions
- What is the UAE Tax Data Document?
- A report of an invoice or credit note that a service provider sends to the Federal Tax Authority. It is a separate Peppol document type, version 1.0.4 on OpenPeppol, with its own identifier (urn:peppol:taxdata:ae-1) and its own validation rules. It carries a summary of the invoice and the invoice itself.
- Who sends it, the business or its provider?
- The provider. The document names a reporter's representative, which must be a service provider identifier under scheme 0242. The business issues the invoice; its Accredited Service Provider files the report.
- Does the buyer's side report too?
- The document has a reporter's role with two values, 01 and 02. GoRoute's reading is that the seller's side files under one role and the buyer's side under the other, so a single invoice can produce two reports. Check the exact split with your provider.
- What happens if the FTA rejects a report?
- The document type code has four values. S submits a report, R resubmits a corrected one, W withdraws one already filed, and F reports a failed transmission. Which one your provider uses, and when, is part of its service.
- Does the UAE model clear invoices before they go to the buyer?
- The model is five corner, not clearance. The invoice travels between the two providers over Peppol, and the Authority receives a report alongside. Whether a given report can delay delivery is a question for the Ministry's published requirements, not one this page can answer.
About Dr. Syed Raza
Dr. Syed Raza is an IT Enterprise Architect at ClayDesk LLC and leads the GoRoute platform. He works across Peppol Access Point and SMP infrastructure, PINT jurisdictions (Oman, AU/NZ, EU, JP, MY, SG), and national CTC regimes, translating regulatory detail into production-grade e-invoicing systems.
Building on Peppol?
GoRoute is a certified Peppol Access Point & SMP. Book a demo or read the docs to get started.