How a buyer is addressed
Every invoice carries an electronic address for the buyer, even when the buyer cannot be reached on the network — it is what identifies your customer to the authority. This page is every case the platform answers and the address each one produces. It is the same table the API documentation carries, because a connected ERP and the OAuth API resolve a buyer identically.
The one rule behind all of it
An address is two parts: the scheme — which registry issued the number — and the number itself. Everything below is the platform working both out from whatever your accounting system holds.
Where both can be determined, the buyer is addressed by its own identifier. Where they cannot, the invoice is still filed, under an FTA placeholder that says plainly there is no address to deliver to. Nothing is ever guessed — a wrong scheme is not a cosmetic error, it addresses a different company.
Every case
UAE buyer
| What your data holds | Address filed | Result |
|---|---|---|
Tax number (TRN) The first ten digits are the UAE TIN. This is the only truncation in the platform. | 0235:<first 10 digits> | filed |
A participant id, no scheme The scheme follows from the country. An id is already an address, so it is never truncated. | 0235:<id, verbatim> | filed |
No tax number at all The address is filled in and the invoice is still refused: a UAE buyer is required to carry its TRN. | 0235:9900000098 | refused |
Addressed under any scheme but 0235 A UAE buyer is identified in the FTA's own registry. Another scheme means the address was built against the wrong one. | — | refused |
Buyer outside the UAE — with something we can use
| What your data holds | Address filed | Result |
|---|---|---|
Participant id + scheme Used exactly as sent. Never truncated, and a scheme you state is never re-derived. | <scheme>:<id> | filed |
Participant id, no scheme The scheme is filled in from the country. State it yourself for a GLN, DUNS or LEI, which no country issues. | <country scheme>:<id> | filed |
Tax number, country publishes a VAT scheme Germany shown. The WHOLE number is used — the first-10 rule is UAE-only. | 9930:DE123456789 | filed |
Tax number, US / AU / JP / NG No VAT in any of the four, but each publishes exactly one scheme and it is the tax authority's own number: EIN, ABN, qualified-invoice issuer number, Tax ID. | 9959 · 0151 · 0221 · 0244 | filed |
Tax number, Estonia The one deliberate deviation: EE is live on the company code, which is what this platform is registered and sending with. | 0191:<first 8 digits> | filed |
Buyer outside the UAE — with nothing we can use
| What your data holds | Address filed | Result |
|---|---|---|
Tax number, DK SE NO FI SG MY IS Their published identity is a company-register or e-invoicing framework number, not a tax number. Nothing is guessed. | 0235:9900000099 | filed |
Tax number, country publishes nothing (BR) Same answer, for the same reason. | 0235:9900000099 | filed |
No identifier at all The export placeholder, whether or not the transaction type declares the export. | 0235:9900000099 | filed |
Identifier fields sent empty or null Blank is read as absent everywhere. An id is never emitted with an empty value under a scheme. | 0235:9900000099 | filed |
Refused, whatever else is on the invoice
| What your data holds | Address filed | Result |
|---|---|---|
Foreign buyer sent under 0235 0235 is the UAE's own scheme. A foreign buyer addressed with it cannot be delivered to. | — | refused |
A scheme that is not on the Peppol EAS list Checked against the published list, so a typo is caught here rather than by the buyer's access point. | — | refused |
Beats everything above
| What your data holds | Address filed | Result |
|---|---|---|
Deemed supply There is no customer to address, so this wins over a participant id on the payload and over the export flag. | 0235:9900000097 | filed |
A placeholder means no delivery, not no filing. The invoice reaches the authority and is reported like any other; what it does not do is arrive in the buyer's own system, because there is no address to send it to. The three are read differently: 9900000097 a deemed supply, 9900000099 an export whose buyer has no Peppol ID, and 9900000098 a domestic buyer who is not on the network — which is why an export never falls back to the domestic one.
To turn a placeholder into a delivery, supply the buyer's real participant id and scheme — the buyer_electronic_address and buyer_electronic_address_scheme fields on the PINT Mapping page, usually pointed at a custom field on the customer record. An identifier you supply is always used and is never replaced by a placeholder — including when it is wrong, which is why an unknown scheme is refused rather than quietly swapped.
Where this comes from in your data
The tax number is whichever field your system keeps it in — a custom field in QuickBooks, the contact's Tax Number in Xero, and so on; they are listed per system on ERP prerequisites. Fill it in for every customer and most of this table never applies to you: the buyer is addressed by its own identifier and the invoice is delivered as well as filed.