A UAE business running ERPNext core hits the same wall every quarter. ERPNext ships generic Sales Taxes and Charges Templates and a Tax Rule engine, but it knows nothing about the Federal Tax Authority's box structure, nothing about the difference between a zero-rated export and an exempt financial supply, and nothing about the fact that a supply into a designated zone may fall outside the scope of VAT entirely. So the finance team exports the GL and the Sales Register to Excel, hand-classifies every line, and rebuilds the return by formula. Meanwhile the standard Sales Invoice print format is English-only and omits the Arabic descriptors and the AED tax disclosure expected on a tax invoice, and reverse-charge purchases from overseas suppliers are either posted as plain input tax or missed altogether.

The UAE Localization Pack is a proper Frappe app — uae_localization — with its own module, DocTypes, fixtures and hooks.py, installed alongside ERPNext rather than patched into it. On install, fixtures create the UAE tax setup: an Account subtree for output VAT, input VAT, reverse charge output and reverse charge input; Sales and Purchase Taxes and Charges Templates for standard-rated 5%, zero-rated, exempt, out-of-scope and reverse-charge scenarios; and Item Tax Template records so the treatment follows the item rather than whoever picks the template. A new UAE VAT Treatment DocType classifies each transaction line into an FTA return box, and a UAE Emirate link on the customer's address drives the emirate-wise split the return demands for standard-rated supplies.

The compliance logic lives in server-side controllers wired through hooks.py doc events. A validate handler on Sales Invoice and Purchase Invoice resolves the VAT treatment from the party's tax category, the item tax template and the delivery address, then blocks submission when a required field is missing — no TRN on a B2B invoice, no emirate on a standard-rated supply, a zero-rating claim with no supporting export evidence attached. An on_submit handler posts the reverse-charge pair as an additional GL entry through make_gl_entries, so a service imported from abroad debits and credits the same amount and lands in both the output and input boxes of the return. TRN validation runs as a Client Script for immediate desk feedback and again server-side, so the REST API and Data Import cannot bypass it.

Bilingual print formats are Jinja templates with an RTL Arabic column beside the English one, the mandatory tax invoice field set, the AED-converted tax amount where the invoice is in foreign currency, and an optional QR payload — rendered through the standard print stack so they work from the desk, the Customer Portal and /api/method/frappe.utils.print_format.download_pdf. A UAE VAT Return DocType aggregates a period into the FTA box layout with drill-down to the contributing GL Entries, refreshed by a scheduler_events job so the numbers are ready before the filing window, and the FTA Audit File export is produced by a @frappe.whitelist() method you can also call over the Frappe REST API for your own automation. Role profiles and DocType permissions ship with it so a tax preparer can build and review a return without holding Accounts Manager.

This is build-to-order, not a marketplace download. You request a quotation, we run a scoping call, and we build the app against your ERPNext version — Frappe/ERPNext v15 or v16 — and your actual chart of accounts, item catalogue and invoicing patterns. Typical delivery is one working week from confirmed scope, longer if the scope includes migrating historical periods or integrating a third-party e-invoicing provider. You get the source, installed and configured on your instance, tested on staging against your own data before anything touches production.