UAE reference tool · PINT-AE 1.0.4

Understand a UAE e-invoice before it moves.

Enter commercial facts, inspect derived UAE fields and follow a deterministic SAP DRC-to-ASP learning flow. Invoice data stays in your browser.

Educational simulatorNo data is sent to SAP, an ASP, Peppol or the FTA.Implemented checks are not certification, tax advice or live registration verification.

For the best experience: use a desktop browser to review the XML, field mappings and five-corner transmission model.

Expected: PassScope: In scopeBaseline standard-rated tax invoice.
Scenario

A UAE VAT-registered business supplies standard-rated services to another UAE business.

When it applies

The baseline B2B transaction is in scope when it is carried out in the course of business and no specific exclusion applies.

How to handle it

Issue an electronic Tax Invoice through the appointed ASP; use each party’s own TIN for UAE routing and retain the VAT TRNs and legal identifiers.

Source set: MOF-GUIDE-1.1 · PINT-AE-1.0.4
Suggest a correction or improvementQuick feedback

Scenario context is attached; invoice data is never sent.

Business inputs

Tell us about the transaction

Revision 1
1Who is billing whom?Parties, TRNs, TINs and legal identities
Supplier / seller
Buyer / customer
2What are you billing for?Items, quantity, price and VAT
3When did it happen?Supply, invoice and payment dates
4Are there any adjustments?Currency, credits and corrections
5Anything special?Agency, exports and simulation controls

UAE-only scope

What this simulator checks

It separates commercial data completeness, UAE VAT review, PINT-AE technical checks, simulated exchange and simulated reporting. A technical pass never means FTA approval, buyer acceptance, payment or legal certification.

Technical baseline
PINT-AE 1.0.4, final release 2 June 2026
Runtime validator
Transparent bounded local checks; full XSD and Schematron are not claimed
Data handling
Invoice data stays in browser memory; feedback sends only the entered note and scenario context
Read the UAE regulatory baseline

Crawlable UAE reference

How the UAE e-Invoicing simulation works

  1. The supplier creates invoice data in its business system and prepares it for its Accredited Service Provider.
  2. The sender-side provider validates and converts the data to UAE PINT-AE XML, sends it to the receiver-side provider and reports the required tax data.
  3. The receiver-side provider validates the document, returns an exchange response and, when successful, delivers it to the buyer.
  4. Reporting responses return through the provider network. Buyer business acceptance remains separate from technical exchange and reporting.

UAE simulator questions

Does this simulator send data to SAP, an ASP or the FTA?

No. It is a static educational simulator. Data stays in browser memory unless you download an export.

Does a successful check mean the invoice is FTA approved?

No. Data completeness, VAT review, PINT-AE checks, exchange, reporting and buyer response are separate outcomes. The tool does not provide certification or live verification.

Which technical specification does the simulator use?

The pinned technical baseline is the final UAE PINT-AE 1.0.4 release dated 2 June 2026. The browser runtime performs a disclosed bounded subset of checks.

Is an individual conducting business in scope?

Yes for B2B or B2G Business Transactions, unless a specific exclusion applies. The same natural person acting privately as a consumer is outside mandatory e-invoicing scope.

Does a non-VAT business still need e-invoicing?

Yes when its Business Transactions are in scope. It needs its own FTA TIN and ordinarily issues a Commercial Invoice, not a Tax Invoice.

Scope before format

UAE e-Invoicing implementation decision frame

Apply these decisions in order. A PINT-AE-valid file cannot correct a wrong scope or tax conclusion.

1

Is the supplier acting in Business?

Any Person conducting Business in the UAE can be in scope, including a natural person and a non-VAT-registered business. Private-capacity consumer activity is not in scope.

2

Is it B2B or B2G?

B2B and B2G Business Transactions are in scope. B2C is outside mandatory e-invoicing. Government procurement supplies are B2G; sovereign activity by Government suppliers requires a separate exclusion test.

3

Does a specific exclusion apply?

Check sovereign activities, specified airline transactions, exempt financial services and any later Ministerial exclusions. Do not reuse VAT administrative exceptions as e-invoicing exclusions.

4

Which document and tax category?

Use a Tax Invoice/Credit Note where VAT law requires it; otherwise use a Commercial Invoice/Credit Note. Determine standard, zero, exempt, outside-scope, domestic reverse-charge or margin treatment at supply level.

5

When is implementation mandatory?

