PINT AE Validation Rules: Why UAE E-Invoices Get Rejected and How to Fix Them
The UAE-specific rules that reject most e-invoices, the data problem behind each, and whether to fix it in your ERP, your integration or with your provider.
By WDF Analysts
Every UAE e-invoice is checked against two published rule sets before it is accepted: the shared Peppol PINT rules and the UAE rules in PINT AE Billing 1.0.4. An invoice that breaks any rule is rejected. In practice almost every rejection traces back to one of nine data problems - tax numbers, tax categories, AED amounts, goods and service codes, transaction flags, credit notes, payment terms, addresses and totals - and most are fixed once, in master data, rather than invoice by invoice.
This is the companion to our guide to the PINT AE format and mandatory fields. That one explains what an invoice must contain; this one explains why invoices fail and where to fix them.
How validation works in the UAE model
Under the Ministry of Finance guidelines, your system sends invoice data to your Accredited Service Provider, which validates it and converts it to PINT AE XML. The buyer’s provider validates it again when it arrives. If that second check fails, the buyer’s provider confirms the failure to your provider and to the FTA, and no tax data is reported for the invoice. The rejection then comes back to you through your provider.
Two rule sets are published with the specification: shared PINT rules, numbered IBR-, that apply to every Peppol International invoice, and UAE rules, numbered IBR-…-AE and ALIGNED-IBRP-, for invoices issued in the UAE. The UAE set is where most new failures come from, because it checks data that most ERPs did not need before.
The rules that reject most UAE e-invoices
Grouped by the data problem behind them. The rule IDs are exact; the wording is summarised, so check the rule page for exceptions before you build.
| Area | What the rule requires | Usual cause | Where to fix it |
|---|---|---|---|
Tax numbersIBR-132-AE, IBR-148-AE | A VAT identifier must be a TRN: 15 digits, starting with 1 and ending with 03. The seller’s TIN must be 10 digits starting with 1. | TRNs typed into free-text fields, with spaces or missing digits; the 15-digit TRN used where the 10-digit TIN belongs. | Customer and company master data, with a format check on entry. |
Tax categories and ratesIBR-145-AE, IBR-190-AE, ALIGNED-IBRP-S-05, -Z-05, -E-05, -O-05, IBR-167-AE | Every line needs a VAT category code. Standard-rated lines must use 5.00; zero-rated lines 0; exempt and out-of-scope lines no rate. Exempt lines need an exemption reason code. | Tax codes in the ERP that do not map one-to-one to PINT AE categories; exempt items with no reason. | Tax code mapping table, plus item master data. |
Amounts in dirhamsIBR-104-AE, IBR-159-AE, IBR-175-AE, IBR-140-AE | Lines with VAT information need the VAT and line amounts in AED. Invoices in another currency need an exchange rate and the total VAT and total with VAT in AED. The tax accounting currency, when given, must be AED. | Foreign-currency invoices that only carry totals in the invoice currency; rounding done differently from the ledger. | Mapping layer: calculate AED amounts per line with the posted rate. |
Goods and service codesIBR-184-AE, IBR-185-AE, IBR-188-AE, IBR-189-AE, IBR-187-AE | Goods need an item classification code with scheme HS. Services need a service accounting code with scheme SAC. | Item masters with no HS code, and service items with no code at all. | Item master data: classify every item once. |
Transaction type codeIBR-154-AE, IBR-007-AE, IBR-138-AE, IBR-137-AE | The eight-flag code must be a string of 0s and 1s in the published order. A free trade zone flag needs a beneficiary ID; a summary invoice needs an invoicing period; disclosed agent billing needs the principal’s ID. | The ERP has no concept of these flags, so they are hard-coded to 00000000. | Rules in the mapping layer, fed by customer, contract and delivery data. |
Credit notesIBR-158-AE, IBR-055-AE | A credit note must carry a credit note reason code and, except for reason VD, a reference to the original invoice. | Credit notes raised without linking to the invoice they correct. | Credit note workflow in the ERP. |
Payment termsIBR-127-AE, IBR-191-AE, IBR-192-AE | A payment due date when an amount is due, a payment means code, and a payment account identifier for credit transfers. Credit notes and deemed supplies are exempt from the first two. | Payment terms held as text, and bank details only in a PDF template. | Payment terms and company bank master data. |
AddressesIBR-143-AE, IBR-144-AE, IBR-128-AE | Seller and buyer addresses need line 1, city and country subdivision. For UAE addresses the subdivision must be one of AUH, DXB, SHJ, UAQ, FUJ, AJM or RAK. | Emirates stored as free text ("Dubai", "Dubayy", "DXB"). | Address master data, mapped to the seven codes. |
TotalsIBR-CO-10, IBR-CO-13 to IBR-CO-16, IBR-091, IBR-123 to IBR-125 | Line net amounts must add up to the document totals, tax must equal the tax breakdown, and document totals may have at most two decimals. | Line-level rounding that differs from document-level rounding. | Mapping layer: one rounding rule, applied the same way the ledger does. |
HS codes for goods, SAC codes for services
This is the requirement most businesses discover late. Each line carries an item type. If it is goods, the line needs an item classification identifier with scheme HS, the Harmonized System code used in customs. If it is services, it needs a service accounting code with scheme SAC. Lines that mix both need both. Classify each item in your item master once, and the rule is satisfied on every invoice after that.
Tax numbers: TRN versus TIN
The TRN is your 15-digit tax registration number; the TIN is its first 10 digits and is your address on the network, with scheme 0235. Rule IBR-132-AE checks that every TRN on the invoice is 15 digits, starts with 1 and ends with 03. Rule IBR-148-AE checks the seller’s TIN is 10 digits starting with 1. A Tax Group member uses its own TIN, not the group representative’s, according to the Ministry’s mandatory fields document.
Foreign-currency invoices
An invoice in US dollars or euros is allowed, but the tax side is in dirhams. You need the exchange rate (IBR-159-AE), the VAT and line amounts in AED on each line (IBR-104-AE), and the total VAT and total with VAT in AED (IBR-175-AE). Calculate them from the same rate your ledger posts, or your VAT return and your e-invoices will disagree.
Where each fix belongs
A rejection tells you which rule failed, not where the fix belongs. Fixing it in the wrong place is how the same error comes back every week.
| Layer | What gets fixed there | Who does it |
|---|---|---|
| Source data (your ERP and master data) | TRNs and TINs, emirate codes, HS and SAC codes, tax codes on items, payment terms, bank details | Finance and operations, once per record |
| Mapping layer (connector or integration) | Transaction type flags, AED conversions, rounding, tax category mapping, credit note references | Whoever builds or configures the integration |
| Your ASP | XML conversion, UUID, transmission, tax data reporting, participant ID lookup | The provider, under your contract |
Rule of thumb: if the correct value exists somewhere in your business but not on the record, fix the source data. If the value is derived (a flag, an AED amount, a rounding), fix the mapping. Your provider can only fix its own steps.
Validate before the invoice leaves your system
The rules are published with the specification, so they can run inside your own process before an invoice reaches your provider. Doing that gives you three things a provider’s rejection cannot:
- Errors at the moment of entry, when the person raising the invoice still has the information to fix it.
- No round trip through two providers and back before you learn something was wrong.
- Time. Under Ministerial Decision No. 197 of 2026, an e-invoice must be issued and transmitted within 14 business days of the transaction. Every rejection uses some of that window.
A rejection process that holds up after go-live
- Route rejections back to the issuing system, attached to the invoice, not to a provider portal.
- Name an owner per error type: master data errors to finance operations, mapping errors to IT or your integrator.
- Fix the cause, then reissue. Correct the customer or item record first so the next invoice passes too.
- Watch the rate weekly. Rejections per hundred invoices, by rule. It should fall every week after go-live.
Common mistakes
- Hard-coding the transaction type code to 00000000. It passes the format check and is wrong for every free zone, export or summary invoice.
- Mapping ERP tax codes by name. "VAT 0%" can mean zero-rated, exempt or out of scope, and each is a different category.
- Testing only tax invoices. Credit notes have their own rules and fail differently.
- Fixing rejected invoices by hand in a portal. The record that caused it stays wrong.
- Building against an old version. OpenPeppol publishes PINT AE in numbered versions; confirm which one your provider validates against.
Where we fit
Pre-submission validation and rejection handling are the core of our UAE e-invoicing integration work. We are not an ASP: we make sure the system your provider connects to sends invoices that pass. If your go-live is 1 January 2027, our go-live plan shows where validation fits in the remaining weeks.
Validation questions
What is a SAC code in UAE e-invoicing?
SAC stands for service accounting code. Under PINT AE rule IBR-185-AE, every invoice line for a service must carry a service accounting code, and rule IBR-189-AE requires its scheme identifier to be SAC. Goods carry an HS classification code instead (IBR-184-AE and IBR-188-AE).
Why was our UAE e-invoice rejected for the TRN?
Rule IBR-132-AE requires a VAT identifier to be a TRN of exactly 15 digits that starts with 1 and ends with 03. Spaces, dashes, missing digits or a TIN in the TRN field all fail it. The seller’s TIN, used for the electronic address, must be 10 digits starting with 1 under IBR-148-AE.
Why was our credit note rejected?
The two most common causes are a missing credit note reason code (IBR-158-AE) and a missing reference to the original invoice, which IBR-055-AE requires for every reason except VD. Both have to come from the credit note workflow in your ERP.
Which emirate codes does PINT AE accept?
For a UAE address, rule IBR-128-AE accepts only AUH, DXB, SHJ, UAQ, FUJ, AJM and RAK as the country subdivision.
Who validates a UAE e-invoice?
Both service providers. The supplier’s Accredited Service Provider validates the data and converts it into PINT AE XML; the buyer’s provider validates it again on receipt. If the buyer’s provider rejects it, it confirms the failure to the supplier’s provider and the FTA, and no tax data is reported for that invoice.
Rule IDs and requirements were checked against OpenPeppol’s PINT AE Billing 1.0.4 documentation and Ministry of Finance publications on 6 November 2026. Rules change between versions; check the version your provider validates against.
Official sources: PINT AE UAE-aligned rules · PINT AE shared business rules · OpenPeppol - PINT AE specifications · UAE Electronic Invoicing Guidelines
Related articles
How WDF does this in practice
This is work we do for clients every week. Here is what that looks like as a service:
