- HOME
- Taxes & compliance
- UAE eInvoicing ERP integration: how to map master data to PINT AE fields
UAE eInvoicing ERP integration: how to map master data to PINT AE fields
Under UAE eInvoicing, your accounting system or enterprise resource planning (ERP) system creates the invoice data, and an Accredited Service Provider (ASP) validates it, converts it to the UAE format and sends it on. On 23 February 2026, the Ministry of Finance (MoF) published guidance listing the fields every eInvoice must contain. A standard Tax Invoice needs 51 mandatory fields.
That guidance tells you what a compliant eInvoice must contain. It does not tell you whether your own system holds that data correctly. This guide helps you answer that question. It maps the mandatory fields to the master data a typical ERP already keeps, so you find the gaps in an internal check, not when your ASP rejects a real invoice.
One point up front: an ASP does not fix your data. It validates and formats what your system sends. It will not add a missing Tax Registration Number (TRN) to a customer record or correct a wrong tax code on an item. Master data quality is your responsibility, whichever ASP you choose.
What does ERP integration mean for UAE eInvoicing?
Every in-scope invoice passes through five parties, called corners. Your system creates the invoice data at Corner 1. Your ASP validates and converts it at Corner 2, and sends it to the buyer's ASP at Corner 3. The buyer's system receives it at Corner 4. The Federal Tax Authority (FTA), at Corner 5, receives tax data from both ASPs. For a full walkthrough, see how the 5-corner model works.
Corners 2 and 3 belong to the ASPs. Corners 1 and 4 are the systems that create and receive invoices, which for most businesses means the ERP or accounting software.
So ERP integration has two parts:
• The connection: how your system sends data to your ASP and receives confirmations back. ASPs usually document this, and it is often the easier part.
• The data: whether the invoice data is complete and correct before it leaves your system. This depends on your own master data, not on your ASP.
A perfect connection still produces a rejected invoice if the customer record behind it has no TRN.
How can you connect your ERP to an ASP?
There are three common ways to connect. The right one depends mostly on what your system can already produce.
Option | How it works | When it fits |
Direct API integration | Your system sends each invoice straight to the ASP's application programming interface (API) as it is created | Your system can already produce complete, structured invoice data, and you can do development work in it |
Middleware | A separate layer sits between your system and the ASP and reshapes the data into the required structure | You run an older system, or several systems feed one ASP connection |
Ready-made connector | An extension from your ASP or your ERP vendor that already maps standard fields | You want less custom development and can accept less flexibility |
Ask your ERP vendor or implementation partner whether it offers a UAE eInvoicing module or connector for your version. Whichever option you choose, it will send whatever your master data contains. A well-built connection sends a wrong TRN just as reliably as a poor one.
For a comparison of connecting an existing ERP, using a separate ASP portal or moving to accounting software with eInvoicing built in, see ASP vs ERP vs integrated accounting software.
What fields must a UAE eInvoice contain?
The MoF's mandatory fields guidance, dated 23 February 2026, sets out two lists:
• A Tax Invoice needs 51 mandatory fields.
• A Commercial Invoice needs 49. This is the invoice used for sales that do not need a Tax Invoice under VAT law, such as exempt or out-of-scope supplies, or sales by a business that is not VAT registered.
The two lists share almost every field. Both group their fields into the same six categories:
Category | Number of fields | Examples |
Invoice details | 9 | Invoice number, issue date, invoice type code, currency |
Seller details | 11 | Seller's legal name, tax identifier, address |
Buyer details | 9 | Buyer's name, identifier, address |
Document totals | 5 | Totals before and after tax, amount payable |
Tax breakdown | 4 | Tax category and rate, tax amount |
Invoice line | 13 on a Tax Invoice, 11 on a Commercial Invoice | Item description, quantity, price, tax category |
Three categories cause most problems: buyer details, tax breakdown and invoice lines. They depend on customer, tax code and item records that many people change over many years. The other three are mostly set up once during implementation, or calculated automatically once your tax setup is right.
How do the mandatory fields map to your master data?
The PINT AE specification uses Peppol's own codes for these fields. An Invoice Business Term (IBT) is a single field, such as the invoice number. An Invoice Business Group (IBG) is a set of related fields, such as all the seller details. A developer working from the specification sees codes like IBT-001 or IBG-04. This table links the codes to the records in your system.
Category | PINT AE reference | Where the data usually comes from | What to check |
Invoice details | IBT-001 invoice number, IBT-002 issue date, IBT-003 invoice type code, IBT-005 currency code | Document numbering and currency settings | Numbers are sequential with no gaps; currency codes are current |
Seller details | IBG-04 Seller, IBT-031 seller tax identifier | Your own company profile | Your TRN, TIN and legal details are correct and up to date |
Buyer details | IBG-07 Buyer | Customer records, and supplier records for self-billing | Every active customer has a current TRN where it has one, and full legal details, not just a name and address |
Document totals | IBG-22 Document totals, IBT-115 amount payable | Tax calculation settings | Your tax rules produce the exact line and total amounts the format expects |
Tax breakdown | IBG-23 VAT breakdown | Tax code settings | Every tax code maps to one of the UAE's six tax categories |
Invoice line | IBG-25 Invoice line, IBT-131 line amount | Item or service records | Every item has the correct tax category, not a default one |
A few details matter for the mapping:
• Tax identifiers. Your Participant Identifier on the Peppol network is scheme 0235 followed by your 10-digit Tax Identification Number (TIN). The TIN is the first 10 digits of a TRN from any FTA tax registration. The tax identifier field on the invoice itself carries the TRN where the business has one.
• Tax categories. Section 10.5 of the UAE Electronic Invoicing Guidelines, version 1.1 lists six: standard rate, exempt, outside the scope of VAT, reverse charge, zero rated and margin scheme.
• Invoice type code. IBT-003 tells the receiving system what kind of document it is: 380 for a Tax Invoice, 381 for a Tax Credit Note, 480 for a Commercial Invoice, 81 for its credit note, and 389 and 261 for the self-billed versions. A wrong code sends an otherwise correct invoice down the wrong validation path.
• Differences between the two lists. A few fields have slightly different names on the Commercial Invoice list, because that list must also cover sellers with no TRN. Two line-level fields, the VAT amount and line amount in AED, appear only on the Tax Invoice list.
For the full field list and an example, see the UAE eInvoice format guide.
What does a master data gap look like in practice?
Take a customer record created years ago, when a distributor started trading with a new buyer. It holds a trading name and a delivery address. That was enough for a person to read a PDF invoice. It is not enough for an eInvoice.
Field | What the old record shows | What an eInvoice needs |
Legal name | "Gulf Star Trading", a trading name | The full legal name, exactly as on the customer's trade licence |
Tax identifier | Blank, or a TRN from before a restructuring | The customer's current TRN, where it has one |
Line tax category | One default VAT code on every line | The correct tax category for each line, such as standard rate, zero rated, exempt or outside the scope of VAT |
None of these gaps shows up on a PDF that a person approves by eye. All of them show up when the same data reaches automated validation. That is why this check belongs before go-live.
Where does ERP integration usually go wrong?
These are data and process gaps, not broken connections. They appear once real invoices start moving.
• Missing or old TRNs on customer records, usually for long-standing customers set up before eInvoicing.
• Default tax codes on items instead of the category that actually applies.
• Currency or unit codes in your system that do not match the code lists PINT AE uses.
• Legal name mismatches between the trade licence and your system, often after a rebrand or change of ownership.
• The same customer or item set up differently in two systems, when separate entities each feed their own ASP connection. One system then sends a valid invoice and the other a rejected one.
• A mapping built on an older version of PINT AE. The specification has already been updated more than once. Check your mapping against the current version on the Peppol site, and name someone to watch for updates.
The first four are data fixes. The last two need an owner, because they will come back without one. For who should own what, see UAE eInvoicing roles and responsibilities.
What should an ERP master data checklist include?
Use this as a starting checklist:
• Customer records: a current TRN for every active customer that has one; legal name matching the trade licence; full billing address.
• Supplier records: the same checks, for self-billing and purchase scenarios.
• Item records: every item or service has an explicit tax category, not a default.
• Company profile: your own TRN, TIN and legal details are correct.
• Currency and unit codes: checked against the code lists your ASP and PINT AE expect.
• Field mapping: built on the current PINT AE version, with a named owner for future updates.
You can start this check now, before you choose an ASP. Finishing it first makes it much more likely that your first live invoices go through without rejections. For the wider preparation steps, see the UAE eInvoicing readiness and implementation guide.
Zoho Software Trading LLC is a Ministry of Finance-accredited eInvoicing service provider for the UAE, with accreditation number 121988, as shown on the MoF register of accredited service providers.
Explore UAE eInvoicing with Zoho Books
Frequently asked questions
Do you need to replace your ERP to comply with UAE eInvoicing?
Usually not. Most established systems can produce the required fields once the master data is correct and the system can connect to an ASP, directly or through middleware. The work that is almost always needed is cleaning up and maintaining the master data.
Which master data causes the most eInvoice rejections?
Customer records and item tax categories. Seller details and invoice settings are usually set up once and rarely change. Review customer TRNs and item tax codes first.
Does an ASP check or fix your master data?
No. An ASP validates and formats the invoice data it receives. It does not correct your customer, item or tax records. A data problem on your side produces a rejected invoice whichever ASP you use.
Do currency and unit codes need to follow a standard?
Yes. PINT AE uses standard code lists for values such as currency and unit of measure. Map your system's internal codes to those lists and test them before go-live.
Related guides
• UAE eInvoice format: PINT AE mandatory fields and XML structure
• ASP vs ERP vs integrated accounting software for UAE eInvoicing
• UAE eInvoicing roles and responsibilities
• UAE eInvoicing standards: Peppol, PINT AE, access points and CTC