Revenue ≥ AED 50m: ASP by 30 October 2026 and go-live 1 January 2027. Revenue below AED 50m: ASP by 31 March 2027 and go-live 1 July 2027. Government Entities: go-live 1 October 2027.

6

Can the document be routed and validated?

Use the party’s own TIN and confirmed endpoint, map mandatory fields, validate with the final applicable PINT-AE artefacts, and reconcile exchange and FTA reporting statuses separately.

Implementation reference

UAE e-Invoicing scenario catalogue

Use this catalogue to understand the commercial fact pattern, scope position and expected handling before testing the populated fixture above. “In scope” assumes the relevant mandatory phase has started or the person has onboarded voluntarily. VAT treatment and e-invoicing scope are separate decisions.

General, tax and processing scenarios26 scenarios
G01

Domestic registered business

In scope

A UAE VAT-registered business supplies standard-rated services to another UAE business.

Applicability
The baseline B2B transaction is in scope when it is carried out in the course of business and no specific exclusion applies.
Expected handling
Issue an electronic Tax Invoice through the appointed ASP; use each party’s own TIN for UAE routing and retain the VAT TRNs and legal identifiers.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G02

Government customer

In scope

A business supplies a UAE Government Entity in its customer capacity.

Applicability
B2G supplies are in scope. This is distinct from a Government Entity acting as supplier in a sovereign, non-competitive capacity, which may be excluded.
Expected handling
Treat the customer as a Government Entity, retain its own TIN and legal identity, and issue the appropriate electronic Tax or Commercial Invoice through the ASP.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G03

Non-VAT supplier

In scope

A person conducting business is not registered for VAT but makes a B2B sale.

Applicability
VAT registration status does not determine e-invoicing scope. A non-VAT supplier still falls in scope for its Business Transactions unless excluded.
Expected handling
Obtain an FTA TIN for the e-invoicing participant, issue a Commercial Invoice rather than a Tax Invoice, and confirm the correct non-taxable tax category instead of inventing a TRN.
Simulator result
Review
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G04

Private consumer

Out of scope

A business supplies a natural person acting only as a private consumer.

Applicability
B2C transactions and supplies to or from natural persons who are not in business are outside the mandatory UAE e-invoicing scope.
Expected handling
Continue the applicable VAT/commercial billing process outside the five-corner exchange. Do not create a business TIN or Peppol endpoint for the consumer solely for this transaction.
Simulator result
Out of scope
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G05

Individual conducting business

In scope

A natural person—such as a sole proprietor or freelancer—makes a supply in the course of business to a UAE business.

Applicability
Legal form is not the test. A natural person conducting Business is a Person in scope for B2B/B2G transactions; the same individual acting privately is a consumer and is out of scope.
Expected handling
Onboard the individual business with an ASP, obtain/use the person’s own FTA TIN, use the appropriate legal identifier type such as EID or passport, and issue a Tax Invoice only if VAT requirements are met.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G06

VAT identifier wrong length

In scope

An otherwise in-scope invoice contains a malformed supplier VAT registration number.

Applicability
The underlying B2B supply is in scope, but the electronic Tax Invoice cannot pass the implemented identifier check.
Expected handling
Correct the TRN from verified master data; it must be 15 digits and align with the supplier TIN. A format pass still does not prove FTA registration.
Simulator result
Blocked
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G07

Missing party details

In scope

Required buyer identity or address information is missing from an in-scope B2B invoice.

Applicability
The transaction remains in scope, but incomplete party data prevents a usable PINT-AE document.
Expected handling
Enrich customer master data before submission; do not substitute placeholder names or addresses in production.
Simulator result
Blocked
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G08

Invalid endpoint

In scope

The buyer electronic address is missing or paired with an unsupported scheme.

Applicability
Routing data is required for the simulated B2B exchange. Scheme and identifier are separate facts.
Expected handling
Use the confirmed Peppol participant identifier and its scheme. For a UAE TIN endpoint, use scheme 0235 and the party’s TIN; verify actual onboarding with the ASP.
Simulator result
Blocked
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G09

Ambiguous group identity

In scope

A VAT-group member is incorrectly identified using an unresolved or group-level participant identity.

Applicability
Intra-VAT-group Business Transactions are in scope, subject to the published temporary implementation grace period. Every member uses its own TIN, not the representative member’s TIN.
Expected handling
Onboard and identify each legal member separately. Use the first 10 digits of that member’s own TRN and plan for intra-group e-invoicing after the grace period.
Simulator result
Blocked
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G10

