Invoice rules
The customer setup on the previous page is done once. These are the rules that apply to every invoice you raise, so they never stop mattering. Each one is checked before the invoice is converted, and a failure comes back as a status on the invoice rather than as an error in your ERP — so it is worth knowing them in advance.
The invoice number must be unique
The number you raised in your ERP is the number that is filed — it is never rewritten. That makes duplicates your ledger's problem first: the same number, on the same date, to the same buyer is treated as already sent and will not go out a second time.
That behaviour is deliberate. A retry, a webhook that fires twice and a genuine re-issue look identical from outside, and filing the same invoice number twice with the authority is worse than filing it once. If you need to correct an invoice that has already gone, raise a credit note against it rather than re-sending the original number.
Every tax rate in your ERP needs a UAE treatment
Your system has its own tax rates — “VAT 5%”, “Zero Rated”, “Exempt”, whatever they are called in your chart. The FTA does not read those names; it reads a category. Mapping one to the other is done once per entity, on the VAT treatment page in the dashboard.
A rate with no treatment mapped is a gap, and the dashboard flags the profile as incomplete rather than guessing a category — guessing here would mean filing 5% output tax as exempt, or the reverse. Reverse charge, zero-rated and exempt all carry different obligations, so the mapping has to be a decision, not a default.
A non-AED invoice is converted at the Central Bank rate
An invoice in USD, EUR or any currency other than the dirham must also report its VAT in AED. The platform does that conversion, at the rate the UAE Central Bank published for the invoice's own date — walking back to the last published business day when the invoice falls on a weekend or a holiday.
By default the rate on the invoice in your accounting system is not used, and you do not need to fill it in for us. That field means different things in different systems: it can be quoted the other way round, be against a base currency that is not the dirham, or simply be stale — and the AED figures it produces are what the FTA assesses the VAT on.
An entity that must file at its own rate can say so, and then nominate the field to read or supply the rate per invoice. That is one switch on the entity and one row on PINT Mapping — Exchange rate covers both, and which one you want.
An invoice is only refused on this when the Central Bank published no rate at all for that currency on or before its date — a currency they do not list, or a date far enough in the future that nothing has been published yet. Nothing is ever filed at a rate nobody published.
An AED invoice needs none of this. It is already in the currency the FTA assesses in, so no rate and no second set of figures is added.
The buyer has to be addressable
Every invoice carries an electronic address for the buyer, even when the buyer is not on the network. A UAE buyer is addressed by its TRN; a foreign buyer by its own national tax number or by a Peppol identifier it already has.
When a buyer genuinely has none of those, the invoice is still filed — a placeholder address is used, and which placeholder depends on the kind of supply. That is a fallback for a buyer who cannot be reached, not a way to skip filling in a customer record: a UAE buyer without a TRN is a data error, and is reported as one.
The full decision tree, including the export and deemed-supply placeholders, is on Export invoice details. It is written for the API but the addressing is identical here.
Credit notes need a reason and an original
A credit note carries a reason code from the FTA's list, and a reference to the invoice it corrects. Both come out of your ERP, so raise the credit note against the original document rather than as a standalone negative invoice — a standalone one has nothing to reference.
Reverse-charge lines carry more than a tax code
A reverse-charge supply moves the VAT obligation to the buyer, so the FTA asks for more detail: the buyer's tax number is mandatory, and each line needs the type of goods or services from the published code list. A line simply tagged “RCM” with nothing else is not enough.
If an invoice is rejected
The rejection is recorded on the invoice with the rule it failed, in the same words the validator uses. Fix the cause in your ERP — the customer record, the tax mapping, the missing rate — and send it again; nothing needs to be recreated here.
A rejection means the invoice was not filed. It is not a warning, and it does not resolve itself on the next sync.