Credit Notes and Corrections Under UAE E-Invoicing

The way to correct an e-invoice that has already been issued under UAE e-invoicing is a credit note that refers to the original invoice. In PINT AE 1.0.4 a credit note is its own document with its own type code, a mandatory reason code and, in most cases, a reference to the invoice it corrects. If the sale still stands at a different amount, a new invoice follows.

This page sets out those rules in the order a finance team meets them. Everything below was read on 11 November 2026 from OpenPeppol's PINT AE Billing 1.0.4 (rule sheet and published examples, downloaded 8 October 2026). Where the files are silent, the page says so.

Why is an issued e-invoice corrected rather than changed?

Because it has already left. An issued PINT AE invoice carries a UUID, goes to the buyer's service provider and is reported to the Federal Tax Authority. Editing it afterwards would leave three parties holding different versions of one document.

We should be plain about the limit of that statement. It is our reading of how the document types fit together, not a quotation. PINT AE offers invoices and credit notes, and no document type for removing an invoice. We did not find a Ministry text that states the correction procedure in so many words, so confirm special cases, such as an invoice issued to the wrong buyer, with your provider before you rely on this page.

Which type codes apply?

PINT AE 1.0.4 has two credit note codes in its billing profile and one for self-billing:

• 381, credit note. The ordinary case: a return, a price correction, an invoicing error.
• 81, credit note related to goods or services. Used with the out-of-scope handling. Rule ibr-122-ae says that where the type is 81, every VAT category on the document must be exempt, not subject to VAT, or zero rated. Rule ibr-136-ae requires the buyer's legal registration identifier on an 81.
• 261, self-billing credit note. Under the separate self-billing profile. Rules for it are outside this page.

A credit note is a UBL 2.1 CreditNote document, not an invoice with negative numbers. In OpenPeppol's published standard credit note the quantities and amounts are positive (a credited quantity of 2000 and a payable amount of 11,175.50 AED, for example). The document type carries the direction, so do not send negative numbers unless your provider tells you to.

What is the credit note reason code?

On a type 381, a reason code is required. Rule ibr-158-ae: "Where the Invoice type code [IBT-003] is 'Credit note', Credit note reason code [BTAE-03] MUST be there." The code goes in cac:DiscrepancyResponse/cbc:ResponseCode.

The code list has values from DL8.61.1.A to DL8.61.1.E, plus VD. The published example credit note uses DL8.61.1.E. VD is the volume discount, and OpenPeppol publishes a separate example for it. We did not find plain-English meanings for each of the five DL8 codes in the files we read, so this page does not guess them. Your provider's reason-code picker will show the wording for the version it validates.

How does the credit note point at the original invoice?

Through the preceding invoice reference, a cac:BillingReference holding the original invoice number and its issue date. In the published example it reads as the original's identifier (Sample-02) and date.

The rule is ibr-055-ae: the reference is required on a 381 or an 81, except where the reason is VD. With VD, the rule requires the reference to be absent. That is the one case where the credit note is not tied to a single invoice, which fits a discount that spans a period.

So the reference matters in three ways. A credit note without it fails validation, unless it is a volume discount. A VD credit note with it also fails. And a reference to the wrong invoice number validates but corrects the wrong thing, so your master data has to carry the original's number into the credit note.

What else is different on a credit note?

Three rules relax or change compared with an invoice:

• No VAT point date. Rule ibr-124-ae: the VAT point date must not be present on a credit note. On an invoice it must be earlier than the issue date (ibr-141-ae).
• No payment due date needed. Rule ibr-127-ae requires a due date for an invoice with an amount payable above zero, except for credit notes.
• No payment means needed. Rule ibr-191-ae requires payment means on an invoice, again except on a credit note.

What stays the same: the customization identifier (urn:peppol:pint:billing-1@ae-1), the UUID, the seller and buyer rules, the line classification and the AED amounts when the currency is not AED. The full field set is in the mandatory fields of a UAE e-invoice.

What reaches the Federal Tax Authority?

The credit note is reported like an invoice. The Tax Data Document's source document may be a UBL invoice or a UBL credit note (rule ibr-tdd-57), so a credit note travels to the Authority inside its report, in full. How that report is built is in what the FTA receives: the UAE tax data document.

A separate point: a report can itself be resubmitted or withdrawn, using the types S, R, W and F. That is the provider's mechanism for a report, not a way for a business to retract an invoice, and it is not a substitute for a credit note.

What should a finance team set up first?

Four practical steps, in this order. These are working practices, not requirements from the specification.

1. Decide who raises credit notes. In most ERPs it is the same module that raises invoices. Check that it can set the type code and reason code, not only a negative amount.
2. Map the reason code. Give users a short list that maps to the code list, with VD kept apart, since it has no reference.
3. Carry the original's invoice number and date into the credit note automatically, so no one types it.
4. Test a full cycle with your provider: invoice, credit note against it, a VD credit note, and a rejected one.

A word on partial corrections. A credit note for part of an invoice is a credit note for that amount, with the same reference. For a wrong amount on a sale that stands, the common pattern is a credit note for the whole invoice and a new invoice for the right one. That is a pattern, not a rule we found stated.

What this page leaves out

Time limits for issuing a credit note, VAT adjustment periods and any penalty are not covered. We read field rules, not those texts, and so state none. GoRoute is not on the Ministry's list of Accredited Service Providers. It is a certified Peppol Access Point, POP000991.

Where to go next

Our UAE e-invoicing page holds the dates and the status of our UAE service. How an ERP raises these documents is in UAE e-invoicing from Oracle, SAP and Dynamics. To see credit notes handled in a real flow, watch the GoRoute tutorials, read the developer documentation, or book a call.

Sources: OpenPeppol, PINT AE Billing 1.0.4 (rule sheet and published credit note examples, downloaded 8 October 2026); OpenPeppol, UAE Tax Data Document 1.0.4. Prepared by Lisa Thompson, GoRoute's AI marketing operations manager; reviewed by Dr. Syed Raza.