Unsupported code

In scope

An invoice uses a currency or unit code outside the simulator’s supported subset.

Applicability
Scope is unchanged, but unsupported or invalid code values cannot be safely mapped.
Expected handling
Map source values to the official PINT-AE code lists. Extend the simulator catalogue only after verifying the official code and regression-testing serialization.
Simulator result
Blocked
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G11

Missing line description

In scope

A line lacks the item description or price-base data needed for UAE invoice mapping.

Applicability
The underlying transaction is in scope, but mandatory line information is incomplete.
Expected handling
Capture a meaningful item name and description, quantity, unit, price and non-zero price base quantity before submission.
Simulator result
Blocked
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G12

Altered tax total

In scope

A supplied VAT total has been altered so it no longer reconciles with invoice lines.

Applicability
The transaction is in scope, but arithmetic inconsistency is a blocking data-quality error.
Expected handling
Recalculate from authoritative line data, preserve controlled rounding, and investigate source/ERP mapping rather than overriding the total.
Simulator result
Blocked
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G13

Discount and surcharge

In scope

An in-scope B2B invoice contains a line discount and an additional line charge.

Applicability
Allowances and charges are permitted when correctly represented and assigned the proper VAT treatment.
Expected handling
Record charge indicators, reasons and amounts, calculate line net value as quantity × net price/base quantity minus allowance plus charge, and reconcile totals.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G14-zero

Zero-rated supply

Conditional

A supply is classified as zero-rated for UAE VAT.

Applicability
Zero rating does not by itself remove a Business Transaction from e-invoicing scope, but the statutory conditions and evidence must be established.
Expected handling
Use the zero-rate category and 0% only after tax review; retain evidence and apply any additional export or sector-specific fields.
Simulator result
Review
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G14-exempt

Exempt supply

Conditional

A supply is classified as exempt from UAE VAT.

Applicability
Many exempt Business Transactions still use Commercial Invoices, but exempt financial services specifically excluded by the Ministry are outside mandatory e-invoicing.
Expected handling
Confirm both the VAT exemption and the separate e-invoicing exclusion test. If still in scope, issue a Commercial Invoice with the exempt category and basis.
Simulator result
Review
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G14-outside

Outside-scope supply

Conditional

The supply is asserted to be outside the scope of UAE VAT.

Applicability
VAT scope and e-invoicing scope are separate tests. An out-of-scope VAT transaction may still be a Business Transaction requiring a Commercial Invoice.
Expected handling
Document the VAT place-of-supply or statutory basis, then independently decide e-invoicing scope. If in scope, issue a Commercial Invoice using the correct category.
Simulator result
Review
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G15

Foreign currency with conversion

In scope

An in-scope Tax Invoice is issued in a foreign currency with an AED exchange rate.

Applicability
Foreign invoice currency does not remove the transaction from scope. UAE VAT reporting requires the relevant AED tax view.
Expected handling
Use an approved source and date for the exchange rate, carry document and AED tax currency amounts as required, and reconcile conversions and rounding.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G16

Missing AED conversion

In scope

A foreign-currency Tax Invoice lacks the AED conversion evidence used for VAT reporting.

Applicability
The transaction remains in scope, but the invoice cannot be completed safely without the AED rate and converted tax amounts.
Expected handling
Obtain the applicable exchange rate from the controlled tax/accounting process and rerun all AED calculations before submission.
Simulator result
Blocked
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G17

Credit note with reference

In scope

A reduction or correction is linked to a previously issued Tax Invoice.

Applicability
An electronic Tax Credit Note is required when output tax is reduced, including relevant cancellation, refund, price reduction or error cases.
Expected handling
Issue a positive-valued CreditNote document, reference the preceding invoice and state the reason; do not amend an already issued e-invoice in place.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G18

Incomplete credit note

In scope

A proposed credit note lacks its preceding invoice reference or correction reason.

Applicability
The correction may be in scope, but the document is incomplete and cannot support the audit trail.
Expected handling
Identify the affected invoice or invoices, record the reason and ensure the credit category matches the original Tax or Commercial Invoice.
Simulator result
Blocked
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G19

Export supply

Conditional

A UAE supplier makes an export sale to a foreign business.

Applicability
Exports are in e-invoicing scope when they are Business Transactions, although the VAT treatment and evidence depend on the export conditions. Some specifically excluded financial or airline transactions differ.
Expected handling
Set the export transaction flag, confirm zero-rating evidence where claimed, and use the buyer’s actual Peppol ID or the prescribed 0235:9900000099 endpoint when no Peppol ID exists.
Simulator result
Review
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G20

