DEV Community: Perfonec Computers

A Small Python Script to Catch E-Invoice Data Problems Before They Reach the Network

Perfonec Computers — Mon, 02 Nov 2026 11:13:34 +0000

Disclosure: I used AI to help draft this article. I reviewed the content and tested the script myself. I work at an accounting software partner in Dubai, and this post is a general tutorial.

The UAE is moving to structured electronic invoices. Instead of emailing a PDF, a system produces invoice data in a defined format, and an accredited service provider sends it to the customer. The Ministry of Finance publishes the list of accredited providers.

In practice, most rejected invoices are not caused by software bugs. They come from bad master data: a customer with no tax number, an item called "Services", an address stored in one text box. This post shows a small script that finds these problems in a CSV export before you send anything.

What the script checks

Customer tax registration numbers (TRN) exist and are 15 digits
Customer address has a street, a city, and a country
Item names are not generic words such as "Services" or "Goods"
Unit codes come from an allowed list
VAT category codes come from an allowed list

The data

Export two CSV files from your accounting system. customers.csv:

name,trn,street,city,country
Alpha Trading LLC,100123456789012,Sheikh Zayed Road,Dubai,AE
Beta Logistics,,Industrial Area 3,Sharjah,AE
Gamma Foods,12345,,Abu Dhabi,AE

And items.csv:

name,unit,vat_category
Monthly IT support retainer,HUR,S
Services,Box,S
Steel pipe 6 metre,MTR,Z
Goods,EA,X

The script

import csv
import re
import sys

# Edit these to match the specification your provider gives you.
GENERIC_NAMES = {"services", "service", "goods", "item", "items", "product",
                 "products", "misc", "other", "general", "supply"}
ALLOWED_UNITS = {"EA", "C62", "KGM", "LTR", "MTR", "MTQ", "HUR", "DAY"}
ALLOWED_VAT_CATEGORIES = {"S", "Z", "E", "O"}
TRN_PATTERN = re.compile(r"^\d{15}$")  # UAE TRNs are 15 digits


def check_customers(path):
    problems = []
    with open(path, newline="", encoding="utf-8") as f:
        for row_no, row in enumerate(csv.DictReader(f), start=2):
            name = row.get("name", "").strip() or f"row {row_no}"
            trn = row.get("trn", "").strip()
            if not trn:
                problems.append((name, "missing TRN"))
            elif not TRN_PATTERN.match(trn):
                problems.append((name, f"TRN is not 15 digits: {trn}"))
            for field in ("street", "city", "country"):
                if not row.get(field, "").strip():
                    problems.append((name, f"missing {field}"))
    return problems


def check_items(path):
    problems = []
    with open(path, newline="", encoding="utf-8") as f:
        for row_no, row in enumerate(csv.DictReader(f), start=2):
            name = row.get("name", "").strip()
            label = name or f"row {row_no}"
            if name.lower() in GENERIC_NAMES or len(name) < 4:
                problems.append((label, "item name too generic"))
            unit = row.get("unit", "").strip().upper()
            if unit not in ALLOWED_UNITS:
                problems.append((label, f"unit '{unit}' is not an allowed code"))
            cat = row.get("vat_category", "").strip().upper()
            if cat not in ALLOWED_VAT_CATEGORIES:
                problems.append((label, f"VAT category '{cat}' not recognised"))
    return problems


if __name__ == "__main__":
    customers, items = sys.argv[1], sys.argv[2]
    all_problems = check_customers(customers) + check_items(items)
    for record, issue in all_problems:
        print(f"{record}: {issue}")
    print(f"\n{len(all_problems)} issue(s) found")

Running it

python validate_data.py customers.csv items.csv

With the sample data above, the output is:

Beta Logistics: missing TRN
Gamma Foods: TRN is not 15 digits: 12345
Gamma Foods: missing street
Services: item name too generic
Services: unit 'BOX' is not an allowed code
Goods: item name too generic
Goods: VAT category 'X' not recognised

7 issue(s) found

Limits worth knowing

This script checks format only. It does not confirm that a TRN belongs to the customer, and it does not replace the validation your accredited provider performs. The allowed lists at the top are examples. Use the code lists in the specification your provider supplies, and update them when the specification changes.

Start with customers you invoice most often. Fixing a small group of high-volume records usually removes most of the problem.

If you adapt this for your own system, I would be interested to hear which checks you added.

QBESync Setup Guide — UAE E-Invoicing for QuickBooks Desktop and Online

Perfonec Computers — Tue, 27 Oct 2026 11:05:31 +0000

Disclosure: I am Akanksha Surana, CEO of Perfonec Computers in Dubai. Perfonec developed QBESync — the UAE Peppol e-invoicing connector for QuickBooks. We are the Authorised QuickBooks Dealer and Pro Advisor in UAE. This guide is written to help UAE QuickBooks users understand the complete setup process.

