DEV Community: Perfonec Computers

Integrating UAE Peppol E-Invoicing with Odoo — What Developers and Implementers Need to Know

Perfonec Computers — Tue, 22 Sep 2026 07:34:28 +0000

UAE mandatory e-invoicing went live in pilot phase on 1 July 2026. Every UAE VAT-registered business sending B2B invoices must now route them through the UAE Peppol network as PINT AE XML. For Odoo developers and implementers working with UAE clients, this creates a specific integration challenge — Odoo does not ship with a native UAE Peppol access point. The transmission layer has to be added externally.

This post covers what the UAE Peppol infrastructure looks like technically, what PINT AE XML requires at the field level, how the Odoo data model maps to those fields, where data quality issues typically appear, and what a complete implementation involves from a developer perspective.

The UAE Peppol Network — Four-Corner Architecture

UAE e-invoicing uses the standard Peppol four-corner model:

Corner 1 — Seller ERP (Odoo)
Corner 2 — Seller ASP (Accredited Service Provider)
Corner 3 — Buyer ASP
Corner 4 — Buyer ERP

The ASP at Corner 2 is the developer integration point. It validates the invoice against the PINT AE schema, handles the Peppol transmission, and returns a status response. For Odoo, this means building or configuring a connector between the account.move model and the ASP API.

The standard integration pattern is:

account.move (state = posted)
→ intercept confirmation event
→ read invoice data from Odoo ORM
→ map to PINT AE fields
→ serialize to XML
→ POST to ASP API endpoint
→ receive status response
→ write status back to account.move
PINT AE XML — Schema and Mandatory Fields

PINT AE is the UAE's national extension of Peppol BIS Billing 3.0. It is defined under the UAE Ministry of Finance Electronic Invoicing Guidelines Version 1.1, published June 2026.

Every B2B invoice must pass schema validation before the ASP will transmit it. The 17 mandatory PINT AE fields and their BT codes are:

BT-1 Invoice number
BT-2 Invoice date (ISO 8601 — YYYY-MM-DD)
BT-3 Invoice type code
380 = standard invoice
381 = credit note
BT-5 Invoice currency code (ISO 4217)
BT-27 Supplier name
BT-29 Supplier TRN (15-digit UAE VAT number)
BT-35 Supplier street address
BT-37 Supplier city
BT-40 Supplier country code (must be "AE")
BT-44 Buyer name
BT-46 Buyer TRN (15-digit UAE VAT number)
BT-50 Buyer street address
BT-52 Buyer city
BT-55 Buyer country code
BT-110 Sum of invoice line net amounts
BT-112 Invoice total VAT amount
BT-131 Invoice line net amount (per line)

Every invoice line must also carry one of four PINT AE VAT category codes:

S Standard rate — 5% UAE VAT
Z Zero-rated — exports, certain food, international transport
E Exempt — bare land, residential property resale
O Out of scope — outside UAE territory, certain financial services

And every unit of measure must use UN/CEFACT codes:

EA Each (countable items)
KGM Kilogram
LTR Litre
MTR Metre
HUR Hour (services billed hourly)
DAY Day
MTK Square metre
Mapping PINT AE Fields to the Odoo Data Model

Here is the direct mapping from PINT AE BT codes to Odoo models and fields:

python

PINT AE → Odoo field mapping

PINT_AE_MAPPING = {
'BT-1': ('account.move', 'name'),
'BT-2': ('account.move', 'invoice_date'),
'BT-3': ('account.move', 'move_type'),
'BT-5': ('account.move', 'currency_id'),
'BT-27': ('res.company', 'name'),
'BT-29': ('res.company', 'vat'),
'BT-35': ('res.company', 'street'),
'BT-37': ('res.company', 'city'),
'BT-40': ('res.company', 'country_id'),
'BT-44': ('res.partner', 'name'),
'BT-46': ('res.partner', 'vat'),
'BT-50': ('res.partner', 'street'),
'BT-52': ('res.partner', 'city'),
'BT-55': ('res.partner', 'country_id'),
'BT-110': ('account.move', 'amount_untaxed'),
'BT-112': ('account.move', 'amount_tax'),
'BT-131': ('account.move.line', 'price_subtotal'),
}

