UAE E-Invoicing Mandatory Fields: How They Map to NetSuite

The UAE Ministry of Finance published version 1.0 of its mandatory fields specification in February 2026. It defines exactly 51 fields that must appear in every electronic tax invoice submitted through the national e-invoicing network. If your NetSuite implementation is being scoped or retrofitted for compliance, this document is your primary reference. Read the UAE e-invoicing integration guide for NetSuite for the broader architecture picture, but this post focuses entirely on the fields: what each one is, where it comes from in NetSuite, and where NetSuite falls short natively.

Why the Field Mapping Matters Before You Build Anything

A common mistake in e-invoicing projects is treating the XML schema as something the integration layer “figures out at runtime.” That works until the first field that NetSuite does not store. The UAE specification includes several such fields. Discovering them during UAT rather than during design adds weeks to a project and often requires a second deployment of custom fields to production.

The better approach is to map all 51 fields to their NetSuite source before writing a single line of integration code. This lets you identify custom field requirements, data quality gaps, and hardcoded values up front. Check the UAE e-invoicing compliance deadlines for NetSuite businesses to understand how much runway you have to complete this work.

The 51 Mandatory Fields: Group by Group

The specification organises the 51 fields into six groups: Invoice Details, Seller Details, Buyer Details, Document Totals, Tax Breakdown, and Invoice Line fields. The line-level group applies per line, so an invoice with ten lines carries the Invoice Details fields once and the line fields ten times.

Invoice Details (Fields 1–9)

Field 5 is the first significant gap. NetSuite has no native field for an 8-bit binary string representing transaction type flags. The eight flags correspond to: Free Trade Zone, Deemed Supply, Margin Scheme, Summary Invoice, Continuous Supply, Disclosed Agent Billing, Supply through e-commerce, and Exports. Each flag is “1” if applicable and “0” if not. You need a custom field on the Invoice transaction record, populated either by the user or by scripted logic based on customer and item attributes.

Seller Details (Fields 10–20)

Buyer Details (Fields 21–29)

Document Totals and Tax Breakdown (Fields 30–38)

Tax category code (field 37) requires a mapping table. NetSuite tax codes need to be mapped to one of the six PINT-AE categories: Standard Rate, Exempt, Out of Scope, Reverse Charge, Zero Rated, or Margin Scheme. This mapping should be maintained as a custom list in NetSuite or a lookup table in the integration layer.

Invoice Line Fields (Fields 39–51)

Fields NetSuite Does Not Have Natively

Before building the integration, create the following custom fields in NetSuite. Without them, the integration layer has no source record to read from:

• Invoice transaction type code (field 5): Custom text field on the Invoice transaction record. Use a 8-character format with validation or a set of eight checkbox fields mapped to binary positions. The field must be populated per invoice, either manually or via a scripted rule.
• Invoice UUID (not in the 51 mandatory fields, but required): When you submit an invoice to the Accredited Service Provider (ASP), you receive a UUID back. Store this on the Invoice record via a custom field so you can reference the original submission. This is a post-submission field, populated by the integration callback.
• Seller TIN (field 11): The first 10 digits of the 15-digit TRN. Store on the Subsidiary record as a custom field. The Peppol endpoint ID is then assembled as “0235:” + TIN in the integration layer.
• Seller trade license number (field 13) and registration type (field 14): Custom fields on the Subsidiary record.
• Buyer TIN (field 22): Custom field on the Customer record. Required for all B2B electronic invoices to UAE-registered buyers.

The AED Conversion Requirement for Line Fields

Fields 48 and 49 are the most technically awkward requirement in the specification. The VAT line amount and total line amount must be expressed in AED on every invoice line, regardless of the invoice currency. If you invoice a customer in USD or EUR, the integration must convert each line’s amounts to AED at the exchange rate on the invoice date.

NetSuite stores the exchange rate on every foreign currency transaction. The integration layer should pull the exchange rate from the Invoice record and apply it to each line’s tax amount and net amount to produce the AED equivalents. Do not try to store these as persistent NetSuite fields on each line; calculate them at extraction time based on the invoice’s exchange rate.

This also means your integration needs to know the functional currency of the subsidiary is AED, so it knows which direction to convert. For subsidiaries whose base currency is already AED, no conversion is needed.

The Peppol Participant ID: What It Is and Where It Lives

The UAE e-invoicing network uses the Peppol framework for addressing. Every participant (seller and buyer) is identified by a Peppol Participant ID in the format: 0235:TIN.

The TIN is the first 10 digits of the 15-digit TRN. For example, if the TRN is 100000000000003, the TIN is 1000000000, and the Peppol endpoint ID is 0235:1000000000. The scheme code “0235” is the UAE-specific Peppol issuing agency code and is always hardcoded.

In NetSuite terms: store the TIN (10 digits) as a custom field on the Subsidiary record (for your company) and on the Customer record (for buyers). The integration layer then concatenates “0235:” + TIN to form the Peppol Participant ID for the XML. Never store the full Peppol ID as a field; the “0235:” prefix is always a constant.

For guidance on how the full submission process works, see how to integrate NetSuite with a UAE e-invoicing service provider, which covers the ASP connection, submission flow, and error handling.

What to Harden in Your Integration Layer

Several values in the specification are always fixed. Rather than adding NetSuite custom fields for them, hardcode them directly in the XML generation code and document that decision clearly:

• Specification identifier: always urn:peppol:pint:billing-1@ae-1
• Business process type: always urn:peppol:bis:billing
• Seller electronic identifier (scheme code): always 0235
• Buyer electronic identifier (scheme code): always 0235
• Seller tax scheme code: always VAT
• Buyer tax scheme code: always VAT

These six values never vary by transaction or customer. Keeping them as code constants rather than database fields eliminates an entire class of data quality issues where someone accidentally blanks out the field or enters the wrong value.

For the unit of measure codes (field 41), maintain a mapping table between NetSuite unit types and UN/ECE Recommendation 20 codes. NetSuite’s default unit names (“Each”, “Hour”, “Kilogram”) will not match the required codes (“EA”, “HUR”, “KGM”). A lookup table in the integration is the cleanest approach.

Use the UAE e-invoicing go-live checklist for NetSuite to verify all custom fields are created, populated, and tested before your compliance date.

Getting the field mapping right at the design stage is the difference between a smooth go-live and an expensive rework cycle. The 51 mandatory fields in the UAE specification are clearly defined; what matters is knowing which ones NetSuite covers natively, which require custom fields, and which should be hardcoded constants in your integration. Build that inventory first, then write the code. For a complete view of your implementation scope, see NetSuite implementation and integration services from Aaxonix.