The Problem — QuickBooks Has No Native UAE Peppol Support

UAE mandatory e-invoicing requires every VAT-registered business to send B2B invoices through the UAE Peppol network in PINT AE XML format from 2027. QuickBooks does not have this built in.

QBESync is consequently the connector that bridges QuickBooks and the UAE Peppol network. Without it — or another approved connector — UAE QuickBooks users cannot comply with the mandatory requirement.

This guide covers the complete QBESync setup — all 9 steps, the full PINT AE data audit with field-by-field QuickBooks fixes, the 7-invoice pilot testing checklist, and what happens at go-live.

Quick Reference
Product: QBESync — UAE Peppol e-invoicing connector for QuickBooks
Developer: Perfonec Computers — Authorised QuickBooks Dealer UAE
QB versions: Desktop 2017–2024 | QuickBooks Online | QB Enterprise
Setup time: 4 to 8 weeks (data audit is the longest step)
Pilot phase: Open from 1 Jul 2026 — ZERO fines during testing
Deadline 1: 1 Jan 2027 — revenue above AED 50M
Deadline 2: 1 Jul 2027 — all other VAT-registered SMEs
Contact: +971 4 386 6199 | sales@perfonec.com
Website: www.qbeinvoice.com
Architecture — How QBESync Works

Before the setup steps, here is what QBESync actually does under the hood:

QuickBooks (Desktop or Online)
│
│ Invoice confirmed
▼
QBESync
│
├── Reads invoice data via SDK API (Desktop) or REST API (Online)
├── Maps fields to PINT AE XML schema (17 mandatory fields)
├── Validates XML against UAE PINT AE business rules
├── Signs and packages for Peppol transmission
│
▼
ASP (Approved Service Provider)
│
▼
UAE Peppol Network
│
▼
Buyer's ERP / Accounting System
│
▼
Delivery confirmation → back to QBESync → status updated in QuickBooks

QB Desktop connection: Local SDK API — more stable, faster for bulk data operations during setup.

QB Online connection: Intuit REST API (OAuth 2.0) — cloud-based, suitable for remote teams.

The 17 Mandatory PINT AE Fields

Every UAE B2B invoice must contain these 17 fields in the PINT AE XML. Missing or incorrect values cause rejection at the ASP or Peppol network level.

BT-1 Invoice number
BT-2 Invoice issue date
BT-3 Invoice type code (380 = invoice, 381 = credit note)
BT-5 Invoice currency code
BT-25 Preceding invoice reference (credit notes only)
BT-29 Seller TRN (Tax Registration Number)
BT-35 Seller street address
BT-36 Seller city
BT-38 Seller country code (AE)
BT-46 Buyer TRN
BT-50 Buyer street address
BT-51 Buyer city
BT-53 Buyer country code
BT-110 Invoice total VAT amount
BT-112 Invoice total amount with VAT
BT-130 Item unit code (UN/CEFACT)
BT-151 VAT category code (S / Z / E / O)
BT-152 VAT rate (5 / 0)
BT-153 Item description
All 9 Setup Steps
Step 1 — Version Check (Day 1)
QB Desktop 2017 ✅ Supported — local SDK API
QB Desktop 2018 ✅ Supported — local SDK API
QB Desktop 2019 ✅ Supported — local SDK API
QB Desktop 2020 ✅ Supported — local SDK API
QB Desktop 2021 ✅ Supported — local SDK API
QB Desktop 2022 ✅ Supported — local SDK API
QB Desktop 2023 ✅ Supported — local SDK API
QB Desktop 2024 ✅ Supported — local SDK API
QB Online ✅ Supported — Intuit REST API
QB Enterprise ✅ Supported — confirm with Perfonec
QB Desktop 2016- ❌ Not supported — upgrade required

Perfonec runs this check on Day 1 at no cost.

Step 2 — PINT AE Data Audit (Week 1–3)

This is the longest step and the most important. Between 20 and 40 percent of UAE QuickBooks customer records are typically missing BT-46 (buyer TRN). Furthermore, generic item descriptions, unstructured addresses, and non-standard unit codes all cause schema validation failure.

Here is the full audit table — what to check in QuickBooks, the common problem, and the fix:

BT-46 — Buyer TRN

Where: Customer record → Tax Registration No field
Problem: Missing from 20–40% of UAE customer records
Fix: Collect UAE TRN from all VAT-registered customers
Risk: HIGH — invoice rejects immediately without buyer TRN

BT-153 — Item Description

Where: Products and Services → Name field
Problem: Services, Goods, Item, Consulting — too generic
Fix: Rename to specific: "IT Support Monthly",
"Steel Pipe 48mm x 6m", "Warehouse Storage per Pallet"
Risk: HIGH — FTA business rules reject generic descriptions

