Key Takeaways
4 insights · 11 min readUAE e-invoices are UBL 2.1 XML under the PINT AE specification — invoices use the Invoice root, credit notes the CreditNote root.
Type codes matter: 380 for an invoice, 381 for a credit note. Swapping them gets the document rejected.
A credit note must reference the original invoice (BillingReference) and use positive amounts — never negative.
VAT sits in TaxTotal / TaxSubtotal per category (S, Z, E, O); the TRN sits in PartyTaxScheme. Your ASP validates before it sends.
A UAE e-invoice is a UBL 2.1 XML document under the PINT AE specification. An invoice uses the Invoice root with type code 380; a credit note uses the CreditNote root with code 381, must reference the original invoice, and carries positive amounts. VAT is broken down per tax category in TaxSubtotal, and each party's TRN sits in PartyTaxScheme with tax scheme VAT.
In this guide
What format is a UAE e-invoice? The core building blocks A worked invoice XML Structuring the VAT breakdown A worked credit note XML Invoice vs credit note The fields people get wrong Common XML mistakes How validation works Getting it rightThe single biggest mental shift in UAE e-invoicing is that an invoice is no longer a document you look at — it is structured data a machine reads. Under the PINT AE specification, invoices and credit notes are exchanged as UBL 2.1 XML across the Peppol network and validated automatically. Get the structure right and it passes silently; get one field wrong and the whole document bounces. This guide walks the anatomy of both an invoice and a credit note, with worked XML you can hold up against your own output.
Read this before you copy any XML
The examples below illustrate the UBL 2.1 / PINT AE structure. Always validate against the official Ministry of Finance PINT AE specification and Data Dictionary and your ASP's validator before use — the exact CustomizationID URN and the current business rules are defined there. [VERIFY the CustomizationID and business rules against the official PINT AE spec.]
What format is a UAE e-invoice?
A UAE e-invoice is a structured UBL 2.1 XML file built to the PINT AE specification — the UAE specialisation of the Peppol International (PINT) billing model. It is not a PDF, an image or an email attachment; it is data that both the buyer's system and, through the 5-corner model, the FTA can read directly.
Two document types share almost the same anatomy but are technically distinct: the invoice (root element Invoice) and the credit note (root element CreditNote). Everything else — parties, tax, totals, lines — follows the same UBL grammar, which is why once you can read one, you can read both. The rest of this guide uses that grammar.
What are the core building blocks of a PINT AE e-invoice?
Every PINT AE document is assembled from a fixed set of UBL elements. Learn these and the XML stops looking like noise:
| Element | Purpose |
|---|---|
cbc:CustomizationID | Identifies the PINT AE specification the document conforms to |
cbc:ProfileID | The Peppol business process (billing) |
cbc:ID | The invoice or credit note number |
cbc:IssueDate | Issue date, ISO format YYYY-MM-DD |
cbc:InvoiceTypeCode / cbc:CreditNoteTypeCode | 380 invoice / 381 credit note |
cbc:DocumentCurrencyCode | AED |
cac:AccountingSupplierParty / ...CustomerParty | Seller and buyer, including TRN |
cac:TaxTotal / cac:TaxSubtotal | Total VAT and the breakdown per tax category |
cac:LegalMonetaryTotal | Net, tax-exclusive, tax-inclusive and payable amounts |
cac:InvoiceLine / cac:CreditNoteLine | The individual line items |
A worked invoice XML example
Here is a minimal but valid-shaped invoice for AED 1,000 of consulting plus 5% VAT. Note the InvoiceTypeCode of 380, the TRN inside each party's PartyTaxScheme, and the currencyID="AED" attribute on every monetary amount:
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:CustomizationID>urn:peppol:pint:billing-1@ae-1</cbc:CustomizationID> <!-- PINT AE spec ID: VERIFY exact URN -->
<cbc:ProfileID>urn:peppol:bis:billing</cbc:ProfileID>
<cbc:ID>INV-2026-000123</cbc:ID>
<cbc:IssueDate>2026-07-11</cbc:IssueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>AED</cbc:DocumentCurrencyCode>
<cac:AccountingSupplierParty>
<cac:Party>
<cac:PartyName><cbc:Name>Seller LLC</cbc:Name></cac:PartyName>
<cac:PostalAddress>
<cbc:CityName>Dubai</cbc:CityName>
<cac:Country><cbc:IdentificationCode>AE</cbc:IdentificationCode></cac:Country>
</cac:PostalAddress>
<cac:PartyTaxScheme>
<cbc:CompanyID>100XXXXXXXXXXXX</cbc:CompanyID> <!-- Seller TRN -->
<cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:PartyTaxScheme>
</cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
<cac:Party>
<cac:PartyName><cbc:Name>Buyer LLC</cbc:Name></cac:PartyName>
<cac:PartyTaxScheme>
<cbc:CompanyID>100YYYYYYYYYYYY</cbc:CompanyID> <!-- Buyer TRN -->
<cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:PartyTaxScheme>
</cac:Party>
</cac:AccountingCustomerParty>
<cac:TaxTotal>
<cbc:TaxAmount currencyID="AED">50.00</cbc:TaxAmount>
<cac:TaxSubtotal>
<cbc:TaxableAmount currencyID="AED">1000.00</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="AED">50.00</cbc:TaxAmount>
<cac:TaxCategory>
<cbc:ID>S</cbc:ID> <!-- S = standard rated -->
<cbc:Percent>5</cbc:Percent>
<cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
</cac:TaxTotal>
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount currencyID="AED">1000.00</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="AED">1000.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="AED">1050.00</cbc:TaxInclusiveAmount>
<cbc:PayableAmount currencyID="AED">1050.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="HUR">10</cbc:InvoicedQuantity> <!-- unit code from UN/ECE Rec 20 -->
<cbc:LineExtensionAmount currencyID="AED">1000.00</cbc:LineExtensionAmount>
<cac:Item>
<cbc:Name>Consulting hours</cbc:Name>
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID><cbc:Percent>5</cbc:Percent>
<cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:ClassifiedTaxCategory>
</cac:Item>
<cac:Price><cbc:PriceAmount currencyID="AED">100.00</cbc:PriceAmount></cac:Price>
</cac:InvoiceLine>
</Invoice>Every monetary amount carries the currencyID attribute; every date is ISO-formatted; and the line-level tax category (ClassifiedTaxCategory) matches the document-level TaxSubtotal. Those three habits alone prevent the majority of validation failures.
Your ASP rejecting invoices on validation?
We map your data to the PINT AE Data Dictionary and fix the XML so documents pass first time.
How do you structure the VAT breakdown?
VAT lives in cac:TaxTotal, with one cac:TaxSubtotal per rate. Each subtotal states the taxable amount, the tax amount and a tax category code. The category codes you will actually use are:
| Code | Meaning | Percent |
|---|---|---|
| S | Standard rated | 5 |
| Z | Zero rated | 0 |
| E | Exempt | — |
| O | Outside scope / not subject to VAT | — |
| AE | VAT reverse charge (where it applies) | 0 |
The golden rule is reconciliation: the sum of your line-level categories must equal your document-level TaxSubtotal figures, and the total VAT must equal the sum of the subtotals. If a single line is tagged Z when it should be S, the totals will not add up and the document fails. This is also where VAT accuracy and e-invoicing meet — the categories here are the same ones that drive your VAT return.
A worked credit note XML example
A credit note looks similar, but three things change and all three are mandatory: the root element becomes CreditNote, the type code becomes 381, and a BillingReference points back to the original invoice. Amounts stay positive:
<CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:CustomizationID>urn:peppol:pint:billing-1@ae-1</cbc:CustomizationID> <!-- VERIFY exact URN -->
<cbc:ProfileID>urn:peppol:bis:billing</cbc:ProfileID>
<cbc:ID>CN-2026-000045</cbc:ID>
<cbc:IssueDate>2026-07-11</cbc:IssueDate>
<cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode> <!-- 381 = credit note -->
<cbc:DocumentCurrencyCode>AED</cbc:DocumentCurrencyCode>
<cac:BillingReference>
<cac:InvoiceDocumentReference>
<cbc:ID>INV-2026-000123</cbc:ID> <!-- MUST reference the original invoice -->
<cbc:IssueDate>2026-07-01</cbc:IssueDate>
</cac:InvoiceDocumentReference>
</cac:BillingReference>
<cac:AccountingSupplierParty> ... </cac:AccountingSupplierParty>
<cac:AccountingCustomerParty> ... </cac:AccountingCustomerParty>
<cac:TaxTotal>
<cbc:TaxAmount currencyID="AED">10.00</cbc:TaxAmount>
<cac:TaxSubtotal>
<cbc:TaxableAmount currencyID="AED">200.00</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="AED">10.00</cbc:TaxAmount>
<cac:TaxCategory><cbc:ID>S</cbc:ID><cbc:Percent>5</cbc:Percent>
<cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:TaxCategory>
</cac:TaxSubtotal>
</cac:TaxTotal>
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount currencyID="AED">200.00</cbc:LineExtensionAmount> <!-- positive, not negative -->
<cbc:TaxExclusiveAmount currencyID="AED">200.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="AED">210.00</cbc:TaxInclusiveAmount>
<cbc:PayableAmount currencyID="AED">210.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
<cac:CreditNoteLine>
<cbc:ID>1</cbc:ID>
<cbc:CreditedQuantity unitCode="HUR">2</cbc:CreditedQuantity> <!-- CreditedQuantity, not InvoicedQuantity -->
<cbc:LineExtensionAmount currencyID="AED">200.00</cbc:LineExtensionAmount>
<cac:Item>
<cbc:Name>Consulting hours</cbc:Name>
<cac:ClassifiedTaxCategory><cbc:ID>S</cbc:ID><cbc:Percent>5</cbc:Percent>
<cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:ClassifiedTaxCategory>
</cac:Item>
<cac:Price><cbc:PriceAmount currencyID="AED">100.00</cbc:PriceAmount></cac:Price>
</cac:CreditNoteLine>
</CreditNote>Notice the line element is cac:CreditNoteLine with cbc:CreditedQuantity — not InvoiceLine / InvoicedQuantity. The amounts describe the value being credited, expressed positively; the document type is what tells the buyer's system and the FTA that this reduces the amount owed.
Invoice vs credit note: the differences that matter
Most credit-note rejections come from treating a credit note like an invoice. Hold the two side by side:
Invoice
- Root element
Invoice. - Type code 380.
- No billing reference required.
- Lines:
InvoiceLinewithInvoicedQuantity.
Credit note
- Root element
CreditNote. - Type code 381.
- Must reference the original invoice via
BillingReference. - Lines:
CreditNoteLinewithCreditedQuantity; amounts positive.
The fields people get wrong
A handful of small fields cause most validation failures. Check these every time:
| Field | Requirement | Common error |
|---|---|---|
| TRN | PartyTaxScheme/CompanyID, scheme VAT | Missing, or wrong scheme ID |
| Currency | DocumentCurrencyCode = AED; currencyID on amounts | currencyID attribute omitted |
| Dates | ISO YYYY-MM-DD | Local date formats |
| Unit codes | UN/ECE Rec 20 codes (e.g. HUR, EA) | Free-text units |
| Type code | 380 invoice / 381 credit note | Swapped or wrong |
Common XML mistakes that get e-invoices rejected
Pulling it together, these are the recurring errors an ASP validator will bounce:
The rejection shortlist
• Using the Invoice root for a credit note — it must be CreditNote.
• Wrong document type code — 380 and 381 swapped.
• Negative amounts on a credit note — UBL credit notes are positive.
• No BillingReference — a credit note with no link to its original invoice.
• Tax that does not reconcile — line categories that do not sum to the TaxSubtotal.
• Wrong CustomizationID / ProfileID — the document is rejected before content is even checked.
How does validation actually work?
You do not hand-write these documents in production. Your accounting system or middleware generates the UBL XML, and your Accredited Service Provider validates it against the PINT AE schema and business rules before transmitting it over Peppol. Failures come back as specific rule errors — for example a business-rule code flagging a missing reference or a tax mismatch.
- Map your data to the PINT AE Data Dictionary fields.
- Generate UBL 2.1 XML from your accounting system, such as your bookkeeping platform.
- Set the right root and type code (Invoice/380 or CreditNote/381).
- Validate against the PINT AE rules and your ASP's validator.
- Resolve business-rule errors before transmission.
- Transmit through your Accredited Service Provider.
Expert Tip
Keep one known-good invoice and one known-good credit note as reference files once they pass validation. When a new document fails, diffing it against the reference finds the offending field in seconds — far faster than re-reading the whole schema.
How to get your PINT AE documents right
Understanding the structure is what turns an opaque validation error into a five-minute fix. But you should not have to become a UBL expert to be compliant — the work is in the setup: mapping your master data, configuring your system to emit the correct codes, and testing against the live rules before your go-live date.
Fastlane's team gets your e-invoicing output right at the source: we map your data to the PINT AE Data Dictionary, configure your accounting system, run test documents through validation, and keep the tax categories aligned with your VAT filing and corporate tax records. Start with our e-invoicing service to build your readiness plan.
Fastlane Tax Team
FTA-registered tax agents with 4,000+ corporate tax and VAT filings across the UAE mainland and 40+ free zones. Every guide is reviewed against current FTA regulations before publishing.
Ask the team a question