Unit of measure maps through product_uom on account.move.line

to uom.uom — requires custom l10n_ae_uom_code field on uom.uom

VAT category code maps through tax_ids on account.move.line

to account.tax — requires custom l10n_ae_vat_type field on account.tax

The Most Common Data Quality Issues

In practice, the PINT AE schema is not the hard part. The hard part is data quality in existing Odoo databases. These are the five failures that appear most consistently across UAE Odoo implementations:

Issue 1 — BT-46 missing (buyer TRN)

python

Check for partners without TRN

partners_without_trn = env['res.partner'].search([
('customer_rank', '>', 0),
('vat', '=', False),
('country_id.code', '=', 'AE'),
])

Typical result: 20-40% of customer records

Fix: Bulk update via partner import, add a constrains check on res.partner to require vat when country_id = AE and customer_rank > 0.

Issue 2 — BT-50/BT-52 combined in one field

Many UAE Odoo accounts have the full address stored in street as a single string — "Office 401, Al Barsha 1, Dubai". PINT AE requires street and city as separate fields.

python

Identify affected partners

partners_with_combined_address = env['res.partner'].search([
('customer_rank', '>', 0),
('city', '=', False),
('street', '!=', False),
])

Fix: Write a migration script to split the address or use partner import with separate columns.

Issue 3 — Missing UN/CEFACT codes on uom.uom

Standard Odoo UoM records do not include UN/CEFACT codes. The PINT AE XML serialiser needs this to populate the unit code on each invoice line.

python

Add custom field to uom.uom

class UoM(models.Model):
_inherit = 'uom.uom'

l10n_ae_uom_code = fields.Char(
    string='UN/CEFACT Code',
    help='Required for UAE PINT AE e-invoicing'
)

Then populate via a data XML file:

xml

EA

KGM

Issue 4 — account.tax records without PINT AE category

python
class AccountTax(models.Model):
_inherit = 'account.tax'

l10n_ae_vat_type = fields.Selection([
    ('S', 'Standard Rate (5%)'),
    ('Z', 'Zero Rated'),
    ('E', 'Exempt'),
    ('O', 'Out of Scope'),
], string='PINT AE VAT Category')

Issue 5 — Fiscal position not assigned to customer records

UAE fiscal position must be set on res.partner for all UAE VAT-registered customers. Without it, tax lines will not carry the correct PINT AE category.

python

Bulk assign UAE fiscal position

uae_fiscal_pos = env['account.fiscal.position'].search([
('name', 'ilike', 'UAE')
], limit=1)

uae_partners = env['res.partner'].search([
('customer_rank', '>', 0),
('country_id.code', '=', 'AE'),
('property_account_position_id', '=', False),
])
uae_partners.write({
'property_account_position_id': uae_fiscal_pos.id
})
The ASP Integration — Request and Response Pattern

The ASP API call follows this pattern for most UAE FTA-approved ASPs:

python
import requests
import json

def submit_to_asp(invoice_xml: str, invoice_id: str) -> dict:
"""
Submit PINT AE XML to ASP endpoint.
Returns status dict with transmission result.
"""
headers = {
'Content-Type': 'application/xml',
'Authorization': f'Bearer {ASP_API_KEY}',
'X-Invoice-ID': invoice_id,
}

response = requests.post(
    url=ASP_ENDPOINT,
    data=invoice_xml.encode('utf-8'),
    headers=headers,
    timeout=30,
)

if response.status_code == 200:
    return {
        'status': 'sent',
        'peppol_id': response.json().get('peppolId'),
        'timestamp': response.json().get('sentAt'),
    }
elif response.status_code == 422:
    return {
        'status': 'rejected',
        'errors': response.json().get('validationErrors', []),
    }
else:
    response.raise_for_status()

The status response should be written back to account.move via a custom field and surfaced in the invoice chatter so the accounts team can see it without going to a separate dashboard.

Credit Notes — Type 381

