A UAE trader sells to a customer in Dubai and ships the goods to that customer's contractor in Sharjah. Three parties are involved and the Electronic Invoice has a place for each. Section 12.2 of the Guidelines confirms that where billing is addressed to one party and delivery is directed to another, the TRN or TIN of the recipient of the goods can be provided in the Delivery to Party ID field within the Delivery Information section. Using it correctly depends on treating customer, beneficiary and delivery recipient as three separate determinations.
Three Parties, Three Fields
The customer is the Person who issued the purchase order or is the contracting party. That is the entity billed, the entity whose TRN drives the tax treatment, and the entity whose Participant Identifier routes the document to Corner 3.
The beneficiary is the person or entity that ultimately uses, consumes or owns what is being supplied. The Guidelines require beneficiary details where the customer is a Free Zone entity, and the population rules for that field are covered in the Free Zone scenario analysis.
The delivery recipient is the party that physically receives the goods, and this is where triangular arrangements land. The Delivery to Party ID field carries that party's TRN or TIN, so it operates as an identity field rather than an address field.
Why the Identifier Matters More Than the Address
Most ERP ship-to records carry a name, a street address and a contact. Very few carry a tax registration number, because nothing previously required one. The identifier makes the movement of goods traceable across two tax positions rather than one — a revenue authority reading the invoice can see that the supplier billed party A and delivered to party B, and can match that against party B's own records. An address alone supports no such match. For businesses that drop-ship, supply main contractors on behalf of subcontractors, or sell to a procurement entity while delivering to operating sites, this is the field that documents the arrangement.
An Available Field, and a Policy Decision
The Guidelines phrase constraint 12 permissively: the identifier can be provided. It is not framed as mandatory for triangular transactions, which leaves the enterprise with a policy decision rather than an instruction. The case for populating it is evidential — where a supply's treatment depends on where the goods went, a populated delivery party makes the position self-evidencing on the document the FTA reads first. The case for restraint is data quality, since a wrong TRN in the delivery section is a statement about a third party's tax affairs. Either way the answer belongs in policy, settled once and applied the same way by every billing run.
Mirroring, and the Individual Consumer Case
Constraint 26 addresses the opposite situation, where the ultimate beneficiary and the customer are the same. The Guidelines confirm that Beneficiary Name and Beneficiary ID can mirror the customer information, duplicating the customer details into the beneficiary fields. The stated reason is that this keeps the Electronic Invoice technically complete without implying that another party is involved.
Where the end customer is an individual consumer, the Guidelines allow the individual's name and available identification details to be used, or a note that no registered ID exists where none applies. That resolves a question which otherwise stalls consumer-adjacent billing configurations: an absent registration number is an acceptable state, provided the absence is stated rather than left blank by default.
The work these two constraints create sits in the customer master rather than the invoice template. Deciding which counterparty relationships involve a separate delivery party, and capturing that party's tax identifier during onboarding, is what makes the field populate consistently at issuance.