MINSEONG.com
MINSEONG / GUIDES

UAE eInvoicing Participant Identifiers and buyer endpoints: 0235 + TIN, Tax Group members, and buyers without an identifier

Published · Official sources last reviewed 22 October 2026; MoF Guidelines V1.1 read 24 October 2026 · 10 min read

Under the UAE eInvoicing model, an invoice is not emailed to a person. It is sent over the Peppol network from your Accredited Service Provider (ASP) to your buyer’s ASP, and it needs a machine-readable address to get there. Before you issue an eInvoice, you therefore need to know where it is going: the buyer’s Participant Identifier, or one of the predefined endpoints the Ministry of Finance (MoF) has set aside for buyers that do not have one. This guide explains how those identifiers are built, how Tax Group members are treated, which special endpoints exist and how to keep the information in your customer records.

The facts below come from the MoF’s UAE Electronic Invoicing Guidelines, Version 1.1 dated 01 June 2026, read on 24 October 2026, and the MoF eInvoicing programme page. Where a technical detail is not settled by those sources, we mark it as unconfirmed rather than guess. For the wider exchange model, read our guide to the 5-corner model and the PINT AE data standard first.

1. Why the receiving address matters

The Guidelines describe a five-corner model: the supplier (corner 1), the supplier’s ASP (corner 2), the buyer’s ASP (corner 3), the buyer (corner 4) and the Federal Tax Authority (FTA, corner 5). The two ASPs exchange the invoice over Peppol, an international framework for exchanging electronic business documents maintained by OpenPeppol. For that exchange to work, each business on the network is known by an identifier, and the sending side has to state which identifier the invoice is addressed to.

The Guidelines split the work between you and your ASP. According to the responsibility table, the ASP looks up the buyer’s Peppol participant identifier and generates the unique identifier (UUID) for each invoice, while the business is responsible for collecting its buyers’ participant identifiers so that it can invoice them. In other words, your ASP routes the document, but knowing who your customer is, and holding the right identifier for them, stays with you. A footnote to the same table confirms the general point: ASPs carry out exchange and reporting in practice, but the compliance obligation remains with the supplier (or the buyer, for self-billing).

2. How a Participant Identifier is built

The Guidelines define the Participant Identifier as “0235” followed by the business’s 10-digit Tax Identification Number (TIN). Section 2 of the Guidelines explains that the TIN is the first 10 digits of the business’s Tax Registration Number (TRN). Put together, the logic is simple:

  • Start with the TRN shown on the buyer’s VAT registration.
  • Take its first 10 digits. That is the TIN.
  • Prefix it with 0235. That is the Participant Identifier.

What we have not confirmed about the format

The predefined endpoints described below are written in the Guidelines with a colon, for example 0235:9900000098. We have not confirmed exactly how a buyer’s own identifier must be written in the XML, which PINT-AE element and scheme attribute carry it, or what validation the ASPs apply to it. Those details belong to the PINT-AE specification, its Data Dictionary and your ASP’s documentation. Do not hard-code a format from this guide; take it from your ASP.

Your own identifier

Appendix 3 of the Guidelines lists, among the ASP’s roles, onboarding you to the Peppol network and providing your Participant Identifier. Once you have it, share it with your suppliers in the same way you will collect identifiers from your customers. Our trading partner onboarding guide covers how to run that exchange of information with customers and suppliers.

3. Tax Group members use their own TRN

A common mistake is to treat a VAT Tax Group as a single address. The Guidelines say that members of a Tax Group use their own TRN, not the representative member’s TRN, when the TIN is derived. Each member therefore has its own Participant Identifier, and an invoice to a member should be addressed to that member, not to the group representative.

Appendix 1 of the Guidelines also notes that members of the same Tax Group may onboard with different ASPs. You cannot assume that two group companies sit behind the same provider. The Guidelines further ask businesses to keep their details current in EmaraTax and with their ASP, giving joining or leaving a Tax Group as an example, so a change in group membership is a trigger to check your own records and to tell your trading partners.

Whether a particular transaction between members of the same Tax Group is within the system at all is a separate question. It is covered in our Tax Group exclusion guide; this guide only deals with addressing.

4. One ASP for sending and receiving

Section 6.1 of the Guidelines states that each in-scope Person must appoint only one ASP, covering both sending and receiving Electronic Invoices. For addressing, that means each business, and each Tax Group member, should have one Participant Identifier reachable through one ASP. You should not ask customers to send to one provider while you issue through another.

ASPs are accredited by the Ministry. The Guidelines V1.1 still refer to Ministerial Decision 64/2025 for accreditation, but that decision was repealed and replaced by Ministerial Decision No. 168 of 2026, in force from 1 October 2026. The MoF publishes a list of eInvoicing Accredited Service Providers, and our ASP accreditation guide explains the current rules.

5. Predefined endpoints when the buyer has no identifier

Not every buyer will have a Participant Identifier. The Guidelines specify three predefined endpoints for these situations:

  • 0235:9900000098 where the buyer does not have a Participant Identifier.
  • 0235:9900000099 for exports where the buyer does not have a Peppol ID.
  • 0235:9900000097 as the buyer address for deemed supplies.

How to read each case

Buyer without an identifier (…98). This covers a buyer that cannot be reached by a Participant Identifier. The Guidelines name the endpoint; they do not, in the parts we have read, explain how the buyer then receives the invoice or what else the supplier must do. Our 5-corner guide notes that the Guidelines mention a separate Tax Invoice may still be needed where a buyer has not yet implemented eInvoicing; confirm with your ASP and adviser how that applies to your customers.