Credit notes in PINT AE use document type code 381 and must reference the original invoice:

python
def get_invoice_type_code(move):
"""Map Odoo move_type to PINT AE BT-3 value."""
if move.move_type == 'out_invoice':
return '380'
elif move.move_type == 'out_refund':
return '381'
raise ValueError(f'Unexpected move_type: {move.move_type}')

def get_preceding_invoice_ref(move):
"""Get original invoice reference for credit notes (BT-25)."""
if move.move_type == 'out_refund' and move.reversed_entry_id:
return move.reversed_entry_id.name
return None
Testing Sequence for the Pilot Phase

The UAE e-invoicing pilot phase runs from 1 July 2026 with no financial penalties for validation failures. This is the right window to run a complete integration test. The recommended sequence:

Test 1 — Standard B2B invoice
All 17 BT fields populated
Tax line with category S

Test 2 — Zero-rated export invoice
BT-55 buyer country ≠ AE
Tax line with category Z

Test 3 — Credit note
move_type = out_refund
BT-3 = 381
BT-25 = original invoice name

Test 4 — Mixed-tax invoice
Lines with S and Z categories on same invoice

Test 5 — Free zone invoice
Custom beneficiary field populated for DMCC/JAFZA/IFZA/DIFC

Test 6 — Multi-currency invoice
currency_id ≠ AED
AED equivalent amounts included per Version 1.1

Test 7 — Advance payment invoice
Per UAE E-Invoicing Guidelines Version 1.1
Separate document flow from sale.order

Each test should be run against the ASP's sandbox Peppol endpoint — not a mock — to catch schema validation errors that local pre-validation may not catch.

Mandatory Deadlines for Implementers
Go-live (revenue AED 50M+): 1 January 2027
Fines begin (large biz): 2 January 2027
Go-live (all other SMEs): 1 July 2027
Fines begin (SMEs): 2 July 2027
Pilot phase (no penalties): From 1 July 2026 — open now

Penalty under Cabinet Decision No. 106 of 2025: AED 5,000/month for non-implementation. AED 100/non-compliant invoice capped at AED 5,000/month. Maximum combined: AED 10,000/month.

Summary

UAE Peppol e-invoicing for Odoo is a well-scoped integration problem. The PINT AE schema is clearly defined. The Odoo data model maps cleanly to the BT fields once the custom extensions are in place. The real work is data quality — specifically BT-46 (buyer TRN), address structure (BT-50/BT-52), UN/CEFACT unit codes, and fiscal position assignment.

A pre-validation step before the ASP call is worth implementing — it catches the most common data issues at confirmation time and reduces ASP API errors significantly.

The pilot phase is the right time to run the full test sequence. No penalties apply during pilot regardless of how many validation failures occur.

Based on UAE Ministry of Finance Electronic Invoicing Guidelines Version 1.1 (June 2026) and Peppol BIS Billing 3.0. For technical reference only — not legal advice.

Written by Akanksha Surana — Odoo Ready Partner with Odoo Middle East.

Zoho Books Is Now an FTA-Approved ASP — What This Means for UAE Businesses

Perfonec Computers — Thu, 17 Sep 2026 07:43:16 +0000

This is a significant update for every UAE business using Zoho Books.

Zoho Books has been approved by the UAE FTA as an Accredited Service Provider — or ASP — for UAE mandatory e-invoicing. As a result, UAE Peppol e-invoicing now works directly within Zoho Books. No external ASP subscription is needed anymore.

Disclosure: Perfonec Computers is the authorised Zoho Partner in UAE. We supply Zoho Books licences and handle UAE e-invoicing setup. This guide is written to inform UAE Zoho Books users about this update.

What Is an ASP and Why Does This Matter?

An ASP, or Accredited Service Provider, is an FTA-approved company that validates UAE invoices, converts them to PINT AE XML format, and sends them through the UAE Peppol network to the buyer.

Previously, Zoho Books did not have its own Peppol access point. Therefore, every UAE Zoho Books user needed to find, appoint, and pay for a separate external ASP subscription on top of their Zoho Books licence fee.

