Your provider rejected a document and handed you an identifier. Here is what each one means, when it fires, and where the cause actually lives in your data.
These are the codes companies meet in practice. Open any one for the cause and the fix. The complete set of 95 UAE-specific rules is in the rule lookup, searchable in plain words.
one fix clears every single invoice you issue.
What actually went wrong. Exchange rate has too many decimal places
The exchange rate carries more than six decimal places. The pattern allows a whole number or up to six decimals, so 1, 1.0 and 1.123456 all pass and 1.1234567 does not.
The fix. Up to six decimal places. A whole number is valid; seven or more decimals is not.
What actually went wrong. Seller passport issuing country is not a valid ISO code
The fix. Only applies where your own company is identified by passport. Two-letter ISO 3166-1 code, and this is your own record, so one fix clears every invoice.
What actually went wrong. Seller TIN is not in the required format
The fix. This is your own company record, not a counterparty record, and it is not the 15-digit VAT TRN. Where a non-VAT tax registration identifier is used for the seller, it must be 10 digits in the form 1XXXXXXXXX.
one fix clears a whole class of documents.
What actually went wrong. Billing frequency code is not from the permitted list
The billing frequency value must come from the published list: DLY, WKY, Q15, MTH, Q45, Q60, QTR, YRL, HYR, OTH. This rule checks the value when one is present. It does not make frequency mandatory for continuous supply — we checked, and no rule does.
The fix. The permitted values are DLY, WKY, Q15, MTH, Q45, Q60, QTR, YRL, HYR, OTH. Note this rule only checks the value when one is present; it does not make frequency mandatory.
What actually went wrong. Free zone flag set without a beneficiary identifier
You have set the free zone flag, which makes a beneficiary identifier mandatory. Either supply it, or check whether the flag should be set at all — being registered in a free zone does not automatically mean every invoice carries the flag.
The fix. Either supply the identifier, or check whether the flag should be set at all. Being registered in a free zone does not by itself mean every invoice carries it.
What actually went wrong. Summary invoice without an invoicing period
The summary flag is set but no invoicing period is stated. A summary invoice must say what period it covers.
The fix. A summary invoice must state the period it covers.
What actually went wrong. Export without a full delivery address
An export needs a full delivery address including the country subdivision, and the delivery country must not be AE.
The fix. Country subdivision is required, and the delivery country must not be AE.
What actually went wrong. Transaction type code is malformed
The transaction type code is absent, the wrong length, or contains something other than 0 and 1. The rule tests the field against an eight-character pattern, and an absent field fails that test, so this field is mandatory on every document. Use 00000000 only when you have confirmed that none of the eight situations applies — not as a default.
The fix. Only the characters 0 and 1, and every official example uses exactly eight positions.
one fix clears every invoice that product appears on.
What actually went wrong. Item description missing
The fix. Blank descriptions in the catalogue. Usually a handful of legacy records nobody uses but nobody deleted.
What actually went wrong. Reverse charge line without nature of goods or services
A reverse charge line must state the nature of the goods or services. This is an extra field that only appears in this scenario.
The fix. An extra field that only appears in this scenario.
What actually went wrong. Goods lines carry no classification code
Your item is marked as goods, so a classification code is mandatory. This is the rule most companies meet first — and it only fires because your system populates the item type. Fix in the item master, not on the invoice: the code belongs to the product, not the transaction.
The fix. Add the HS code to the product record. Fixing one product clears every invoice that product appears on.
What actually went wrong. Service lines carry no service accounting code
Your item is marked as a service, so a service accounting code is mandatory. Note that many ERPs have a field for goods classification and none for services — check whether yours can even store this before planning the work.
The fix. Add the SAC code to the service record. Check first whether your system has a field for it — many do not, and that changes the fix.
What actually went wrong. Lines marked as both goods and services need both codes
The item is marked as both goods and services, which requires both codes. Often this is a data entry choice rather than reality — check whether the line should simply be split in two.
The fix. Either supply both codes, or split the line in two. Often the 'both' marking is a data entry habit rather than reality.
What actually went wrong. Classification code is present but not on the HS scheme
A classification code is present but the scheme is not HS. UNSPSC, CPV and internal category codes are not accepted here. If your catalogue is coded to another scheme, it needs mapping, not relabelling.
The fix. UNSPSC, CPV and internal categories are not accepted. Existing codes need mapping to HS, not relabelling.
one fix clears every document built from that template.
What actually went wrong. Payment due date missing where it is required
A payment due date is missing where the rule requires one. It is required whenever the amount due is above zero, unless the document is a credit note or carries the deemed-supply flag. In those cases the requirement falls away — it does not turn into a ban, and a due date present there is not an error.
The fix. Required whenever the amount due is above zero, unless the document is a credit note or carries the deemed-supply flag. In those cases the requirement falls away — it does not become a prohibition.
What actually went wrong. Payment means type code missing where it is required
The fix. Same shape as the due date: required by default, exempt for credit notes and deemed supplies. The exemption removes the obligation, not the permission.
one fix clears every invoice to that customer or supplier.
What actually went wrong. Buyer passport issuing country is not a valid ISO code
The fix. Only applies where the buyer is identified by passport. The country must be a two-letter ISO 3166-1 code on the counterparty record — not a country name.
What actually went wrong. Tax registration number is malformed
The tax registration number is not in the expected shape: fifteen digits, beginning with 1 and ending 03. Very often the value in the ledger is correct but carries spaces, dashes or a trailing note.
The fix. Fifteen digits, starting 1 and ending 03. Very often the ledger value is right but carries spaces, a dash or a trailing note.
The credit note reason code is not from the permitted list. The values are DL8.61.1.A through DL8.61.1.E, plus VD. Note that VD has a special meaning: it marks a credit note with no preceding invoice, and using it alongside a reference to one is itself a rejection (ibr-055-ae).
A credit note must either reference the invoice it corrects, or carry the reason code VD to say there is no such invoice. One or the other, never both and never neither.
A line in tax category N carries a zero rate. The rule requires a rate above zero on that line: the tax is calculated on the margin rather than the full amount, but the rate shown must still be the ordinary one. Replace the zero with the applicable rate.
A credit note of type 381 has no reason code. The reason code is required on its own. Whether a preceding invoice reference is also required depends on which reason you give: for an ordinary correction it is required by ibr-055-ae, and for VD it must be absent. Read the two rules together.
This rule is a placeholder in the published schematron — its body is test="true()", so it cannot fail in release 1.0.4. The message text reserves space for a minimum digit count, written as 'X'. We do not know what that number will be, or when it will be set. Worth watching in future releases; nothing to do about it today.
We classified all 95 UAE rules by the structure of their executable test rather than by their wording. The distribution is worth knowing: not one of them is a prohibition. Every rule either requires something to be present, constrains a value, fires only under a condition, or checks an arithmetic identity.
That matters because of what people do when they read an exception. A rule saying "required, except when the invoice type is X" is often read as "must not be there when the type is X", and the field gets deleted. It is a costly misreading: the exception lifted an obligation, it did not impose one, and the deletion breaks a different rule that did require the field. Nothing in this release tells you to remove anything.
Forty rejections usually reduce to three or four causes. A single counterparty missing a tax number fails on every invoice issued to it; one item with no classification code fails on every line it appears in. The count in the rejection report measures documents, not problems.
Fixing it document by document is the expensive mistake. Group the rejections by rule and by the record they come from, fix the record once, and the documents clear together. The order matters too: start with the record that appears in the most rejected documents, because that is the one whose correction is visible immediately.
A worked example does exactly this on invented data, or see what we would need from you to do it on yours.
All 95 executable rules, as published: PINT AE 1.0.4 jurisdiction-aligned rules, dated 2026-06-03 and checked 2026-07-28.