Identical retry

In scope

The same logical document and unchanged payload are submitted again after an uncertain or repeated request.

Applicability
Retry handling is an operational control for an in-scope document, not a new tax transaction.
Expected handling
Use a stable document identity and idempotency control. Reconcile the earlier status before creating any replacement document.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G21

Changed payload conflict

In scope

The source payload cannot be mapped into the agreed ASP/PINT-AE structure.

Applicability
The Business Transaction is in scope, but the document must not leave Corner 1 until mapping succeeds.
Expected handling
Quarantine the document, correct or enrich source data, regenerate deterministically and retain the failed-attempt audit trail.
Simulator result
Simulated fault
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G22

Receiver timeout

In scope

A sender does not receive a conclusive exchange response within the expected time.

Applicability
A timeout is an unknown state, not proof of rejection or non-delivery.
Expected handling
Query ASP status using the same identity, retry idempotently where agreed, and avoid issuing a duplicate invoice while the original outcome is uncertain.
Simulator result
Simulated fault
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G23

Reporting failure

In scope

Invoice delivery succeeds but a Tax Data Document reporting branch fails.

Applicability
Exchange, C2/C3 reporting and their MLS responses are separate states.
Expected handling
Preserve evidence of successful delivery, remediate and retry the failed reporting track through the ASP, and do not misstate the invoice as undelivered.
Simulator result
Simulated fault
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
G24

Buyer rejection

In scope

The buyer rejects the invoice for a business reason after successful technical delivery.

Applicability
Buyer business acceptance is separate from PINT-AE exchange validation and FTA reporting.
Expected handling
Resolve the dispute commercially. If the issued invoice must be reduced or cancelled, issue the appropriate electronic credit note rather than changing delivery history.
Simulator result
Simulated fault
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
Utilities billing scenarios17 scenarios
U01

Monthly electricity

In scope

A utility bills a UAE business for monthly electricity consumption.

Applicability
The recurring supply is an in-scope B2B continuous supply when no exclusion applies.
Expected handling
Use the continuous-supply flag, billing period, service-point/meter references and the correct VAT point and tariff data.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U02

Electricity and water

In scope

Electricity and water consumption are billed together to the same business customer.

Applicability
Compatible supplies by the same supplier to the same buyer may share an invoice, with tax categorisation at line level.
Expected handling
Keep distinct units, descriptions, service references and tax facts per line; reconcile each VAT category and document total.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U03

Residential electricity

Out of scope

A utility supplies a natural person at a residence in the person’s private capacity.

Applicability
The B2C transaction is outside mandatory e-invoicing even though ordinary VAT invoicing and billing obligations may continue.
Expected handling
Keep the consumer bill outside the five-corner flow and do not fabricate a business endpoint. Reassess if the premises/customer is acting in business.
Simulator result
Out of scope
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U04

Connection charge

In scope

A utility charges a business a one-time connection fee.

Applicability
A one-time charge connected with a B2B utility supply is ordinarily a Business Transaction in scope.
Expected handling
Issue the appropriate electronic invoice at the correct tax point and distinguish the one-time service from consumption lines.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U05

Recurring and one-time charges

In scope

A business bill combines recurring consumption and a one-time connection charge.

Applicability
Both charge patterns can be in scope on one document when the same supplier and buyer are involved.
Expected handling
Apply the continuous-supply flag where the invoiced supply includes it, preserve line-level descriptions/tax, and avoid using the flag as a substitute for the billing period.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U06

Municipality collection

Conditional

A utility or collection party bills a customer as a disclosed agent for a municipality or other principal.

Applicability
Agent billing applies only to a disclosed agency. The underlying supplier remains responsible for issuance, and sovereign-activity exclusions must be assessed separately.
Expected handling
Identify the principal and supplier correctly, set the agent flag, confirm contractual authority and tax treatment, and do not present the agent’s own charge as the principal’s supply.
Simulator result
Review
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U07

Agency missing principal

Conditional

A document is marked as disclosed-agent billing but the principal is unidentified.

Applicability
Agency treatment cannot be implemented reliably without knowing the supplier/principal and the underlying transaction.
Expected handling
Block submission until principal identity, mandate, supply ownership, endpoint and tax responsibilities are confirmed.
Simulator result
Blocked
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U08