That has now changed. Zoho Books is the ASP. The direct Peppol connection is built into Zoho Books itself. Therefore, you no longer need a separate ASP at all.

What Changed — Before and After

Before this approval, UAE Zoho Books users needed two things — a Zoho Books licence and a separate external ASP subscription. The ASP had to be selected, appointed, and managed separately. Invoice data left Zoho Books to reach the ASP first before going to the Peppol network.

Now, everything happens inside Zoho Books. When you confirm a B2B invoice, Zoho Books creates the PINT AE XML directly, checks all 17 mandatory PINT AE fields, and sends the invoice through the UAE Peppol network on its own. As a result, there is no extra ASP cost, no extra vendor to manage, and no API link to set up between Zoho Books and an outside ASP.

In short — Zoho Books now does what TallyPrime 7.0 has done from the start. Both platforms have direct built-in Peppol e-invoicing with no external ASP needed.

How the Invoice Journey Works Now

After setup, your team confirms invoices in Zoho Books exactly as always. The whole Peppol process happens in the background automatically. Here is the full journey:

Invoice confirmed in Zoho Books — your team, same as always
Zoho Books creates PINT AE XML directly — automatic
Zoho Books checks all 17 PINT AE mandatory fields — automatic
PINT AE XML sent through UAE Peppol network directly from Zoho Books — automatic
Invoice delivered to buyer's accounting system — automatic
Send status updated in Zoho Books dashboard — automatic

Your team does nothing new after go-live.

What This Means for Cost

Before this update, UAE Zoho Books users paid for a Zoho Books licence plus a separate ASP subscription. Now, the ASP function is built into Zoho Books. Therefore, there is no extra ASP cost at all on the right plans.

Professional plan (~AED 110/month) — direct Peppol supported, no extra ASP cost

Premium plan (~AED 165/month) — direct Peppol supported, no extra ASP cost

Elite plan (~AED 220/month) — direct Peppol supported, no extra ASP cost

Standard plan (~AED 55/month) — does NOT support direct Peppol — plan upgrade needed

Free tier — does NOT support direct Peppol

How Zoho Books Now Compares to Other UAE Platforms

With this approval, the UAE e-invoicing platform picture looks like this:

TallyPrime 7.0 — native Peppol built in, no external ASP needed. Best for trading, manufacturing, and stock-heavy businesses.

Zoho Books — now an approved ASP with direct Peppol built in, no external ASP needed. Best for small businesses, startups, and businesses already using the Zoho suite.

QuickBooks — needs QBESync by Perfonec to connect to UAE Peppol. Best for SMEs and professional services.

Odoo ERP — needs OESync by Perfonec to connect to UAE Peppol. Best for growing businesses needing full ERP.

Sage 50 — needs middleware and external ASP. Best for distribution and trading companies.

Therefore, UAE businesses now have two strong no-external-ASP options — TallyPrime 7.0 and Zoho Books. The right choice depends on your business type and size.

What You Still Need to Set Up

This is the most important point to understand. Zoho Books being an approved ASP does not mean e-invoicing is automatically ready in your account. You still need to configure Zoho Books for UAE e-invoicing before you can go live.

Here is what needs to be done:

Plan check — Professional, Premium, or Elite plan required. Standard plan users need to upgrade first.

PINT AE data audit — all 17 mandatory PINT AE fields must be correctly set up in Zoho Books. The most commonly missing field is the buyer TRN in Zoho Books Contacts. Additionally, addresses must be in a structured format, product names must be specific, and UN/CEFACT unit codes must be set up on all products.

VAT code mapping — all Zoho Books tax rates must be mapped to the four PINT AE VAT category codes. S for standard rated at 5%, Z for zero-rated, E for exempt, and O for out of scope.

Enable direct Peppol — the direct Peppol connection must be turned on and configured in your Zoho Books account settings. This includes credit note type 381, advance payment invoices per Version 1.1, and free zone fields for DMCC, JAFZA, IFZA, and DIFC.

Pilot phase testing — all invoice types must be tested through the direct Peppol connection during the pilot phase. The pilot phase has been open since 1 July 2026 with no financial fines for any errors. Therefore, now is the right time to test.