BT-130 — Unit Code

Where: Products → Unit of Measure field
Problem: Each, Box, Lot, Piece — not valid UN/CEFACT codes
Fix: Map to UN/CEFACT standard codes:
EA = each/unit
KGM = kilogram
MTR = metre
LTR = litre
HUR = hour
DAY = day
MTQ = cubic metre
Risk: HIGH — schema validation fails on invalid unit codes

BT-35 — Seller Street Address

Where: Company settings → address fields
Problem: Full address stored as one unstructured text block
Fix: Split into street name, city, country code (AE)
Risk: MEDIUM — address structure required by PINT AE schema

BT-50 — Buyer Street Address

Where: Customer record → billing address
Problem: Full address in one text block per customer
Fix: Split into street, city, country code
across every customer record
Risk: MEDIUM — same schema requirement as seller address

BT-151 — VAT Category Code

Where: Tax code on each product or service
Problem: Standard 5% applied to zero-rated or exempt supplies
Fix: S = Standard rate 5%
Z = Zero-rated (international freight, exports)
E = Exempt
O = Out of scope (outside UAE VAT)
Risk: HIGH — wrong category causes FTA rejection

Free Zone Beneficiary Field

Where: Customer record → custom free zone flag
Problem: Missing for JAFZA, DMCC, IFZA, DIFC, RAKEZ buyers
Fix: Tag all free zone customers — QBESync populates
the PINT AE free zone field automatically
Risk: HIGH — free zone invoices reject without this field

BT-5 — Currency / AED Equivalent

Where: Invoice currency setting
Problem: AED equivalent missing on USD and EUR invoices
Fix: No manual fix needed — QBESync calculates and
populates AED equivalent automatically per V1.1
Risk: LOW — QBESync handles this automatically
Step 3 — Data Quality Fixes (Week 2–4)

The client team works through the fix list Perfonec produces after the audit. Perfonec orders fixes by rejection risk — HIGH risk first, MEDIUM second, LOW last.

Typical fix timeline by business size:

Small business (<100 customers, <50 products): 3–5 days
Medium business (100–500 customers): 1–2 weeks
Large business (500+ customers, many products): 2–3 weeks

The bottleneck is almost always collecting missing buyer TRNs — not renaming items or fixing addresses. Getting TRNs from customers requires chasing accounts contacts. Consequently, start this step as early as possible.

Step 4 — ASP Registration (Week 2–3)

Perfonec registers the business with an Approved Service Provider. The ASP provisions:

Company Peppol participant ID
Peppol network endpoint (SMP registration)
Digital certificate for invoice signing
ASP connection credentials for QBESync configuration

Perfonec handles this step entirely. The client team does not interact with the ASP directly. Registration takes 3 to 5 business days after submission.

Step 5 — QBESync Installation and Configuration (Week 3–4)

QB Desktop installation:

bash

QBESync installs as a Windows service

Connects to QuickBooks via local SDK API

Requires QuickBooks to be open on the same machine

or accessible on the same local network

QBESync_config.json settings covered:

ASP endpoint URL and credentials
Company TRN
VAT code mappings (S / Z / E / O)
Free zone customer tags
Multi-currency AED equivalent rules
Invoice type settings (all 7 types)
Incoming Peppol invoice endpoint

QB Online connection:

OAuth 2.0 flow:

Perfonec initiates QBESync → QB Online OAuth
Client authorises in QB Online
QBESync stores refresh token
REST API polling interval configured
ASP webhook endpoint configured

Configuration takes 1 to 2 days once all data fixes are complete.

Step 6 — Pilot Phase Testing (Week 4–6)

The pilot phase opened 1 July 2026. Zero fines apply to any failure during pilot. The same failure after go-live triggers AED 100 per invoice.

Test all 7 invoice types:

Type 1 — Standard B2B invoice

How: Raise sales invoice to UAE VAT-registered test customer
Check: PINT AE XML generated ✓
All 17 fields populated ✓
Schema validation passed ✓
Peppol status: Delivered ✓

Type 2 — Credit note (type 381)

How: Issue credit memo in QuickBooks against test invoice
Check: BT-3 = 381 ✓
BT-25 = original invoice number ✓
Peppol status: Delivered ✓

Type 3 — Advance payment invoice

How: Raise deposit invoice before full order invoice
Check: Advance payment flag per V1.1 ✓
Correct amounts and VAT treatment ✓

Type 4 — Zero-rated export invoice

How: Raise invoice to overseas buyer (country code ≠ AE)
Check: BT-151 = Z ✓
BT-152 = 0 ✓
BT-53 ≠ AE ✓
VAT amount = 0 ✓

Type 5 — Free zone invoice

How: Raise invoice to JAFZA or DMCC test customer
Check: Free zone beneficiary field populated ✓
Peppol status: Delivered ✓

