UAE e-invoicing ERP integration: PINT AE 5-corner model

Digital transformation

You appointed an Accredited Service Provider and assumed the hard work was done. It is not: the ASP solves transport, while every value on the invoice is still calculated in your ERP. With mandatory issuing starting 1 January 2027, here is exactly what has to change in your finance systems, field by field.

Why your ASP cannot fix your ERP compliance obligations

Successful UAE e-invoicing ERP integration under the PINT AE 5-corner model requires your finance system to calculate all invoice values, map 51 mandatory data fields, and handle dual reporting to the Federal Tax Authority (FTA). While your Accredited Service Provider (ASP) manages network transmission and assigns the Peppol UUID, it will not fix invalid tax categories, broken line calculations, or unmapped buyer identifiers. If your organisation books AED 50m or more in annual revenue, you are in Phase 1 of the UAE e-invoicing mandate: an ASP had to be appointed by 30 October 2026 (extended from 31 July 2026 by the amendment to Ministerial Decision No. 244 of 2025), with mandatory issuing and receiving starting on 1 January 2027. That leaves a tight window to ensure your ERP produces compliant PINT AE XML data before go-live.

The Ministry of Finance Electronic Invoicing Guidelines v1.1 put the compliance responsibilities in writing: the ASP transmits and reports, but calculating all Electronic Invoice values is the supplier's job. Every dirham, every tax code, and every rounding decision originates in your ERP and billing logic. If your finance systems cannot produce PINT AE compliant master data and totals, no ASP can correct them for you.

This post covers the ERP-side work that starts after signing your ASP contract: field-level requirements before 1 January 2027, a complete worked example, an integration architecture that survives rejection, and a six-week cutover plan. If you are still evaluating providers, review our companion guide on how to choose an e-invoicing ASP in the UAE.

How does UAE e-invoicing ERP integration work in the PINT AE 5-corner model?

The UAE uses a 5-corner model, defined in the MoF guidelines:

1. Corner 1: Supplier. You submit invoice data to your ASP in whatever format you agreed with it.
2. Corner 2: Your ASP. Validates the data, converts it to the UAE standard XML (PINT AE), and transmits it to the buyer's ASP.
3. Corner 3: The buyer's ASP. Validates the XML and confirms receipt back to Corner 2.
4. Corner 4: The buyer. Receives the invoice in the format agreed with its ASP.
5. Corner 5: The Federal Tax Authority. In parallel with the exchange, both Corner 2 and Corner 3 report tax data to the FTA using a separate Peppol document, the Tax Data Document (TDD), specified in the PINT AE Tax Data Document BIS.

That "in parallel" is the bit finance leaders underestimate. There are two reporting legs per invoice: your ASP reports issuance, the buyer's ASP reports reception, and if the buyer's ASP cannot validate the document it sends a Tax Data Status (TDS) message, TDD type code "F", instead of a normal TDD. Your invoice can be sent, delivered, and still not properly reported. Your error handling has to watch both legs.

Three consequences follow directly from the framework:

• The ASP does not compute. The MoF responsibilities table assigns calculation of all invoice values to the supplier, and secure transmission to the ASP. If the tax breakdown is wrong, the ASP rejects; it does not fix.
• The UUID is the ASP's, the numbering is yours. The ASP generates a UUID for every Electronic Invoice to prevent duplication (MoF guidelines, section 5.2). Your ERP still owns the invoice number, the credit note reference and the sequence, and the FTA cares about those.
• There is no QR code. Electronic Invoices are XML only (section 5.3). Everything a reviewer or auditor needs has to be reconstructable from the XML and the associated records you keep.

What are the 51 mandatory PINT AE fields required in your ERP?

On 23 February 2026 the FTA published the UAE Electronic Invoice Mandatory Fields document: 51 mandatory fields for an electronic Tax Invoice, and 49 for a commercial Electronic Invoice. KPMG's summary of the technical guidance makes the point plainly: this list is the required mapping for ERP, POS and billing systems. Work through it against your ERP and you will find four recurring gap classes.

Four details deserve explicit attention before your mappers are written:

VAT category codes. PINT AE carries a VAT category code on every line, every document-level allowance and charge, and every VAT breakdown group. The categories cover standard rated (the UAE rate is 5%), zero rated, exempt, out of scope and reverse charge. The rules are strict and mechanical: for standard rated, the category tax amount must equal the taxable amount multiplied by the category rate; for exempt and out of scope, the rate must be zero or absent; for reverse charge, the tax amount must be zero. Your ERP's internal tax codes must map one-to-one onto these categories, and a single invoice can carry several categories at once.

