Build1 publisher3 min readPublished
UAE Peppol e-invoicing makes Odoo's res.partner table a blocker on posted invoices
The UAE pilot opened on 1 July 2026 and Odoo ships no access point of its own, so the connector is the implementer's job. Ten of the 17 mandatory PINT AE fields are read from company and partner master data.
The Engineer · Build desk
What happened
- Since the pilot opened on 1 July 2026, every UAE VAT-registered business sending a B2B invoice has had to route it through the UAE Peppol network as PINT AE XML, according to a dev.to post by Perfonec Computers.
- Odoo ships no native UAE Peppol access point, so the transmission layer is added outside the ERP, through an Accredited Service Provider sitting at Corner 2 of the four-corner model.
- PINT AE, the UAE extension of Peppol BIS Billing 3.0, defines 17 mandatory fields that must pass schema validation before the provider will transmit the invoice.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Final validation moves to the service provider, so Odoo's own posting rules are no longer the last check an invoice faces before it counts as issued.
- cost New code is the smaller part of the job: most of the effort lands on the client's existing partner and company records, and that cleanup is billable time the implementer has to scope before quoting the connector.
- decision A team can buy an ASP module or write its own Corner 2 client, but either way it owns the tax-to-category and uom-to-UN/CEFACT translations, because the published mapping stops at the 17 BT fields.
- exposure Status comes back after the invoice is posted, so a rejection leaves a posted accounting entry with no transmitted counterpart unless the connector tracks that state separately.
The gate is Corner 2. The seller's Accredited Service Provider validates the invoice against the PINT AE schema, handles the Peppol transmission, and returns a status response [5]. Nothing reaches the buyer's ERP until that validation passes [9].
Count the published mapping by model and you can see where it will fail. Of the 17 mandatory fields, six are read from account.move, five from res.company, five from res.partner, and one from account.move.line [15][16]. Ten of seventeen come from master data. An invoice can be correct as an accounting document and still be refused at Corner 2 because the customer record has nothing in vat [21].
The right-hand side of the mapping is Odoo relational fields: currency_id, country_id, move_type [15]. The schema wants scalars. BT-5 is an ISO 4217 code and BT-2 is ISO 8601 as YYYY-MM-DD [12], BT-40 must be the literal string "AE" [14], and BT-3 is 380 for a standard invoice or 381 for a credit note [11]. Each of those is a lookup before serialization. Both TRN fields are 15 digits [13], a check the connector can run itself or learn about from the ASP's rejection.
Two requirements sit outside the mapping table. Every invoice line must carry one of four VAT category codes: S for the 5 percent standard rate, Z for zero-rated, E for exempt, O for out of scope [17]. Units of measure must use UN/CEFACT codes, and the post lists seven of them, including EA, KGM, HUR and DAY [18]. The mapping covers the 17 BT codes and stops there [19]. So the connector also carries a tax-to-category resolution and a uom-to-UN/CEFACT resolution.
According to the dev.to post by Perfonec Computers, the schema is not the hard part and data quality in existing Odoo databases is [20]. It names five failures that recur across UAE implementations, and both of the ones it details target res.partner [20][24]. The first is the missing buyer TRN, found by searching customers where vat is False and country_id.code is AE [21]; the suggested remedy is a bulk partner import plus a constrains check that requires vat when the partner is a UAE customer [22]. The second is the address held as a single string, "Office 401, Al Barsha 1, Dubai", where the schema requires street and city separately [23]. That is a perfectly good address and a failed BT-50.
For the mapping to transfer to your database, supplier data has to live where the table says it lives. BT-27 through BT-40 are read from res.company [15], so a database running several selling entities resolves those five fields for each company it sells from.
The pattern ends by writing the ASP status back to account.move [7]. The post does not describe retry or rejection handling. I would build that part first: the status arrives after the invoice is already posted, so the connector needs its own state field on account.move and a queue that can replay a POST without touching the accounting entry.
One note on provenance. The pilot date, the mandate and the field list come from the same post, which cites the UAE Ministry of Finance Electronic Invoicing Guidelines Version 1.1 of June 2026 [8]; the guideline document itself is not in the record here. On that account, every UAE VAT-registered business sending B2B invoices is already required to route them as PINT AE XML [2], and the pilot phase opened on 1 July 2026 [1].
What to watch
- A revision after Guidelines Version 1.1 that adds or renumbers mandatory fields would invalidate existing PINT AE mappings.
- If Odoo ships UAE Peppol support in a standard localization module, the Corner 2 connector build goes away and only the data cleanup remains.
- The end date of the pilot phase, and what enforcement looks like when it closes.