What a specification constrains, versus what you control today
| Aspect | Today | Under PINT AE |
|---|---|---|
| Layout and design | Yours | Irrelevant: this is data, not a document |
| Required fields | Broadly what the VAT rules require | Prescribed and machine-validated |
| Addresses | Usually one free-text block | Structured fields |
| Customer name | Trading name is fine | Legal name matching the trade licence |
| Tax applied | Often at invoice level | At line level, using defined category codes |
| Units of measure | Free text: “box”, “hrs” | Codes from a controlled list |
| Credit notes | Loosely reference another document | Structured reference to the invoice corrected |
| Validity | Judged by a person | Judged automatically, before delivery |
The two rows that generate real work are tax at line level and coded units of measure. Most SME accounting systems apply tax at invoice level and hold units as free text, and both have to change before anything can be transmitted at all.
Why that is the answer
A specification of this kind is not a template. It is a contract about meaning.
When your invoice says a line is taxed at 5 per cent, PINT AE defines precisely how that is expressed (which code, in which field, with which accompanying values) so that your customer’s system, their provider and the tax authority all interpret it identically without anyone reading it.
That is why conformance is binary rather than approximate. A person reading a PDF can work out what you meant from context. A validator cannot, and does not try. Either the invoice conforms or it does not.
The UAE profile sits on top of an international base specification rather than being invented from nothing. The underlying structure is documented and stable, and vendors with Peppol experience in other markets are not starting from scratch. What is UAE-specific is the local layer, the tax categories, identifiers and business rules reflecting UAE VAT rather than another jurisdiction’s.
What has to be right for an invoice to validate
The specification constrains several things at once, and failures cluster predictably:
- Presence: required fields must be there. A missing customer tax registration number, where one is required, is a hard failure
- Format: dates as dates, identifiers matching their expected pattern, amounts to the correct precision, currency from the standard list
- Consistency: values must agree with each other. Line totals summing to the invoice total, tax amounts matching the categories and rates applied
- Controlled codes: units of measure, tax categories, document types. Free text where a code is expected fails
- Business rules: conditional requirements, such as fields that become mandatory only when a particular tax treatment is used
- References: a credit note pointing at an invoice that actually exists
Consistency failures are the ones that surprise finance teams, because the invoice looks perfectly correct. A rounding difference of a few fils between line totals and the invoice total is invisible on a PDF and fatal to a validator.
Why your current invoices would probably not pass
Businesses reasonably assume that an invoice satisfying today’s VAT requirements will satisfy this one. The content largely overlaps; the structure does not.
A compliant tax invoice today needs the words “Tax Invoice”, your details and TRN, the customer’s details and TRN where registered, a sequential number, dates, a description, amounts, and the VAT payable in AED. Most businesses meet that.
PINT AE needs all of it as structured, coded, validated data. The gap is not in what you record but in how it is held: addresses as one free-text blob, trading names rather than legal names, tax registration numbers missing for a substantial share of customers because nothing previously forced their collection, units typed rather than coded, and tax applied at invoice level rather than per line.
Each is trivial in isolation. Collectively they are months of work, because most of it depends on going back to customers and waiting.
Whose problem the specification actually is
Realistically, not yours.
The specification is implemented by your accounting software and your accredited service provider. You will not write XML, map fields, or read the technical documentation. Where your vendor supports the UAE profile, conformance is largely their problem to solve.
What is unambiguously yours is the data that goes into it. No provider can supply a customer’s tax registration number you do not hold, choose the correct tax category for a supply you have classified wrongly, or decide which unit code matches how you actually sell.
So the sensible division of labour is: let the vendor and provider own the specification, and own the data yourself. Businesses that get this backwards, studying the technical spec while leaving customer master data untouched, spend their effort on the part that was already handled and neglect the part that was not.
Where this goes wrong
- Assuming a VAT-compliant invoice is automatically PINT AE compliant. Content overlaps; structure does not.
- Treating the specification as a layout when it constrains data and meaning, not appearance.
- Holding addresses as one free-text block where structured fields are required.
- Using trading names rather than legal names matching the trade licence.
- Applying tax at invoice level when it is required per line.
- Free-text units of measure where coded values are expected.
- Studying the specification instead of fixing customer master data.
Your next step
- Leave the specification to your vendor and provider: that part is theirs.
- Export your customer master and check legal names, tax registration numbers, address structure.
- Check whether your system applies tax at line level or invoice level.
- Look at your units of measure: free text, or coded?
- Confirm credit notes reference the invoice they correct.
Related questions
Frequently Asked Questions
What is PINT AE?
The UAE’s national specification for structured e-invoices, defining which fields an invoice must carry, how each is represented, and which combinations are valid, so any system on the network can read and validate it without human interpretation.
Is our current tax invoice already compliant?
Almost certainly not, though the content largely overlaps. A compliant tax invoice today holds the right information; PINT AE needs that information as structured, coded, validated data. The gap is in how it is held rather than what you record.
What causes validation failures?
Missing required fields, wrong formats, inconsistency between values, free text where a code is expected, and conditional business rules not satisfied. Inconsistency is the one that surprises people, because the invoice looks correct.
Why do line totals matter so precisely?
A validator checks arithmetically rather than reading for sense. A rounding difference of a few fils between line totals and the invoice total is invisible on a PDF and fatal to validation.
Do we need to understand the specification?
No. It is implemented by your software and your provider. What is yours is the data going into it, no provider can supply a tax registration number you do not hold or fix a supply you classified wrongly.
What is the most common data problem?
Customer master data: addresses as free text rather than structured fields, trading names instead of legal names matching the trade licence, and missing tax registration numbers because nothing previously forced their collection.
Does tax have to be applied per line?
Yes, using defined tax category codes at line level. Most SME systems apply tax at invoice level today, and that has to change before anything can be transmitted.
What about units of measure?
They must come from a controlled coded list rather than free text. “Box” or “hrs” typed into a field will not validate, so item master data generally needs work.
Is PINT AE unique to the UAE?
It is the UAE’s profile of an international base specification rather than a format invented from nothing. That lowers technical risk compared with a bespoke national system, though it does nothing to reduce the data preparation work.
What happens if the specification is updated?
Your provider and software vendor absorb it. That is a large part of what you are paying them for. Specifications of this kind are versioned and updates are published ahead of taking effect. What you should confirm during provider selection is that keeping current with specification changes is explicitly their responsibility under the contract rather than a chargeable extra.
Legal names, tax registration numbers, structured addresses. That one file tells you more about your readiness than the technical specification ever will.
Check my compliance status 058 101 9570
Last reviewed 27 July 2026. Rates, thresholds and deadlines change, the e-invoicing provider deadline has already moved once. Confirm current requirements with the Federal Tax Authority before acting, or ask us to check your position.