UAE Peppol Participant ID Explained: The 0235:TIN Format for NetSuite Businesses

Every UAE business that issues e-invoices through the Peppol network needs a Peppol participant ID before their Accredited Service Provider can route a single document. That identifier follows a specific format: 0235:TIN, where 0235 is the UAE Electronic Address Scheme code and TIN is the first 10 digits of your Tax Registration Number. Get that format wrong, and your ASP cannot register your endpoint, invoices cannot be addressed correctly, and your go-live stalls. This guide explains the exact construction rules, clarifies the widespread confusion over scheme codes, and shows where NetSuite stores and uses the participant ID during XML generation.

What Is a UAE Peppol Participant ID?

A Peppol participant ID is a network address, not an identifier printed on invoices. Its sole function is to tell the Peppol network where to deliver a document. Think of it as an email address for structured business documents: without a valid, registered address, the routing infrastructure has nowhere to send the invoice.

In the UAE implementation, every registered business on the Peppol network gets exactly one participant ID, structured as:

Using TRN 100012345600003 as an example, the TIN is 1000123456 and the resulting Peppol participant ID is 0235:1000123456. This ID is registered with the Peppol network through EmaraTax when you appoint an FTA-accredited ASP. It is also specified as Field 14 in the UAE mandatory fields specification, meaning it appears in every outbound PINT-AE/UBL 2.1 document your system generates.

Critically, the Peppol participant ID is not the same as the TRN that appears on your tax invoices, nor is it your VAT registration number. Those are separate identifiers used for FTA reporting and legal invoice display. The participant ID is purely a network routing identifier used by ASPs.

For a full picture of how this identifier fits into the broader compliance framework, the UAE FTA e-invoicing requirements document covers mandatory fields, document types, and timeline obligations in detail.

Why the Scheme Code Is 0235, Not 0216

A significant number of unofficial guides, vendor presentations, and early pilot documentation reference scheme code 0216. This is incorrect for UAE production implementations. The UAE Ministry of Finance Guidelines V1.0, published in February 2026, specifies 0235 as the Electronic Address Scheme code for the UAE.

Where did 0216 come from? It was used in some early documentation and test environments before the MoF finalised the UAE-specific Peppol scheme registration. Some third-party implementation guides picked up the old code and have not been updated. If your ASP or ERP vendor’s documentation references 0216, treat that as a red flag and confirm with the ASP directly.

The practical consequence of using 0216 in production: ASP registration will fail, or the endpoint will be registered under an incorrect scheme that other network participants cannot resolve. Your outbound invoices will reference an unresolvable address and either be rejected or undeliverable.

The scheme code 0235 is hardcoded. It does not vary by business size, entity type, emirate, or registration date. Every UAE entity on the Peppol network uses 0235 as the scheme component of their participant ID.

How to Derive Your TIN from Your TRN

The UAE Tax Registration Number issued by the FTA is 15 digits long. The TIN used in the Peppol participant ID is only the first 10 of those 15 digits. This truncation is by design: the MoF guidelines define TIN as a 10-digit subset of the TRN for network addressing purposes.

The derivation rule is straightforward:

1. Obtain your 15-digit TRN from your FTA registration certificate or EmaraTax account.
2. Take the leftmost 10 digits only.
3. Prepend the scheme code and colon: 0235:
4. Confirm the resulting string with your ASP before registration.

Example: TRN = 100012345600003, TIN = 1000123456, Peppol participant ID = 0235:1000123456.

There is no calculation or checksum involved. The last five digits of the TRN are simply not used in the participant ID. Do not pad, modify, or hash the TIN. Store it exactly as derived.

For buyer records, the same logic applies. If the buyer is a UAE-registered business on the Peppol network, their participant ID is constructed from the first 10 digits of their TRN using the same 0235 scheme. If the buyer is not yet registered or is outside the UAE, different predefined endpoints apply.

Predefined Endpoints for Unregistered and Export Buyers

Not every buyer your NetSuite system invoices will have a registered Peppol participant ID. The UAE e-invoicing framework accounts for this with two predefined endpoint values:

These are not real TINs. They are reserved values that signal to the ASP how to handle the document. When the buyer endpoint is 0235:9900000098, the ASP knows the buyer has not yet onboarded and applies the appropriate handling procedure defined by the FTA. When it is 0235:9900000099, the ASP handles the document as an export transaction.