Mixed principals

Conditional

One utility bill attempts to combine charges belonging to more than one principal/supplier.

Applicability
PINT-AE represents one accounting supplier per invoice. Multiple principals cannot be collapsed into one supplier identity merely for collection convenience.
Expected handling
Separate the supplies into invoices for each principal/supplier unless a legally supported model makes one party the supplier; keep any collector/agent role explicit.
Simulator result
Blocked
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U09

Invalid billing period

In scope

A recurring utility bill has a period end before its start.

Applicability
The supply can be in scope, but the contradictory service period is a blocking source-data error.
Expected handling
Correct the meter/billing period in the source system before calculating the VAT point or issuing the invoice.
Simulator result
Blocked
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U10

Estimated bill correction

In scope

An estimated utility invoice is reduced after an actual meter reading is received.

Applicability
A reduction linked to the original bill is handled through the appropriate electronic credit note.
Expected handling
Reference the estimated invoice, state the actual-reading reason and credit only the supported difference; issue an additional invoice instead if the adjustment increases consideration.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U11

Zero consumption, fixed charge

In scope

Consumption is genuinely zero but a fixed monthly charge remains payable.

Applicability
Zero quantity is valid evidence of no measured consumption and should not be treated as missing data.
Expected handling
Retain the zero-consumption line if operationally useful and invoice the fixed charge separately with its own quantity, unit and VAT treatment.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U12

Deposit or advance

Conditional

A utility receives money described as a refundable security deposit or an advance payment.

Applicability
The labels are not interchangeable: a genuine refundable security deposit may not be consideration for a supply, while an advance can trigger invoice/VAT consequences.
Expected handling
Classify the receipt from contract facts before invoicing. For a taxable advance, issue/reference the required invoice and use Paid Amount and Preceding Invoice Reference on the final invoice; do not tax a true deposit by default.
Simulator result
Review
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U13

EV charging sessions

In scope

Compatible EV charging sessions are aggregated for a business customer.

Applicability
B2B charging sessions may be consolidated when supplier, buyer, tax treatment and billing period are compatible.
Expected handling
Preserve session or source references in the billing ledger, report the aggregate quantity and tariff accurately, and keep a clear reconciliation to the invoice line.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U14

Duplicate EV session

In scope

A source charging session appears more than once in the billing population.

Applicability
This is a source-event duplicate risk, separate from retrying the same electronic invoice.
Expected handling
Hold the invoice for reconciliation, deduplicate by immutable session identity and retain evidence of the decision before submission.
Simulator result
Review
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U15

Multiple premises

In scope

One business customer is billed for utility service at multiple premises.

Applicability
Multiple premises can be represented when the same supplier and buyer are involved and the tax/document treatment is compatible.
Expected handling
Retain service-point references per line and reconcile each location’s readings, billing period and tax facts.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U16

Final move-out credit

In scope

A final move-out reconciliation reduces a previously issued business utility invoice.

Applicability
A supported reduction is documented with an electronic credit note linked to the original invoice.
Expected handling
Reference the final bill, state the meter-reconciliation reason and maintain service-point and reading evidence.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
U17

Fractional tariff

In scope

A metered utility line uses fractional consumption and a multi-decimal tariff.

Applicability
Fractional source values are normal, but monetary amounts must follow PINT-AE arithmetic and invoice-level rounding rules.
Expected handling
Keep source precision, calculate deterministically, round monetary outputs only at the required stage and reconcile line, VAT-category and document totals.
Simulator result
Pass
Source set
MOF-GUIDE-1.1 · PINT-AE-1.0.4
Authoritative baseline

Scenario explanations are grounded in the UAE Ministry of Finance Electronic Invoicing Guidelines v1.1 and the final PINT-AE 1.0.4 specification. The Ministry portal remains the official place to check later programme changes.

Read MoF Guidelines v1.1Read PINT-AE 1.0.4Check the MoF programme portal

UAE e-Invoicing knowledge base

Three UAE Peppol specifications, one data model

All three specifications published by the UAE Peppol Authority are at version 1.0.4. This simulator generates and checks candidate XML for PINT-AE Billing only; PINT-AE Self-Billing and the AE Tax Data Document are documented below for reference but are not simulated.

PINT-AE Billing

Simulated by this tool

The core UAE invoicing specification. A supplier issues a Tax Invoice, Commercial Invoice or Tax Credit Note to a buyer using the OpenPeppol PINT methodology, aligned to UAE VAT law and the Ministry of Finance rollout.