Allowances and charges. Three levels exist in PINT AE: document level (with its own VAT category and a summed AllowanceTotalAmount / ChargeTotalAmount), line level (inherits the line's VAT category), and the price-level allowance that explains how net price was derived from gross price. If your ERP books "contractual discount" or "freight recovery" as a G/L note or a text line, it will not survive validation.

Rounding and totals. PINT AE has explicit calculation and rounding chapters, and validation enforces the arithmetic: the VAT breakdown must reconcile to the line sums plus charges minus allowances for each category and rate. There is also a rounding amount term (IBT-114) used to adjust the payable amount. Decide your rounding policy once, apply it in the ERP, and test that it round-trips.

Currency. Invoice currency can be anything, but tax reporting values must be in AED: the FTA list includes "VAT line amount in AED" and "Invoice line amount in AED" as separate mandatory fields, alongside the tax accounting currency term and the exchange rate. If you invoice in USD, your mapper needs the rate and both amount sets.

Worked example: how does an invoice flow through PINT AE end to end?

Gulf Industrial Supplies (a Jebel Ali distributor) issues INV-2027-004182 on 12 March 2027 to a Sharjah buyer. Customer master: name Gulf Engineering LLC, TRN 100234567800003, legal registration type TL, trade licence 765432, address with Emirate recorded.

Step 1: derive identifiers. TIN is the first 10 digits of the TRN: 1002345678. Buyer electronic address becomes 0235:1002345678. Seller endpoint is built the same way from the seller TIN.

Step 2: classify the transaction. Standard B2B sale, UAE mainland, not a free zone or export scenario, so the transaction type code is the neutral flag string:

<cbc:CustomizationID>urn:peppol:pint:billing-1@ae-1</cbc:CustomizationID>
<cbc:ProfileID>urn:peppol:bis:billing</cbc:ProfileID>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:ProfileExecutionID>00000000</cbc:ProfileExecutionID>

(These snippets follow the PINT AE Billing BIS, version 1.0.1 of the published specification. CustomizationID urn:peppol:pint:billing-1@ae-1 and ProfileID urn:peppol:bis:billing are fixed values; anything else is rejected.)

Step 3: map the lines.

Sum of invoice line net amounts: AED 8,620.00.

Step 4: add the structured allowance and charge. Delivery charge AED 150.00 (reason code FC, freight), contractual discount AED 200.00 (reason code 95, discount). Both carry VAT category standard rated:

<cac:AllowanceCharge>
  <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>FC</cbc:AllowanceChargeReasonCode>
  <cbc:Amount currencyID="AED">150.00</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID>S</cbc:ID><cbc:Percent>5</cbc:Percent>
    <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>

Step 5: totals. 8,620.00 + 150.00 minus 200.00 = invoice total without tax AED 8,570.00. VAT breakdown, standard rated at 5%: taxable amount 8,570.00, tax amount 428.50. Invoice total with tax 8,998.50, amount due for payment 8,998.50, due date 11 April 2027. The mapper must produce exactly this chain; the validator recomputes it.

Step 6: submit and confirm. Your ASP converts to PINT AE, transmits to the buyer's ASP, reports a TDD to the FTA, and forwards the confirmations to you. Store the ASP's UUID, the confirmations and the submitted XML against INV-2027-004182.

Step 7: the credit note. The buyer returns 5 filter units. You cannot issue a negative invoice in the UAE (the PINT AE UAE rules permit reverting only by credit note). Issue CN-2027-00087 with document type code 381, set the mandatory credit note reason code (BTAE-03) to the code list value for returned goods, and reference the preceding invoice number and issue date. Only the volume discount reason code "VD" exempts you from the preceding invoice reference.

How do you handle credit notes, self-billing and special transaction scenarios?

The MoF guidelines define eight special scenarios, and PINT AE marks each one as a bit in an 8-digit transaction type code carried in ProfileExecutionID: free trade zone (10000000), deemed supply (01000000), profit margin scheme (00100000), summary invoice (00010000), continuous supply (00001000), disclosed agent billing (00000100), supply through e-commerce (00000010), exports (00000001). Several will bite Gulf businesses specifically:

• Free zone transactions need the beneficiary in addition to the customer, and the beneficiary may be a different entity from the contracting party.
• Deemed supplies and non-onboarded buyers use predefined endpoints. Deemed supply goes to 0235:9900000097; exports where the buyer is not on Peppol go to 0235:9900000099; a buyer not yet subject to UAE e-invoicing goes to 0235:9900000098. In that last case the guidelines require you to issue a regular PDF tax invoice in addition, until the buyer is onboarded. Your AR process therefore runs dual output through the transition.
• Retention and provisional invoices. There is no provisional invoice category. Interim amounts are normal Electronic Invoices; retention calculations stay on a separate commercial document and a tax invoice with VAT is issued when the retention falls due.
• Self-billing inverts the flow: the buyer issues the electronic tax invoice on the supplier's behalf, and both parties must be on the system. Check every self-billing agreement now, because your counterparties' onboarding dates are not yours.
• VAT groups get a grace period: intra-group transactions between members of the same VAT group are exempt from the obligations for 24 months from 1 January 2027. Everything else is in scope from day one.

How should you build idempotent submission and an error queue?

The single worst failure mode in every e-invoicing rollout that has gone badly is not rejection. It is silence: an invoice rejected on a Friday afternoon, nobody alerted, the goods already delivered, and cash collection simply stops. Build the submission layer as a state machine with duplicate suppression before you test anything else.

States: NEW, VALIDATED, IN_FLIGHT, ACCEPTED, REJECTED, ARCHIVED. One outbox row per ERP document number, and resubmission always uses the same idempotency key:

def submit_to_asp(invoice_id: str, payload: dict) -> None:
    row = outbox.get(invoice_id)          # one row per ERP document number
    if row is None:
        outbox.insert(invoice_id, state="NEW", payload=payload, attempts=0)
        row = outbox.get(invoice_id)
    if row.state in ("IN_FLIGHT", "ACCEPTED"):
        return                            # duplicate suppression: never resend blindly
    try:
        outbox.update(invoice_id, state="IN_FLIGHT")
        receipt = asp.submit(idempotency_key=invoice_id, document=row.payload)
        outbox.update(invoice_id, state="ACCEPTED",
                      asp_uuid=receipt.uuid, submitted_at=now())
    except AspRejected as exc:
        outbox.update(invoice_id, state="REJECTED", error=exc.code,
                      attempts=row.attempts + 1)
        alert_finance_ops(invoice_id, exc.code)   # a human must see this today

Three rules to enforce on top: (1) a rejected document is fixed at the source (master data or pricing) and resubmitted under the same business key, never resent and hoped; (2) the error queue has an owner in finance operations with a daily clearing SLA, and REJECTED rows older than one working day escalate; (3) watch both reporting legs, because a TDS from the buyer's side means the invoice moved but the tax report did not.

What is the six-week cutover checklist before 1 January 2027?

Assuming the ASP contract is signed and onboarding in EmaraTax is done (onboarding starts with you, not the ASP):

On archiving, read Article 11 of Ministerial Decision No. 243 of 2025 as the guidelines interpret it: Electronic Invoices, credit notes and their associated data must be retrievable and reproducible for the FTA, and the guidelines accept storage outside the UAE provided records can be produced promptly in complete, readable form. "Associated data" means what supports integrity, authenticity and auditability, not every commercial document. Retention is 5 years from the end of the relevant tax period for taxable persons (7 years for real estate records), extendable by 4 years if there is a dispute or audit. Practically: store the submitted XML, the ASP receipt and UUID, both confirmations, and the source extract that produced the document.

What reconciliations should finance run during the first month?

From 1 January 2027, run these four reconciliations weekly, then monthly:

1. Submission log to AR ledger. Every posted AR invoice appears in the outbox as ACCEPTED with a UUID. Any gap is either an unsent invoice (compliance risk) or a posted document with no billing record (data integrity risk).
2. Accepted invoices to tax reporting. Confirm each accepted invoice has both TDD legs. A TDS event is an open item, not a curiosity.
3. Credit notes to originals. Every credit note references a preceding invoice and a reason code. Unreferenced credit notes will fail validation and, worse, distort your VAT position.
4. Error queue to cash. Rejected invoices older than 24 hours are escalated, because a rejected invoice is an uncollected receivable. Track the count and age as a KPI alongside DSO for the first quarter.

Add one monthly check for the tax team: the VAT breakdown per category and rate in the submitted XML should tie to the VAT return working papers. This is where a rounding policy drift or an unmapped tax code becomes visible before an audit finds it.

Which ERP integration approach fits your architecture?

If you are in Phase 1 and the ASP is appointed, do these three things this week. First, run the 51-field gap analysis on one real invoice per document type and put names against every missing field. Second, validate and cleanse customer master data starting with the top 200 accounts by invoicing volume: TRN, TIN, registration type, address. Third, decide your integration pattern and start the mapper, not the paperwork.

This is the same class of work as the data foundation projects we take on in digital transformation: systems connected, master data governed, finance processes instrumented. Azrty is a UAE company based in Dubai. Our own team in the UAE does the consulting, the deployment and the support for our clients. The mandate is the forcing function; the ERP and data cleanup it demands is the part that keeps paying back after 1 January 2027. The ASP will carry your invoices. Your ERP has to make them worth carrying.

https://www.azrty.com/blog/uae-e-invoicing-erp-integration-pint-ae-5-corner-model

<a href="https://www.azrty.com/blog/uae-e-invoicing-erp-integration-pint-ae-5-corner-model">UAE e-invoicing ERP integration: PINT AE 5-corner model</a> (Azrty)