Type 6 — Multi-currency invoice (USD / EUR)

How: Raise USD or EUR invoice to international customer
Check: BT-5 = USD or EUR ✓
AED equivalent amounts populated ✓
Exchange rate applied per V1.1 ✓

Type 7 — Incoming supplier Peppol invoice

How: Ask test supplier to send Peppol invoice to your endpoint
Check: QBESync receives XML ✓
Validates against PINT AE schema ✓
Creates bill in QuickBooks ✓
Step 7 — Fix Pilot Issues (Week 5–7)

Every rejection during pilot produces a specific error code. The most common rejection codes and fixes:

BT-46 missing or invalid
→ Check customer TRN — re-collect if wrong

BT-153 fails business rules
→ Item description still too generic — rename

BT-130 invalid unit code
→ UN/CEFACT mapping missed — re-map

BT-151 / BT-152 mismatch
→ VAT category and rate do not match — fix tax code

Free zone beneficiary missing
→ Customer not tagged as free zone — tag and retest

AED equivalent calculation error
→ Exchange rate source misconfigured — fix in QBESync config

Most pilot issues resolve within 1 to 3 days of receiving the rejection report.

Step 8 — Team Training (Week 6–7)

Perfonec trains the accounts team on:

Normal invoice flow after go-live
(no change — confirm invoice as usual)
Checking Peppol delivery status in QuickBooks
(new status field on every B2B invoice)
Handling a rejection
(how to read the rejection reason and fix)
Raising credit note type 381
(different from standard credit memo — walk-through)
Incoming supplier Peppol invoice workflow
(how to find, review, and post to QuickBooks)

Training takes half a day. Perfonec provides a written reference guide for the accounts team afterwards.

Step 9 — Go-Live (Week 7–8)

After all 7 types pass pilot and training is complete — go live.

Go-live checklist:
✅ All 7 invoice types passed pilot
✅ Team training complete
✅ ASP production credentials active
✅ QBESync switched from sandbox to production
✅ First live B2B invoice confirmed and transmitted
✅ Delivery confirmation received from buyer
✅ Incoming supplier Peppol endpoint tested live

Perfonec monitors the first two weeks of production — watching delivery status, resolving any production issues, and confirming the first live invoice of each type transmits correctly.

UAE E-Invoicing Deadlines
Revenue > AED 50M:
ASP deadline: 30 Oct 2026
Go-live: 1 Jan 2027
Fines begin: 2 Jan 2027

All other VAT SMEs:
ASP deadline: 31 Mar 2027
Go-live: 1 Jul 2027
Fines begin: 2 Jul 2027

Pilot phase (all businesses):
Open from: 1 Jul 2026
Fines: ZERO during pilot

Fines after deadline:
Non-implementation: AED 5,000/month (no cap)
Per non-compliant invoice: AED 100 (capped AED 5,000/month)
Maximum combined: AED 10,000/month
Common Questions

Why does the data audit take longer than the technical setup?

The technical setup is predictable — 1 to 2 days regardless of business size. The data audit depends on years of QuickBooks usage and data entry habits. Furthermore, collecting missing buyer TRNs requires chasing customer contacts — which is outside Perfonec’s control. Consequently, starting early is the most impactful thing a UAE QuickBooks business can do right now.

QB Desktop or QB Online for QBESync?

QB Desktop is consequently recommended for higher invoice volumes and larger customer databases — the local SDK API is more stable and bulk data editing during the audit is significantly faster. QB Online works well for lower-volume businesses and remote teams.

What if a customer refuses to provide their TRN?

If a UAE VAT-registered buyer refuses to provide their TRN — the invoice cannot go through Peppol. The responsibility to provide a TRN is on the buyer. Furthermore, without their TRN, the invoice will reject at the ASP validation stage regardless of all other fields being correct. Consequently, collecting TRNs from all UAE VAT-registered customers before go-live is a commercial priority — not just a technical one.

Resources

Full guide with downloadable PDF:
https://perfonec.com/qbesync-setup-guide-uae-einvoicing-quickbooks/

What Is QBESync:
https://perfonec.com/what-is-qbesync-uae-peppol-quickbooks/

UAE E-Invoicing Complete Guide:
https://perfonec.com/uae-einvoicing-2027-complete-business-guide/

Free readiness check:
📞 +971 4 386 6199
📧 sales@perfonec.com
💬 WhatsApp: +971 56 408 5594
🌐 www.qbeinvoice.com

QuickBooks is a product of Intuit Inc. Based on UAE Ministry of Finance Electronic Invoicing Guidelines Version 1.1 (June 2026), Ministerial Decisions No. 243 and 244 of 2025, and Cabinet Decision No. 106 of 2025. For general information only — not legal or tax advice.

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.