MINSEONG / GUIDES

UAE eInvoicing reporting obligations: Issuer and Recipient responsibilities under Article 6(6)

Published 24 October 2026 · Official legislation links checked against the project’s regulatory source register · Other official sources last reviewed 22 October 2026 · 12 min read

UAE eInvoicing is not only about creating a structured invoice and transmitting it to a trading partner. Article 6 of Ministerial Decision No. 243 of 2025 also addresses reporting Electronic Invoices and Electronic Credit Notes to the Federal Tax Authority (FTA). Article 6(6) names both the Issuer and the Recipient. That makes reporting a shared compliance-workstream for businesses that issue documents, receive them, or do both.

This guide explains the wording of Article 6(6), the respective roles of Issuers and Recipients, and a cautious procedure for finding out what reporting arrangements apply. It links to the official English text of Decision 243/2025 and the official English text of Decision 197/2026. It is an operational reading aid, not legal advice or an official FTA interpretation. We have not verified the ministerial instrument that specifies the Article 6(6) reporting timeline. Accordingly, this page does not invent a number of days, a technical submission method, a penalty amount, or a detailed data specification.

For the broader document-exchange rules, start with our Issuer and Recipient obligations guide to Article 6. This page concentrates on reporting rather than repeating every invoice, credit-note, timing, and self-billing rule.

What Article 6(6) says

Article 6(6) requires the Issuer and the Recipient to report Electronic Invoices and Electronic Credit Notes to the FTA within the timeline prescribed by the Minister. Three elements matter for operational planning:

Both roles are named. The wording identifies the Issuer and the Recipient. A business should not assume that the other party’s reporting activity automatically removes its own responsibility.
Both document types are named. The paragraph refers to Electronic Invoices and Electronic Credit Notes. A reporting-control design should account for both rather than considering only original invoices.
The timing is prescribed separately. Article 6(6) refers to a timeline prescribed by the Minister. The paragraph itself does not provide a number of days in its text.

Article 6(7) separately says that the Issuer and Recipient fulfil their Article 6 obligations through the appointment of an Accredited Service Provider (ASP). Read Article 6(6) and 6(7) together, these provisions make the ASP relationship an important part of implementation planning. They do not, by themselves, establish every operational detail of reporting, the exact user interface, or which party’s software performs each technical step.

Issuer and Recipient: distinct responsibilities

The Issuer: control the documents you create

In an ordinary sale, the supplier is generally the Issuer. Article 6(1) addresses issuing and transmitting Electronic Invoices for Business Transactions, while Article 6(2) addresses Electronic Credit Notes in specified circumstances. For reporting preparation, an Issuer should be able to identify the invoices and credit notes it generated, their transaction references, the relevant counterparty, and the status information available through its own systems and ASP.

This is a recommended internal control, not a claim that Article 6(6) expressly mandates a particular register or spreadsheet. The purpose is to make it possible to investigate whether a document was created, transmitted, and handled in accordance with the applicable requirements once the authoritative reporting procedure and timeline have been confirmed.

The Recipient: do not treat receipt as the end of the process

In an ordinary purchase, the buyer is the Recipient. Article 6(3) separately requires the Recipient to process Electronic Invoices and Electronic Credit Notes through the Electronic Invoicing System. Article 6(6) also names the Recipient in the reporting obligation. An accounts payable team should therefore work with its ASP and finance systems team to understand the Recipient-side responsibilities, rather than assuming that all relevant duties sit with the supplier.

For practical buyer-side workflows, see the accounts payable and Recipient guide. For the seller-side creation and transmission workflow, see the accounts receivable and Issuer guide. Those pages explain the wider Article 6 context; they do not establish an unverified reporting deadline.

What is confirmed—and what is not

The source material available for this project supports the general Article 6(6) obligation and the fact that the timeline is to be prescribed by the Minister. It does not establish the following details with sufficient evidence for us to publish them as settled requirements:

Exact reporting deadline: the number of days or other time period applicable to each report.
Starting point for the reporting clock: whether the period runs from issuance, transmission, receipt, the transaction date, or another event.
Submission mechanics: the specific interface, API, message flow, file format, acknowledgement, or status code to use for reporting.
Responsibility split inside an ASP workflow: which actions are automated by the ASP and which actions, if any, require a separate action by the Issuer or Recipient.
Penalties for reporting failures: the table annexed to Cabinet Decision 106/2025 has no separate row naming Article 6(6) reporting, and this guide draws no conclusion on whether other penalty legislation applies; see our Cabinet Decision 106/2025 penalties guide.
Detailed reporting fields and corrections: the complete reporting data specification, correction procedure, resubmission rules, and treatment of duplicate or rejected reports.

These are genuine implementation questions, not permission to disregard Article 6(6). Until the official timeline and operational instructions are confirmed, do not substitute a deadline borrowed from another paragraph. In particular, the fourteen Business Day wording in amended Article 6(5) concerns issuance and transmission of Electronic Invoices or Electronic Credit Notes, subject to Article 6(4). It should not be presented as the Article 6(6) reporting deadline.

A practical process for confirming the reporting timeline

The following sequence is an editorial planning method, not an official checklist or a legal test.

Start with the binding text. Read Article 6(6) in Decision 243/2025 and check amendments in the official Decision 197/2026 text. Do not rely only on a summary, an old article, or a vendor presentation.
Check the official Ministry of Finance programme page. Use the MoF eInvoicing programme portal as a starting point for subsequent decisions, official announcements, and guidance. Confirm the publication date, scope, effective date, and whether a document actually prescribes the reporting timeline.
Ask the ASP for the exact authority. Request the official instrument or instruction that defines the reporting period, its start event, the party responsible for each step, and how successful submission is evidenced. A provider’s product behaviour is not a substitute for the underlying legal source.
Separate legal timing from internal service targets. Your organisation may choose an internal target for reviewing exceptions or reconciling reports. Label it as an internal control, not as the statutory reporting deadline.
Record what has been verified. Keep the source title, article or paragraph, URL, publication or effective date where available, review date, and the person or function that owns the next check. If no official deadline has been found, record that as unresolved rather than entering an estimated date.
Recheck when official instructions change. Assign responsibility for checking official MoF and FTA updates, reviewing the ASP’s implementation notes, and assessing whether system configuration or procedures need to change.

Build a document-level evidence trail

While the exact reporting specification remains to be verified, businesses can prepare their internal evidence without pretending that a particular field is legally mandated. Consider maintaining a controlled record of:

the document type (Electronic Invoice or Electronic Credit Note) and an internal identifier;
the Issuer and Recipient as represented in the relevant business records;
the transaction reference and links between a credit note and related records where those links are available;
the creation and transmission timestamps recorded by the business or ASP, without treating either as the unverified reporting-clock start;
the reporting or processing status actually exposed by the ASP, with the source of that status documented;
exceptions, investigation notes, corrective actions, and the evidence used to close them; and
the official guidance version used to determine the applicable process.

This list is a suggested control design. It is not a representation of mandatory Article 7 fields, a complete FTA reporting schema, or proof that a particular ASP status equals legal acceptance by the Authority. Confirm the official data model and status meanings before using them for regulatory conclusions. Our record-keeping and archiving guide discusses evidence retention, and the month-end reconciliation guide explains how to investigate differences between invoice records and ledger data.

Design the control across finance and IT

Reporting should not be left entirely to a tax specialist after the system has gone live. Assign clear ownership for the legal source, document data, integration, monitoring, and exception handling. A workable division of internal responsibilities could look like this:

Tax or finance policy owner: verifies the authoritative rule, the effective date, and how it applies to the organisation’s transactions.
Accounts receivable: reconciles issued invoices and credit notes to the records and statuses available from the invoicing workflow.
Accounts payable: confirms incoming documents are processed through the applicable system and investigates unresolved Recipient-side exceptions.
IT and integration owner: documents message flow, access, monitoring, error handling, and the evidence available from the ASP integration.
ASP relationship owner: obtains written clarification of the provider’s workflow and maps it to the verified legal requirements.