Export buyer without a Peppol ID (…99). Peppol is international, and the MoF programme page notes that the standard allows exchange with businesses outside the UAE. A foreign buyer that is on Peppol is reached by its own Peppol identifier. Where a foreign buyer has no Peppol ID, this endpoint is used. We have not confirmed the identifier scheme to use for a foreign buyer that is on Peppol.

Deemed supply (…97). The Guidelines give a fixed buyer address for deemed supplies; in our reading, this is because such a supply may not have a separate buyer to address in the usual way, but the Guidelines’ reasoning is not something we have confirmed. Whether a transaction is a deemed supply is a VAT question, not an addressing question; decide it under VAT rules before choosing this endpoint.

What remains unconfirmed

We have not verified how the FTA treats invoices sent to these endpoints, whether any additional buyer data must be included, which document types may use them, or how an invoice sent to …98 should be handled if the buyer later obtains an identifier. Ask your ASP to show you, in testing, exactly what happens when each endpoint is used.

6. Recording identifiers in your customer master data

The steps in this section are our editorial recommendation, not an official procedure. The Guidelines make the business responsible for collecting buyers’ identifiers; they do not prescribe how you store them. In our view, the cleanest approach is to make the receiving address a field on every customer record, so that it is decided once and reused rather than looked up invoice by invoice.

  1. Add identifier fields to the customer master: the TRN, the derived TIN, the Participant Identifier (or Peppol ID for foreign buyers) and an “endpoint type” value showing whether the record uses the buyer’s own identifier or one of the predefined endpoints.
  2. Derive, then confirm. Derive the TIN from the TRN, but confirm the resulting identifier with the customer or through your ASP rather than relying on the calculation alone.
  3. Record Tax Group members separately. One record per member, each with its own TRN and identifier, never the representative’s identifier copied across the group.
  4. Use predefined endpoints deliberately. Only assign …98, …99 or …97 where the condition in the Guidelines is met, and record why.
  5. Set change triggers. Re-check the record when a customer registers or deregisters for VAT, joins or leaves a Tax Group, or changes ASP.
  6. Block incomplete records from invoicing until the endpoint field is filled.

Our master data readiness guide explains how to inventory and clean counterparty records more generally, and the data mapping and system integration guide shows how to map those fields from your ERP to what your ASP expects. Note that the Guidelines say businesses may not add their own optional fields into PINT-AE itself; the fields above are internal master-data fields, not additions to the invoice standard.

7. Practical checklist

  • Confirm your own Participant Identifier with your ASP, and that you have appointed one ASP for both sending and receiving.
  • For each Tax Group member, confirm its own TRN, TIN, Participant Identifier and ASP.
  • Collect identifiers from your customers and share yours with your suppliers.
  • Add identifier and endpoint-type fields to your customer master data.
  • List customers with no identifier, export customers without a Peppol ID and any deemed-supply scenarios, and agree with your ASP how each is handled.
  • Get the current PINT-AE specification, Data Dictionary and the MoF mandatory-fields document (V1.0, 23 February 2026) for the exact field format.
  • Test invoices to a normal buyer, a Tax Group member and each predefined endpoint before go-live, using our go-live testing checklist.
  • Train your accounts receivable and accounts payable teams on who maintains identifiers.

8. Frequently asked questions

Is the Participant Identifier the same as the TRN?

No. According to the Guidelines it is 0235 followed by the TIN, and the TIN is the first 10 digits of the TRN.

Can I send every invoice for a Tax Group to the representative member?

No. The Guidelines say Tax Group members use their own TRN, so each member has its own identifier, and members may be onboarded with different ASPs.

Can I use two ASPs, one to send and one to receive?

No. Section 6.1 of the Guidelines requires one ASP covering both sending and receiving.

What if my customer simply has no identifier?

The Guidelines provide the endpoint 0235:9900000098 for a buyer without a Participant Identifier. How the buyer then receives the invoice, and any additional steps, are not something we have verified; agree them with your ASP.

Who is responsible if an invoice goes to the wrong address?

The Guidelines put the collection of buyer identifiers on the business and say the compliance obligation stays with the supplier. How the FTA would treat a misaddressed invoice is not something we have verified. The underlying duties are in Decision 243/2025 as amended by Decision 197/2026; see our Issuer and Recipient obligations guide.

9. What we have not verified

  • the exact XML element, scheme attribute and formatting used for a buyer’s Participant Identifier, and any validation rules;
  • how the FTA treats invoices sent to the predefined endpoints and whether extra buyer data is required;
  • the identifier scheme for foreign buyers that are on Peppol;
  • how buyers are found in any Peppol directory and what happens when a lookup fails;
  • what happens to an invoice already sent to 0235:9900000098 if the buyer later obtains an identifier;
  • whether the Guidelines V1.1 will be revised to reflect Decision 168/2026 and Decision 197/2026.

Important notice

This guide is general information prepared by MINSEONG.COM, an independent website. It is not legal, tax or technical advice and it is not an official government publication. It summarises official MoF material as read on the dates shown, and rules and specifications may change. The master-data steps are editorial recommendations. Always check the current Ministry of Finance and FTA publications, follow your ASP’s documentation and consult a qualified UAE tax adviser before making decisions. You can also run our free eInvoicing readiness check or browse all our guides.