In NetSuite, the integration layer must determine which endpoint to use based on the customer record. A customer flagged as export (or with a non-UAE country) maps to 9900000099. A UAE customer without a stored TIN maps to 9900000098. A UAE customer with a stored TIN gets their derived participant ID. This logic should be built into your customisation or handled by your ASP’s NetSuite connector.

Where the Peppol Participant ID Lives in NetSuite

NetSuite’s standard data model does not include a native field for Peppol participant IDs. The UAE e-invoicing integration requires custom fields added to two record types:

• Subsidiary record: Store the seller’s TIN (first 10 digits of the TRN) as a custom field, for example custrecord_uae_tin. The integration reads this field when populating Field 14 (seller electronic address) in the PINT-AE/UBL 2.1 XML.
• Customer record: Store the buyer’s TIN as a custom field. The integration reads this to construct the buyer’s participant ID or applies the predefined endpoint logic if the field is blank or the customer is flagged as export.

The integration script constructs the full participant ID at runtime by prepending 0235: to the stored TIN value. Storing only the 10-digit TIN (not the full formatted ID) keeps the field clean and avoids scheme-code mismatches if the MoF ever updates the standard.

The UAE e-invoicing integration guide for NetSuite covers the full field mapping between NetSuite records and the PINT-AE document structure, including all 50-plus mandatory and conditional fields beyond the participant ID.

One important note on field placement: the TIN field on the Subsidiary record should be accessible to the integration script without requiring admin access. Configure field-level access appropriately during your NetSuite setup phase.

ASP Onboarding and EmaraTax Registration

The Peppol participant ID does not become active until it is registered on the Peppol network. In the UAE, registration happens through EmaraTax by appointing an FTA-accredited ASP. The ASP then registers your endpoint on your behalf using the participant ID you provide.

The onboarding sequence is:

1. Confirm your TRN with the FTA and derive your TIN.
2. Construct your participant ID: 0235:[first 10 digits of TRN].
3. Log into EmaraTax and appoint an FTA-accredited ASP.
4. The ASP registers your participant ID on the Peppol network (this is a Corner 1 to Corner 2 configuration step).
5. The ASP provides confirmation that your endpoint is live and resolvable on the network.
6. Configure NetSuite with the ASP’s API credentials and endpoint details.

Do not attempt to register directly with Peppol Authority. UAE businesses register exclusively through the EmaraTax portal and their appointed ASP. The FTA maintains the list of accredited ASPs on its website.

Before completing ASP onboarding, review the UAE e-invoicing go-live checklist for NetSuite, which covers pre-launch validation steps including participant ID verification, test document exchange, and ASP connectivity checks.

How the DCTCE 5-Corner Model Uses Your Participant ID

The UAE Peppol network uses the DCTCE (Digital Commerce Through Continuous Electronic) 5-corner model. Understanding where your participant ID fits in that model clarifies why getting it right matters operationally, not just technically.

The five corners are:

When NetSuite (Corner 1) generates a PINT-AE invoice and submits it to your ASP (Corner 2), the ASP reads the buyer’s participant ID from Field 14 of the XML document. It queries the Peppol network to locate Corner 3 (the buyer’s ASP), then delivers the document. Without a valid, registered participant ID for both seller and buyer, Corners 2 and 3 cannot communicate.

The participant ID is also what makes the network structure supplier-agnostic: your buyer does not need to use the same ASP as you. As long as both participant IDs are registered on the Peppol network, documents route correctly between different ASPs.

For implementation specifics on connecting NetSuite to your ASP’s API, see the guide on how to integrate NetSuite with a UAE e-invoicing service provider, which covers authentication, payload structure, and error handling at each corner.

Getting the Peppol participant ID right is foundational to UAE e-invoicing compliance. A single digit error in the TIN, or the wrong scheme code, blocks ASP registration and prevents any document from routing correctly through the network. Verify your TRN with the FTA, derive the TIN precisely, confirm 0235 as the scheme code, and work with an accredited ASP to register the endpoint through EmaraTax before your go-live date. For NetSuite-specific NetSuite implementation and integration services, Aaxonix handles the full participant ID configuration, custom field setup, and ASP connectivity work as part of a structured UAE e-invoicing engagement.