On this page
Most businesses do not find out their invoicing process has a PINT-AE gap until an invoice gets rejected, and by then the cost is no longer theoretical: an invoice that fails transmission to an accredited Access Service Provider has not been legally issued, which means payment terms cannot be enforced against it and the VAT position for that period may be incomplete. This checklist is the audit you want to run before that happens, not after. It walks through the specific fields, codes, and structural rules PINT-AE actually enforces, so you can find your gaps on your own schedule instead of finding them at the ASP's rejection queue.
What "PINT-AE Compliant" Actually Means
PINT-AE is the UAE's adaptation of the Peppol International Invoice specification. Being compliant means three things are simultaneously true for every invoice you issue: the data is structured as UBL 2.1 XML, every mandatory field required by PINT-AE is present and correctly mapped, and the document is transmitted only through an accredited ASP. Missing any one of the three produces a rejection, and rejections cluster around predictable, checkable points. The rest of this post is that checklist.
Two structural facts worth stating plainly before the checklist, because they trip up otherwise-careful audits: UAE PINT-AE defines exactly two document types, Invoice and Credit Note. There is no Debit Note document type in the UAE specification. If anything in your process assumes one exists, that assumption itself is the gap.
Part 1: Document-Level Fields
Go through your last ten issued invoices and confirm each one actually carries these, correctly populated, not just present as a blank or default value:
- Invoice number and issue date: present, unique, and in the correct date format.
- Invoice type code: set correctly for the document (never defaulted to a debit-note-style code that doesn't exist in this specification).
- Invoice currency code: matches what was actually agreed with the buyer.
- Seller details: name, Tax Registration Number, electronic address, and full address including country subdivision and country code.
- Buyer details: the same fields as above, plus buyer reference where applicable.
- Payment means type code and payment terms: if you're using credit-transfer payment, the payee financial account identifier must also be present; its absence is a common silent gap.
- VAT point date and the four total fields: amount without VAT, total VAT amount, amount with VAT, and amount due.
Part 2: Line-Level Fields
Mandatory-field problems hide more often at the line level than the document level, because line data comes from a different part of most systems (inventory/items) than header data does (customer records):
- Every line has an identifier, item name, and quantity with the correct unit-of-measure code.
- Net price and line net amount reconcile with the quantity and unit price you'd expect.
- Every line carries its own VAT category code and VAT rate, not just a document-level default copied down.
Part 3: VAT Category Coding
The UAE applies VAT at 5%, but PINT-AE requires a specific category code at the line level: S (standard-rated), Z (zero-rated), E (exempt), or O (out of scope). Audit this specifically:
- Does every line's VAT category code match its actual tax treatment, or is one code applied uniformly regardless of item type?
- Are zero-rated and exempt supplies distinguished from each other, or treated as interchangeable?
- Is there a step in your process where someone manually assigns this code, and if so, is it documented anywhere other than that person's memory?
Part 4: Document Type and Credit Note Handling
Credit notes carry their own mandatory field that invoices don't: a preceding invoice reference, linking back to the original invoice being credited. This is only required for credit notes, not for every document. When it's missing on a credit note, it's rejected outright.
- Confirm your credit note process actually populates this reference, not just the credit amount.
- Confirm no part of your system or your team's mental model still assumes a "debit note" workflow exists in UAE e-invoicing. It doesn't, and building a process around it guarantees a rejection the first time it's used.
Part 5: Currency and Rounding Edge Cases
These only apply conditionally, which is exactly why they're easy to miss in an audit that only checks "always required" fields:
- If any invoice is issued in a currency other than AED, is the exchange rate field populated? It's mandatory in that case and silently skipped otherwise.
- If rounding is applied to your totals, is the rounding amount field populated to account for it?
- If a prepayment exists against an invoice, is the paid-amount field populated to reflect it?
Part 6: Structural Validation
Even a document with every mandatory field present can still fail if the XML itself is malformed:
- Does your export or integration validate against the actual UBL 2.1 schema, or only against your own internal idea of what the fields should look like?
- Is element ordering, namespace declaration, and field cardinality checked before transmission, or only discovered when the ASP rejects it?
Part 7: Transmission and Audit Trail
The last two items are process questions, not field questions, and they're often the most revealing:
- Is every invoice transmitted only through an accredited ASP, with no fallback path that bypasses this?
- Do you have a per-invoice audit trail showing status (validated, transmitted, cleared, rejected) for each individual document, or only a batch-level log that tells you something in the batch failed without saying which invoice or why?
Scoring Your Audit
If you answered "no" or "not sure" to three or more items above, your invoicing process carries meaningful, predictable rejection risk. It's not hypothetical: these are the same failure patterns that show up across UAE businesses regardless of which accounting system they run. The fields and rules above are not edge cases; they are the specific things PINT-AE validation actually checks.
Closing the Gaps You Find
None of the gaps above require replacing your accounting system or rebuilding how your finance team works. They require a layer that sits between your existing system and your ASP: one that accepts your invoice data in whatever format you already export it in (API, CSV, XLSX, or JSON), normalizes it into a single validated schema independent of which system produced it, checks it against the full PINT-AE rule set before transmission, and only then hands it to your accredited ASP. When something fails, it should surface the actual field or rule that failed, not a generic rejection code you have to trace back manually.
That is the specific problem Kodowo is built to solve. It doesn't replace your ERP and it isn't itself an ASP. It's the validation and mapping layer between the two, with a full audit trail of every invoice's status from receipt through clearance. If you want to map your own audit findings against how that lifecycle actually works, the finance and tax solutions page covers it in more detail.
Frequently Asked Questions
How often should I re-run this audit? At minimum, whenever your invoicing volume, product mix, or accounting system changes, and again before each new compliance-phase deadline applies to your business tier. PINT-AE itself is a living specification, so a process that passed this audit a year ago is not guaranteed to still pass it today.
Does passing this checklist guarantee my invoices won't be rejected? It substantially reduces predictable rejection risk by catching the failure patterns PINT-AE actually enforces, but it is a self-audit, not a substitute for real pre-transmission schema validation. The only way to be certain a specific invoice will pass is to validate that exact document against the full rule set before it's sent.
What's the difference between a mandatory field and a conditional field in this checklist? A mandatory field must be present on every invoice regardless of circumstances (invoice number, issue date, totals). A conditional field is only required when a specific circumstance applies (a non-AED currency, a credit note, a prepayment) and is correctly absent otherwise. Audits that don't distinguish the two either flag false positives or miss real gaps.
My audit found gaps, but I'm not ready to change my process yet. What's the actual risk of waiting? Every invoice issued while the gap exists carries the same rejection risk, and under UAE e-invoicing rules a rejected invoice is not legally issued. It affects payment enforceability and your VAT position for that period, not just paperwork. The risk doesn't accumulate gradually; each individual invoice either clears or doesn't.
Frequently asked questions
- How often should I re-run this audit?
- At minimum, whenever your invoicing volume, product mix, or accounting system changes, and again before each new compliance-phase deadline applies to your business tier. PINT-AE itself is a living specification, so a process that passed this audit a year ago is not guaranteed to still pass it today.
- Does passing this checklist guarantee my invoices won't be rejected?
- It substantially reduces predictable rejection risk by catching the failure patterns PINT-AE actually enforces, but it is a self-audit, not a substitute for real pre-transmission schema validation. The only way to be certain a specific invoice will pass is to validate that exact document against the full rule set before it's sent.
- What's the difference between a mandatory field and a conditional field in this checklist?
- A mandatory field must be present on every invoice regardless of circumstances (invoice number, issue date, totals). A conditional field is only required when a specific circumstance applies -- a non-AED currency, a credit note, a prepayment -- and is correctly absent otherwise. Audits that don't distinguish the two either flag false positives or miss real gaps.
- My audit found gaps, but I'm not ready to change my process yet. What's the actual risk of waiting?
- Every invoice issued while the gap exists carries the same rejection risk, and under UAE e-invoicing rules a rejected invoice is not legally issued -- it affects payment enforceability and your VAT position for that period, not just paperwork. The risk doesn't accumulate gradually; each individual invoice either clears or doesn't.