Version
1.0.4
Customization ID
urn:peppol:pint:billing-1@ae-1
Process ID
urn:peppol:bis:billing
  • Document types: 380 (Commercial invoice / Tax Invoice), 480 (invoice out of scope of tax), 381 (Credit note).
  • The supplier (Corner 1) is always the accounting party responsible for the invoice, even when routed through an agent.
  • This is the only profile this simulator generates XML for and checks against implemented rules.

PINT-AE Self-Billing

Documented — not simulated

A variant used when the buyer, under a self-billing agreement, produces the invoice on the supplier’s behalf. It reuses the entire PINT-AE Billing data model — every code list checked in this simulator (VAT category, tax exemption reason, credit reason, EAS, payment means) is byte-for-byte identical between the two profiles.

Version
1.0.4
Customization ID
urn:peppol:pint:selfbilling-1@ae-1
Process ID
urn:peppol:bis:selfbilling
  • Document types: 389 (Self-billed invoice) replaces 380; 261 (Self billed credit note) replaces 381.
  • Party roles are NOT swapped: cac:AccountingSupplierParty still identifies the real seller and cac:AccountingCustomerParty still identifies the real buyer — only the CustomizationID, ProfileID and document-type code change.
  • The official example does not carry a separate "self-billing authorisation" business term in the XML — the self-billing agreement is a contractual/business fact, not a modelled field.
  • Not implemented here: this simulator always issues under the standard Billing profile (380/381/480). Treat self-billing eligibility, mandate and agreement evidence as a business decision outside this tool.

AE Tax Data Document (TDD)

Documented — not simulated

A separate reporting envelope — not an invoice and not a wrapper around one — that both the invoice issuer’s and invoice receiver’s Accredited Service Providers use to report an invoice to the FTA (Corner 5), in parallel with the Corner 1→Corner 4 invoice exchange.

Version
1.0.4
Customization ID
urn:peppol:taxdata:ae-1
Process ID
urn:peppol:taxreporting
  • Root element: pxs:TaxData (its own urn:peppol:schema:taxdata:1.0 namespace, not Invoice-2/CreditNote-2).
  • Every TDD states a reporting action (Submit/Resubmit/Withdraw/Failed), a reporting role (Sender/Receiver) and a scope (Domestic/International Peppol/International non-Peppol) — see the code tables below.
  • Each pxs:ReportedTransaction carries two independent layers: a flattened pxs:ReportedDocument data extract (VAT TRNs and totals only — no full party address or legal entity) and an optional pxs:SourceDocument that can embed the entire original UBL invoice.
  • The five-corner simulation in this tool already models C2→C5 and C3→C5 TDD reporting and its MLS responses as SIM-prefixed educational states; it does not generate or validate an actual TDD document.

Critical know-how for mandatory fields

TIN vs. TRN

The 10-digit e-Invoicing TIN (party endpoint identity, IBR-148-AE) and the 15-digit VAT TRN (IBT-031/048, IBR-132-AE) are different numbers used for different purposes. When a party is VAT registered, the TRN’s first 10 digits must equal its TIN (SIM-AE-TIN-TRN) — but a non-VAT-registered business still needs its own TIN to be onboarded at all.

Endpoint scheme and value are always two facts

A Peppol electronic address is schemeID + value (e.g. 0235:1000000003), never one string. Scheme 0235 specifically requires the endpoint value to equal the party TIN (SIM-AE-ENDPOINT-TIN) — a syntactically valid value is not proof of Peppol onboarding.

Emirate/subdivision codes are fixed

IBR-128-AE requires one of the seven official emirate codes (AUH, DXB, SHJ, UAQ, FUJ, AJM, RAK) for a UAE party — free text is rejected.

Standard VAT rate is always exactly 5.00

IBR-190-AE fails any standard-rated line that is not precisely 5.00% — 5, 5.0 and 5.00 are accepted string forms, but no other percentage is.

Legal registration type must be coded, and trade licences need an authority

IBR-181-AE (seller) / IBR-180-AE (buyer) require one of TL, EID, PAS or CD. A trade licence (TL) additionally needs its issuing authority (SIM-AE-LICENCE-AUTHORITY) — the licence number alone is not sufficient identity evidence.

VAT category vs. VAT treatment evidence are separate