These are suggested internal roles, not roles prescribed by Article 6(6). In a smaller organisation one person may cover several functions. What matters operationally is that the business can identify who checks official changes, who investigates exceptions, and who keeps the evidence.

Questions to take to your ASP and adviser

Before configuring production controls, ask for answers that point to an authoritative source or a clearly labelled technical implementation note:

Which official instrument or instruction prescribes the Article 6(6) reporting timeline, and when did it take effect?
What event starts the reporting period, and how is the due time calculated?
How are Issuer-side and Recipient-side responsibilities represented in the workflow?
Does the ASP report automatically, or must the customer perform an additional action? What official text supports that interpretation?
What acknowledgement or status is returned, and what does it actually prove?
How are failed, duplicated, corrected, or late reports handled under the applicable official instructions?
Which official rule governs any alleged penalty, and what conditions must be met before it applies?

Keep legal interpretation separate from product configuration. An ASP can explain what its service does, while a qualified tax adviser can help interpret how the binding rule applies to a particular business. Neither should be asked to fill a missing official requirement with an unsupported assumption.

Implementation checklist

Use this as a project-planning aid and adapt it to your organisation; it is not an official FTA checklist.

Identify which business flows make the organisation an Issuer, a Recipient, or both.
Include Electronic Invoices and Electronic Credit Notes in the reporting control inventory.
Confirm the organisation’s ASP arrangements and document the actual reporting workflow.
Obtain and archive the official source that prescribes the reporting timeline before setting a legal due-date rule.
Keep internal service-level targets visibly separate from statutory deadlines.
Agree owners for monitoring, exception investigation, reconciliation, and regulatory source reviews.
Test normal and exception scenarios using the actual ASP implementation and verified instructions.
Update procedures when the official rule or confirmed technical workflow changes.

For a wider delivery plan, use our UAE eInvoicing readiness project plan and go-live testing checklist. These help organise work but do not replace the legal source needed to set a reporting deadline.

Frequently asked questions

Does Article 6(6) name only the Issuer?

No. The paragraph names both the Issuer and the Recipient in relation to reporting Electronic Invoices and Electronic Credit Notes to the FTA. A business should confirm the responsibilities that apply to its role rather than assume that its counterparty alone is responsible.

Is the reporting deadline fourteen Business Days?

This guide has not verified an official Article 6(6) reporting timeline. The fourteen Business Day period in amended Article 6(5) concerns issuing and transmitting documents and is subject to Article 6(4). It must not be reused as the reporting deadline without an independent authoritative basis.

Does appointing an ASP mean the business has no responsibility?

Article 6(7) says the Issuer and Recipient fulfil their Article 6 obligations through appointment of an ASP. That wording makes the ASP arrangement relevant, but this guide cannot conclude that appointment alone removes every responsibility or exception-handling duty. Confirm the legal interpretation and actual service workflow.

What penalty applies if a report is late or missing?

No penalty amount is stated here. The table annexed to Cabinet Decision 106/2025 has no separate row naming Article 6(6) reporting (see our penalties guide), and we have not confirmed whether other penalty legislation applies. Do not assume that a penalty for a different obligation automatically applies to Article 6(6).

What should we do until the reporting instructions are confirmed?

Keep both roles in scope for planning, appoint clear internal owners, maintain document and exception records, ask the ASP for the official basis of its workflow, and check current official MoF and FTA materials. Do not invent a due date or treat an internal target as a statutory requirement.

Official sources and scope of this guide

Ministerial Decision No. 243 of 2025 on the Electronic Invoicing System — official English text.
Ministerial Decision No. 197 of 2026 amending Decision 243/2025 — official English text.
UAE Ministry of Finance eInvoicing programme portal — starting point for official programme material and subsequent updates.

The legal point made here is deliberately narrow: Article 6(6) names both Issuers and Recipients, covers Electronic Invoices and Electronic Credit Notes, and refers to a timeline prescribed by the Minister. This page does not claim to have verified the specific reporting period, the full technical specification, or the penalties. Recheck official materials before using this guide to configure legal deadlines or advise on a particular case.