Most compliance guides stop at "you need 51 mandatory fields." That's the easy part. The hard part is knowing which fields those are, where they come from in your ERP, and what happens when one is missing. Under UAE Federal Decree-Laws 16 and 17 of 2024, every B2B and B2G invoice must conform to PINT AE, the country-specific extension of the Peppol International standard. The UAE Ministry of Finance published version 1.1 of the Electronic Invoicing Guidelines in June 2026, specifying 51 mandatory fields drawn from a library of 130+ total across 16 invoice scenarios.
Miss a mandatory field and your invoice fails validation at your Accredited Service Provider (ASP). It doesn't reach your buyer. It doesn't reach the FTA. And if the problem persists, the penalty is AED 5,000 per month under Cabinet Decision 106 of 2025. That's not a theoretical risk for businesses going live in January 2027.
This guide breaks down every mandatory field category, explains the 16 invoice scenarios, walks through the UBL 2.1 XML structure, and tells you what your finance and ERP teams need to configure before go-live. For the broad mandate overview, start with the UAE e-invoicing complete guide.
Key Takeaways- PINT AE specifies 51 mandatory fields from a total library of 130+, across 16 defined invoice scenarios (UAE Ministry of Finance, "Electronic Invoicing Guidelines V1.1", 2026).- Fields span five categories: invoice header, seller and buyer identification, line-item details, tax totals, and payment and delivery terms.- Buyer TRN is mandatory for all B2B invoices. If your customer master data doesn't carry TRN consistently, that's your first fix.- The Peppol Participant Identifier format is: country code 0235 followed by the 10-digit TIN of the person or entity.- Phase 1 businesses (revenue at or above AED 50M) must appoint an ASP by 30 October 2026 and go live by 1 January 2027.
---
What Is PINT AE and How Does It Relate to UBL 2.1?
In 2026, the UAE Ministry of Finance published the Electronic Invoicing Guidelines V1.1, confirming that PINT AE contains 51 mandatory fields from a 130+ field library, built on the UBL 2.1 XML schema (UAE Ministry of Finance, "Electronic Invoicing Guidelines V1.1", 2026). PINT AE is the UAE-specific profile of the Peppol PINT standard, the same underlying architecture used in Singapore, Australia, and across Europe, configured for UAE VAT rules and FTA reporting requirements.
UBL 2.1 (Universal Business Language version 2.1) is the XML syntax PINT AE uses. Think of it as the grammar. PINT AE is the vocabulary. Your ERP must produce a structured XML document that follows UBL 2.1 syntax and populates every mandatory PINT AE field correctly. A PDF invoice, even a digitally signed one, doesn't qualify.
Why does this matter practically? Your ASP validates every invoice against the PINT AE schema before transmitting it. If a mandatory field is absent, incorrectly coded, or in the wrong format, the ASP rejects the invoice and returns an error code. You fix the data and resubmit. There's no silent pass-through on the Peppol network.
For a detailed explanation of how the Peppol network routes your invoice through all five corners, read the Peppol network guide.
---
What Are the 51 Mandatory PINT AE Fields? (By Category)
The 51 mandatory fields aren't distributed evenly. They cluster into five functional groups, each mapping to a part of your ERP data model. The table below gives every group, its mandatory field count, and representative fields so your ERP team knows what to look for.
| Field Group | Mandatory Fields | Example Fields |
|---|---|---|
| Invoice Header | 12 | Invoice ID, issue date, due date, invoice type code, currency code, document reference |
| Seller and Buyer Identification | 10 | Supplier TRN, supplier legal name, supplier address, buyer TRN (B2B), buyer legal name, Peppol Participant IDs |
| Line-Item Details | 12 | Item name, invoiced quantity, unit of measure, line extension amount, VAT category code, item description |
| Tax Totals | 9 | Tax amount, taxable amount per VAT category, VAT rate, total line extension amount, invoice total with VAT |
| Payment and Delivery Terms | 8 | Payment means code, payment ID, payment due date, delivery date, delivery location |
Total mandatory fields: 51. Total available fields: 130+. The remaining fields are conditional or optional, triggered by specific invoice scenarios or transaction types.
Here's something worth noticing about this distribution. The invoice header and line-item groups each carry 12 mandatory fields, but they create very different remediation challenges. Header fields are almost always in your ERP already. It's the format and coding standards that need alignment. Line-item fields are often partially present, but VAT category codes in particular need systematic mapping from your internal tax codes to the EN 16931 code lists that PINT AE inherits from its European Peppol parent standard.
---
What Does Each Mandatory Field Category Require?
Invoice Header Fields (12 Mandatory)
In 2026, the UAE MoF confirmed that every PINT AE invoice must carry a unique, sequential invoice identifier, the issue date in ISO 8601 format (YYYY-MM-DD), the due date, an invoice type code from the PINT AE code list, and the document currency code (UAE Ministry of Finance, Electronic Invoicing Guidelines V1.1, 2026). These 12 header fields establish the legal identity of the invoice.
The invoice ID field is often overlooked in planning. The FTA requires invoice numbers to be unique and sequential across your entire business, not just within a single ERP system. If you run multiple ERPs, multiple subsidiaries, or multiple billing systems, you need a centralised invoice numbering sequence or a clear partitioning scheme that prevents duplicate IDs across the combined output.
The invoice type code field matters more than it sounds. PINT AE uses a specific code list to distinguish a standard tax invoice from a credit note, a debit note, a self-billed invoice, and other document types. Your ERP's internal document type codes likely don't match these codes directly. The mapping needs to happen at the integration layer before the document hits your ASP.
Seller and Buyer Identification Fields (10 Mandatory)
In 2026, KPMG confirmed that supplier TRN, supplier legal name, and buyer TRN are all mandatory for B2B invoices under the PINT AE specification (KPMG, "UAE: Technical Guidance on Mandatory E-Invoicing Fields", February 2026). This is where most UAE businesses hit their first data quality problem.
The Peppol Participant Identifier is a specific format: the country code 0235, followed by the 10-digit Tax Identification Number (TIN) of the supplier or buyer. This isn't the same as the Tax Registration Number (TRN), though the two are related. Your Peppol ID is registered through your ASP when you join the Peppol network. Your buyer's Peppol ID must also be in the Peppol directory for the invoice to route correctly.
What does the seller address requirement mean in practice? The UAE PINT AE specification requires structured address fields: street name, city name, country code, and postal code as separate elements. A single unstructured "address" field in your ERP master data doesn't satisfy this requirement. Address data that works fine for printing on a PDF often isn't structured enough for PINT AE.
Finance teams that have run B2B e-invoicing mandates elsewhere consistently report the same finding: buyer TRN data quality in the customer master is the single biggest blocker. Businesses assume their CRM or ERP holds TRNs for all B2B customers. In reality, TRN fields are often blank for smaller customers, populated with incorrect values from historical data entry, or formatted inconsistently across systems. Running a TRN data audit on your customer master before integration testing saves weeks.
Line-Item Detail Fields (12 Mandatory per Line)
In 2026, the OpenPeppol PINT AE specification confirmed that each invoice line requires 12 mandatory fields including item name, invoiced quantity with unit of measure code, net unit price, line extension amount, and the VAT category code (OpenPeppol, "PINT AE Specification", 2025). The VAT category code field is where multi-scenario businesses face the most complexity.
UAE VAT applies at a standard 5% rate on most supplies. But your invoice lines might include zero-rated exports, exempt supplies, supplies outside scope, or reverse-charge transactions. Each category has a distinct code in the PINT AE-inherited EN 16931 code list: S (standard rate), Z (zero rate), E (exempt), O (outside scope). Your ERP's tax codes must map to these codes, and that mapping needs to be validated against actual transaction types, not assumed.
The unit of measure code field catches many businesses off guard. PINT AE uses the UN/ECE Recommendation 20 code list for units of measure. "Hours," "pieces," "kilograms" must be expressed as UN/ECE codes (HUR, C62, KGM), not as free text. If your ERP uses internal unit codes, those need to be mapped to the standard list.
Tax Total Fields (9 Mandatory)
The nine tax total fields cover the VAT calculation summary at the invoice level. The UAE Ministry of Finance specifies that every PINT AE invoice must carry the total taxable amount per VAT category, the total VAT amount, and the invoice total with VAT, among others (UAE Ministry of Finance, Electronic Invoicing Guidelines V1.1, 2026). For a single-rate invoice, this is straightforward. For invoices mixing standard-rated and zero-rated lines, each VAT category needs a separate tax total subtotal.
The rounding rules matter. PINT AE requires amounts to be consistent: the sum of line extension amounts must equal the invoice total before VAT, and the declared VAT amount must equal the taxable amount multiplied by the applicable rate. Rounding discrepancies that don't appear on a PDF invoice become validation errors in UBL 2.1.
Payment and Delivery Fields (8 Mandatory)
These eight fields cover how and when payment is expected, plus delivery location details where applicable. The payment means code field uses the UN/EDIFACT UNCL4461 code list: credit transfer (code 30), direct debit (49), card payment (54). Your standard payment terms text doesn't satisfy this field; you need the coded value.
In practice, payment and delivery fields cause fewer validation errors than identity and line-item fields, but they cause more business process discussions. "Payment due date" seems obvious until you realise that a business with dynamic payment terms (early payment discounts, milestone-based billing, disputed invoice holds) needs to decide which date to populate and how to handle exceptions systematically before go-live, not case by case after the mandate is live.
---
What Are the 16 PINT AE Invoice Scenarios?
The UAE Ministry of Finance defines 16 distinct invoice scenarios in the PINT AE specification, each representing a combination of document type and transaction characteristic that triggers specific field and validation requirements (UAE Ministry of Finance, Electronic Invoicing Guidelines V1.1, 2026). Every invoice your ERP issues must fit into one of these scenarios.
The 16 scenarios fall into four main families:
Standard tax invoices. The most common: a B2B invoice for goods or services subject to UAE VAT at the standard 5% rate. Also includes B2G variants where the buyer is a government entity.
Simplified tax invoices. Issued in specific circumstances where a simplified format is permitted under UAE VAT law, typically for lower-value or retail-adjacent transactions where the buyer is not VAT-registered.
Credit notes and debit notes. Adjustments to prior invoices. Credit notes reverse or reduce a previous charge; debit notes increase it. Both must reference the original invoice ID in a document reference field. That reference is mandatory, not optional.
Cross-border and special scenarios. Invoices for zero-rated exports, supplies to free zones, reverse-charge transactions, and self-billed invoices (where the buyer issues the invoice on the supplier's behalf). Each has its own mandatory field set and VAT coding requirements.
Why does scenario identification matter? Your ASP applies scenario-specific validation rules. An invoice that doesn't declare its scenario correctly, or that populates fields inconsistent with its declared scenario, fails validation. You need to map every transaction type your business produces to one of the 16 scenarios before testing begins.
The UAE e-invoicing readiness checklist includes a dedicated step for scenario mapping. It's one of the 20 pre-go-live actions.
---
How Does the UBL 2.1 XML Structure Work?
PINT AE's technical structure is UBL 2.1, an OASIS international standard for electronic business documents. Your ERP or ASP must produce a valid UBL 2.1 XML document for every covered invoice (OpenPeppol, PINT AE Specification, 2025). You don't need to write XML by hand. But understanding the structure helps you understand why your data mapping project has to go beyond field names.
A UBL 2.1 invoice has a hierarchical structure. At the top level sit the invoice-level fields: the invoice ID, issue date, type code, and currency. Below that comes the seller party block (AccountingSupplierParty), then the buyer party block (AccountingCustomerParty). Then come the tax total blocks, the invoice monetary totals, and finally the invoice line items, one block per line.
Why does the hierarchy matter? Because the same data concept appears in different XML paths depending on context. Your supplier's TRN appears inside AccountingSupplierParty/Party/PartyTaxScheme/CompanyID. Your buyer's TRN appears in the equivalent AccountingCustomerParty path. The Peppol Participant IDs for both parties appear in a different element entirely: AccountingSupplierParty/Party/EndpointID and AccountingCustomerParty/Party/EndpointID, both with scheme ID "0235."
Your ASP converts your ERP data to this structure, but only if the data mapping tells it exactly which ERP field feeds which UBL 2.1 element. That mapping document is the core technical deliverable of your integration project. It's also the document that surfaces your data quality gaps most clearly, because it forces your team to specify exactly where each of the 51 mandatory values comes from.
---
Which Fields Cause the Most ERP Integration Problems?
The fields that look simplest on a specification sheet are often the ones that create the most integration effort. Buyer TRN is a single field. But populating it correctly for every customer requires a data remediation programme across your entire customer master. That's not a technical task; it's a data governance task.
There are four PINT AE fields that consistently create ERP integration problems across UAE businesses preparing for the mandate.
Buyer TRN (for B2B invoices). Required for all B2B transactions. Many businesses don't have TRN data stored consistently in their customer master records, especially for smaller or older customer relationships established before UAE VAT was introduced in 2018.
Peppol Participant Identifiers. Both seller and buyer Peppol IDs must be in the format 0235 + 10-digit TIN. Your ASP registers your Peppol ID when you onboard. But your buyer's Peppol ID must be resolvable in the Peppol directory. Buyers who haven't yet registered with an ASP won't have a Peppol ID, which creates a real-world chicken-and-egg problem for early movers.
VAT category codes on line items. The EN 16931 code list that PINT AE uses doesn't map intuitively to typical ERP tax codes. Businesses with complex supply types (exports, exempt supplies, and standard-rated supplies all on the same invoice) need explicit mapping logic at the line-item level.
Structured address fields. PINT AE requires separate XML elements for street, city, country code, and postal zone. Free-text address fields stored as a single string in your CRM or ERP don't split cleanly without transformation logic. The UAE doesn't have a national postal code standard equivalent to UK postcodes or US ZIP codes, which creates additional ambiguity about the PostalZone field.
Your ASP should be able to handle the technical transformation of these fields, but the underlying data quality is your responsibility. The UAE ASP selection guide explains what to look for when evaluating a provider's data mapping support.
---
What Does Your ERP Team Need to Configure Before Go-Live?
Phase 1 businesses (those with annual revenue at or above AED 50 million) must appoint their ASP by 30 October 2026 and go live on 1 January 2027, per Ministerial Decision No. 66 of 2026 (UAE Ministry of Finance, mof.gov.ae, 2026). That's a firm deadline. Phase 2 businesses (below AED 50 million) must appoint by 31 March 2027 and go live by 1 July 2027.
The ERP configuration work runs in parallel with the ASP integration project. Here's what the two workstreams look like in practice.
Workstream 1: Data Remediation. Before your ERP can produce valid PINT AE documents, your master data must meet PINT AE field requirements. That means: auditing customer TRN data and filling gaps, structuring address records into separate components, mapping internal document type codes to PINT AE invoice type codes, and mapping internal tax codes to EN 16931 VAT category codes.
Workstream 2: Technical Integration. Your ERP (or a middleware layer) must produce UBL 2.1 XML documents and transmit them to your ASP via API or SFTP. Your ASP provides the integration specification, the API endpoint, and the test environment. Your ERP team configures the output format, the transmission channel, and the error-handling workflow for rejected invoices. You then test every one of the 16 invoice scenarios that apply to your business.
What's the minimum viable test plan? Run at least one invoice through each scenario type your business produces, in the ASP's test environment, and confirm it passes validation before your go-live date. Most ASPs provide sandbox environments for this purpose. Use them.
What about the voluntary pilot? From 1 July 2026, businesses can submit live invoices on the Peppol network in a penalty-free pilot mode. Phase 1 businesses should use this window. Real invoices, real buyers, and real ASP validation against the live PINT AE schema will surface problems that your test environment may not catch.
For guidance specific to smaller businesses under AED 50M, the UAE e-invoicing SME guide covers Phase 2 obligations and what to prioritise first.
---
How Do You Validate Your PINT AE Invoice Before Submission?
Your ASP does the final validation. But waiting until submission to discover a mandatory field is missing wastes time and risks missing your go-live date. The UAE Ministry of Finance published the PINT AE schematron rules (the machine-readable validation logic) as part of the Electronic Invoicing Guidelines V1.1 (UAE Ministry of Finance, mof.gov.ae, 2026). Those rules are the same ones your ASP runs.
What is schematron validation? It's a set of assertions written in a standard language that checks whether an XML document conforms to business rules beyond simple schema validity. Not just "is this field present?" but "is this VAT amount consistent with the taxable amount times the declared rate?" and "does this credit note reference a valid prior invoice ID?"
Your ERP team can run schematron validation locally during development, before any invoice touches your ASP. OpenPeppol publishes the PINT AE schematron files alongside the specification (OpenPeppol, docs.peppol.eu, 2025). Running them in your test pipeline means you find problems at the source, not at the transmission point.
What are the most common schematron failures in PINT AE implementations? Four patterns appear repeatedly: VAT amount calculation inconsistencies (usually rounding), missing mandatory fields on credit notes (especially the prior invoice reference), incorrect invoice type codes (using a B2B code on a B2G transaction), and Peppol Participant Identifiers that don't resolve in the Peppol directory.
Fixing these during development is fast. Fixing them during go-live testing, with your ASP team waiting, is expensive. Build local validation into your ERP integration pipeline.
---
Frequently Asked Questions About PINT AE Data Fields
Frequently Asked Questions
What is the difference between PINT AE and the UAE e-invoicing mandate?
PINT AE is the technical data standard (51 mandatory fields, 130+ total, built on UBL 2.1 XML) that every compliant invoice must follow. The UAE e-invoicing mandate, established by Federal Decree-Laws 16 and 17 of 2024, is the legal requirement to issue invoices in this format via an approved ASP. PINT AE is how you comply; the mandate is why you must (UAE Ministry of Finance, Electronic Invoicing Guidelines V1.1, 2026).
Is buyer TRN really mandatory for all B2B invoices?
Yes. For B2B transactions, the buyer's Tax Registration Number (TRN) is a mandatory PINT AE field in the AccountingCustomerParty block. Without it, your ASP will reject the invoice before it reaches the Peppol network. For B2G transactions, the government entity's identifier is similarly required. B2C invoices are excluded from the e-invoicing scope entirely (UAE Ministry of Finance, Electronic Invoicing Guidelines V1.1, 2026).
What is the Peppol Participant Identifier format for the UAE?
The UAE Peppol Participant Identifier uses country code 0235 followed by the 10-digit Tax Identification Number (TIN) of the person or government entity. For example: 0235:1234567890. Your ASP registers your identifier when you onboard. Buyer identifiers must be resolvable in the Peppol SMP directory. Buyers who haven't yet connected to an ASP won't have a registered Peppol ID (UAE Ministry of Finance, Electronic Invoicing Guidelines V1.1, 2026).
What happens if my ERP generates an invoice that fails PINT AE validation?
Your ASP rejects the invoice before it enters the Peppol network and returns an error code identifying the failed field or business rule. You correct the data and resubmit. There's no automatic pass-through for invalid invoices. Persistent non-compliance after your mandatory go-live date carries a penalty of AED 5,000 per month under Cabinet Decision 106 of 2025. Build a clear error-handling workflow into your integration before go-live.
Do all 16 PINT AE invoice scenarios apply to every business?
No. The 16 scenarios cover the full range of document types and transaction characteristics: standard invoices, credit notes, debit notes, zero-rated exports, self-billed invoices, and more. Most businesses will use a subset of 4-8 scenarios regularly. You need to identify which scenarios apply to your transaction mix and test each one with your ASP before go-live (UAE Ministry of Finance, Electronic Invoicing Guidelines V1.1, 2026).
---
Sources
- UAE Ministry of Finance, "UAE Electronic Invoicing Guidelines V1.1," retrieved 2026-06-22, https://mof.gov.ae/en/resourcesAndBudget/Documents/UAE%20Electronic%20Invoicing%20Guidelines%20V1.1.pdf
- UAE Ministry of Finance, "E-Invoicing Initiative," retrieved 2026-06-22, https://mof.gov.ae/en/ourpoliciesandinitiatives/Pages/eInvoicing.aspx
- UAE Ministry of Finance, "Ministerial Decision No. 66 of 2026," retrieved 2026-06-22, https://mof.gov.ae/en/news/issuance-of-amendments-to-federal-decree-law-on-tax-procedures-and-federal-decree-law-on-value-added-tax-to-support-the-einvoicing-system/
- OpenPeppol, "PINT AE: Peppol International UAE Specification," retrieved 2026-06-22, https://docs.peppol.eu/poac/ae/
- KPMG, "UAE: Technical Guidance on Mandatory E-Invoicing Fields," retrieved 2026-06-22, https://kpmg.com/us/en/taxnewsflash/news/2026/02/uae-technical-guidance-mandatory-e-invoicing-fields.html
- Federal Decree-Law No. 16 of 2024 and Federal Decree-Law No. 17 of 2024 (UAE e-invoicing legal basis), retrieved 2026-06-22, https://tax.gov.ae/en/taxes/corporatetax.aspx
- Cabinet Decision No. 106 of 2025 (non-compliance penalty AED 5,000/month), retrieved 2026-06-22, https://mof.gov.ae/en/ourpoliciesandinitiatives/Pages/eInvoicing.aspx