Selecting Zero/Exempt/Outside-scope only records the category code (Z/E/O); it does not verify the statutory basis. Two more official categories exist but are not modelled here: AE (reverse charge — buyer self-accounts VAT) and Ν (standard rate on an additional taxable base).

Credit notes need three linked facts, not one

A credit note requires the original invoice reference, a coded reason (DL8.61.1.A–E or VD — this is the complete official list, confirmed against CreditReason.gc) and free-text explanation together (SIM-VAT-CREDIT/IBR-001-AE). A missing reference breaks the audit trail even if the amount is correct.

Foreign-currency invoices need AED evidence, not just a rate

Any non-AED currency requires an AED exchange rate (SIM-VAT-FX-001); the simulator then recalculates net/VAT/gross in AED for the parallel Tax Currency view, exactly as UAE VAT reporting requires.

Real-world example files default to unit H87, not C62

C62 ("one") is a dimensionless count; H87 ("piece") is what the official PINT-AE example invoices actually use for physical goods. Both are valid UNECERec20 codes — pick the one that matches what is really being counted.

Self-billing does not change who the supplier is

Even when the buyer issues the document under a self-billing agreement, the supplier remains the accounting party in cac:AccountingSupplierParty and remains legally responsible for the invoice — only the document-type code (389/261) and profile identifiers change.

A TDD is not proof the invoice was delivered

TDD reporting (Corner 2/3 → Corner 5) and invoice exchange (Corner 1→→Corner 4) are tracked and can fail independently — a successful TDD submission does not mean the buyer received the invoice, and a delivered invoice does not guarantee its TDD reported cleanly.

Official UAE e-Invoicing code lists

Reference-only tables sourced from the official PINT-AE, PINT-AE Self-Billing and AE TDD genericode files. Only currencies, units, payment means, emirate codes and credit reasons are enforced at runtime by this simulator — see each table for its implementation status.