Team training — your accounts team needs to know how to read the Peppol send status in Zoho Books and what to do if an invoice is rejected.

What About Businesses Already Using Zoho Books with an External ASP?

If you already set up an external ASP for your Zoho Books account, you can now move to the direct Peppol connection built into Zoho Books. As a result, you no longer need to pay for the external ASP subscription. Contact Perfonec to migrate your setup to the direct connection.

UAE E-Invoicing Mandatory Deadlines

Every UAE VAT-registered business must be live on UAE mandatory e-invoicing by their deadline:

1 January 2027 — businesses with annual revenue above AED 50 million
1 July 2027 — all other VAT-registered SMEs
1 October 2027 — government entities
From 1 July 2026 — pilot phase open now, no fines during testing

The fine for not going live is AED 5,000 per month under Cabinet Decision No. 106 of 2025. Additionally, AED 100 per non-compliant invoice applies, capped at AED 5,000 per month. However, the pilot phase carries zero fines. Therefore, starting now is the safest approach.

Do Fines Apply to Free Zone Zoho Books Users?

Yes. All UAE VAT-registered free zone businesses — DMCC, JAFZA, IFZA, DIFC, ADGM, RAKEZ — are in scope for UAE mandatory e-invoicing. Furthermore, a free zone licence gives no exemption from the fine schedule under Cabinet Decision No. 106 of 2025.

The Bottom Line

Zoho Books being an FTA-approved ASP is a major positive change for UAE Zoho Books users. It removes the need for a separate ASP subscription, simplifies the setup process, and reduces the total cost of UAE e-invoicing compliance.

However, you still need to configure Zoho Books correctly before going live. The PINT AE data audit, VAT code mapping, and direct Peppol setup all need to be done before your mandatory deadline. Perfonec handles all of this as the authorised Zoho Partner in UAE.

The pilot phase is open now with zero fines. Therefore, the right time to start is today.

About the Author

Akanksha Surana is the CEO and Owner of Perfonec Computers, Dubai — authorised Zoho Partner, Certified QuickBooks Pro Advisor, Authorised Silver Partner for TallyPrime, developer of QBESync and OESync, and Odoo Ready Partner with Odoo Middle East (Cert n°0000699697). She has 9 years of experience setting up Zoho Books and UAE e-invoicing for UAE businesses.

Free Zoho Books UAE e-invoicing readiness check — no cost, no commitment.

📞 +971 4 386 6199 | sales@perfonec.com | www.perfonec.com

Based on UAE Ministry of Finance E-Invoicing Guidelines Version 1.1 (June 2026) and Cabinet Decision No. 106 of 2025. For general guidance only — not legal or tax advice.

Does TallyPrime Need an External ASP for UAE E-Invoicing?

Perfonec Computers — Tue, 01 Sep 2026 11:25:17 +0000

Businesses in the UAE preparing for e-Invoicing often have questions about how their existing accounting software will work with the new requirements. One common question among TallyPrime users is whether they need to purchase a separate external Accredited Service Provider (ASP).

The answer is that a TallyPrime user does not necessarily need a separate third-party ASP. Tally Software Solutions FZCO is an accredited service provider under the UAE e-Invoicing framework, so businesses can choose Tally as their ASP where applicable.

TallyPrime supports accounting and invoicing workflows that can be used as part of the UAE e-Invoicing process. However, businesses still need to complete the required onboarding, configuration, and authorization steps.

Before getting started, TallyPrime users should check that their software version is supported for UAE e-Invoicing and ensure that important information such as the company's TRN, VAT details, customer records, supplier records, and accounting data is accurate.

Using an integrated accounting and e-Invoicing workflow can also help reduce duplicate data entry and make it easier for businesses to manage their invoicing processes.

The key point is that having an ASP is part of the UAE e-Invoicing framework, but the ASP does not necessarily have to be a separate external software provider.

Businesses using TallyPrime should review the latest UAE e-Invoicing requirements and Tally's current documentation before completing their implementation.