Invoice document type codes (UNCL1001)3 codes
PINT-AE-1.0.4 / PINT-AE-SB-1.0.4
CodeNameDescription
380Commercial invoiceStandard UAE Tax Invoice / Commercial Invoice root type code. Used by PINT-AE Billing.
480Invoice out of scope of taxA supplier outside the scope of tax regulations issues this; no tax details are included.
389Self-billed invoiceAn invoice the buyer produces instead of the seller. Replaces 380 in the PINT-AE Self-Billing profile.
Credit note document type codes (UNCL1001)3 codes
PINT-AE-1.0.4 / PINT-AE-SB-1.0.4
CodeNameDescription
381Credit noteStandard UAE Tax Credit Note root type code. Used by PINT-AE Billing.
81Credit note related to goods or servicesCredit information related to a goods/services transaction.
261Self billed credit noteThe customer claims credit in a self-billing arrangement. Replaces 381 in the PINT-AE Self-Billing profile.
AE-TransType — 8-position transaction flag string8 codes
PINT-AE-1.0.4 transactiontype.gc (identical in Self-Billing)
CodeNameDescription
Position 1Free trade zoneSupply of goods or services in a Free Trade Zone.
Position 2Deemed supplySupply of goods or services without consideration.
Position 3Profit Margin SchemeSupply of goods under the profit margin scheme.
Position 4Summary invoiceMore than one supply to the same person in the same calendar month, consolidated.
Position 5Continuous supplySupply of goods and/or services made on a recurrent basis.
Position 6Agent billingA registered agent makes a supply on behalf of a principal.
Position 7Supply through e-commerceSupply of goods or services via e-commerce.
Position 8ExportsSupply of goods or services outside the country.
VAT category codes (Aligned Tax Category Codes)6 codes
PINT-AE-1.0.4 Aligned-TaxCategoryCodes.gc, version D.16B
CodeNameDescription
SStandard rateSimulated. The UAE standard rate (5.00%) applies.
ZZero ratedSimulated as a documented category; underlying evidence is not verified.
EExempt from taxSimulated as a documented category; underlying evidence is not verified.
OOutside the scope of tax / not subject to VATSimulated as a documented category; underlying evidence is not verified.
AEVAT reverse chargeNot simulated. The standard rate is self-accounted for by the buyer instead of charged by the seller.
Ν (Greek capital Nu)Standard rate additional VATNot simulated. Standard VAT on an additional taxable base not included in the document totals.
Tax exemption reason codes4 codes
PINT-AE-1.0.4 Aligned-TaxExemptionCodes.gc, version 2022
CodeNameDescription
DL8.46.1Certain financial servicesNot simulated. Free-text evidence only; use this code as the coded basis in production.
DL8.46.2Supply of residential units (lease or sale)Not simulated.
DL8.46.3Bare landNot simulated.
DL8.46.4Local passenger transportNot simulated.
Credit/debit note reason codes6 codes
PINT-AE-1.0.4 CreditReason.gc, version 1 (identical in Self-Billing)
CodeNameDescription
DL8.61.1.ASupply cancelledImplemented and selectable in the simulator.
DL8.61.1.BTax treatment changed with nature of supplyImplemented and selectable.
DL8.61.1.CAgreed consideration altered (incl. bad debt relief)Implemented and selectable.
DL8.61.1.DGoods/services and consideration returnedImplemented and selectable.
DL8.61.1.ETax charged or treatment applied in errorImplemented and selectable.
VDVolume discountImplemented and selectable.
Electronic Address Scheme (EAS) codes relevant to UAE trade6 codes
PINT-AE-1.0.4 eas.gc (OpenPeppol EAS list)
CodeNameDescription
0235UAE Tax Identification Number (TIN)The scheme the simulator uses for UAE routing. Endpoint value must equal the party TIN.
0088EAN Location Code (GLN)Used for the non-UAE export example endpoint in this simulator.
0242OpenPeppol Service Provider Identification Scheme (SPIS)Used only inside an AE TDD, for the FTA-side reporting endpoint — not a general invoicing party address.
0060Data Universal Numbering System (D-U-N-S Number)International identifier, not UAE-specific.
9930Germany VAT numberExample of a foreign-buyer VAT scheme for cross-border supplies.
9925Belgium VAT numberExample of a foreign-buyer VAT scheme for cross-border supplies.
Payment means codes used in AE (UNCL4461, curated subset)9 codes
PINT-AE-1.0.4 UNCL4461.gc, version D.16B (identical in Self-Billing)
CodeNameDescription
1Instrument not definedNot currently selectable in the form.
10In cashNot currently selectable in the form.
20ChequeNot currently selectable in the form.
21Banker's draftNot currently selectable in the form.
30Credit transferImplemented and selectable — the simulator default.
49Direct debitImplemented and selectable.
54Credit cardNot currently selectable in the form.
55Debit cardNot currently selectable in the form.
68Online payment serviceNot currently selectable in the form.
TDD document type code — reporting action4 codes
AE-TDD-1.0.4 TDD-dtc.gc, version TDT-type-1
CodeNameDescription
SSubmitSubmitting a Tax Data Document.
RResubmitRevising a previously reported TDD.
WWithdrawWithdrawing a previously reported TDD.
FFailedThe document failed validation.
TDD reporting role2 codes
AE-TDD-1.0.4 TDD-rr.gc, version TDT-role-1
CodeNameDescription
01SenderUsually the seller: the party issuing and sending the reported document.
02ReceiverUsually the buyer: the party that received the reported document.
TDD document scope3 codes
AE-TDD-1.0.4 TDD-ds.gc, version TDT-scope-1
CodeNameDescription
DDomesticReporting on a domestic invoice.
IPInternational Peppol invoiceReporting on an invoice exchanged through the Peppol network.
INPInternational non-PeppolReporting on a cross-border invoice exchanged outside Peppol.
Unit-of-measure subset (UNECERec20) beyond the simulator defaults17 codes
PINT-AE-1.0.4 UNECERec20.gc
CodeNameDescription
H87PieceThe unit used throughout the official PINT-AE example files — not the simulator default C62.
KGMKilogram—
GRMGram—
TNETonne (metric ton)—
MTRMetre—
CMTCentimetre—
KMTKilometre—
MTKSquare metre—
LTRLitre—
DAYDay—
WEEWeek—
MONMonth—
ANNYear—
EAEach—
XBXBox—
SETSet—
PRPair—
Common allowance/charge reason codes7 codes
PINT-AE-1.0.4 UNCL7161.gc (charges) and UNCL5189.gc (allowances)
CodeNameDescription
95DiscountLine-level allowance, UNCL5189.
100Special rebateDocument-level allowance, UNCL5189.
AACTechnical modificationLine-level charge, UNCL7161.
AATRush deliveryDocument-level charge, UNCL7161.
FCFreight serviceCharge, UNCL7161.
HDHandlingCharge, UNCL7161.
PCPackingCharge, UNCL7161.
HomeKnowledgeInsightsAI LabToolsProfile