UAE Localization Pack for ERPNext

Key Features

Standalone Frappe app (`uae_localization`) with its own module, fixtures and `hooks.py` — installed via `bench get-app` / `bench install-app`, never a patch to `erpnext` core

FTA-aligned tax setup shipped as fixtures: VAT account subtree plus Sales and Purchase Taxes and Charges Templates for standard 5%, zero-rated, exempt, out-of-scope and reverse-charge, with matching `Item Tax Template` records

`UAE VAT Treatment` DocType mapping every invoice line to its FTA return box, resolved from tax category, item tax template and delivery address

`validate` doc-event controllers on `Sales Invoice`, `Purchase Invoice`, `POS Invoice` and credit notes that block submission on a missing TRN, missing emirate or an unsupported zero-rating claim

Reverse-charge mechanism posted as a real GL pair on `on_submit` via `make_gl_entries`, so imported services hit both the output and input boxes without a manual journal entry

Designated zone handling: flags on Warehouse and Address that drive out-of-scope treatment for qualifying intra-zone movements, with the reasoning stored on the transaction for audit

Bilingual EN/AR tax invoice print formats as Jinja templates with an RTL Arabic column, mandatory FTA field set and AED-converted tax amounts on foreign-currency invoices

Print formats available from the desk, the Customer Portal and the standard `download_pdf` endpoint — no separate rendering service

TRN format validation as both a Client Script (instant desk feedback) and a server-side hook, so REST API writes and Data Import cannot bypass it

`UAE VAT Return` DocType aggregating a period into the FTA box layout, with drill-down from each box to the contributing GL Entries

Emirate-wise split of standard-rated supplies driven by a `UAE Emirate` link on the customer address, as the return's emirate breakdown requires

FTA Audit File export via a `@frappe.whitelist()` method — callable from a desk button or the Frappe REST API for scheduled extraction

`scheduler_events` jobs that pre-aggregate the current period nightly, so period-close is a review rather than a recomputation

Role profile and DocType permissions for a Tax Preparer who can build, review and export returns without Accounts Manager rights

Version-targeted build for Frappe/ERPNext v15 or v16, matching your bench's branch and Python version

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your ERPNext.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

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 2 to 4 weeks 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.

What you get

Installable Frappe app source built for your exact Frappe/ERPNext version (v15 or v16), passing `bench install-app` on a clean bench

Installation and configuration on your instance — fixtures loaded, VAT accounts mapped to your chart of accounts, tax templates bound to your item groups and customer tax categories

Technical documentation: DocType reference, `hooks.py` doc-event map, whitelisted API methods with request/response examples, and the FTA box-mapping table

End-user guide plus a live training session for finance staff covering invoicing, reverse charge, return preparation and audit file export

UAT on a staging bench using a copy of your production data, with a signed-off test script and a documented rollback plan before go-live

Post-go-live support window covering defect fixes and configuration adjustments, spanning your first VAT return period

Private Git repository handover — full commit history, branch matching your ERPNext version, your team added with write access

Handover call and an operations runbook covering upgrade steps, fixture re-sync and re-running the audit file export

Who this is for

Finance Manager at a UAE trading or distribution company

Files quarterly VAT returns and currently rebuilds them in Excel from the Sales Register and GL. Needs the FTA box structure, the emirate-wise split and reverse charge on imported services to come out of ERPNext directly, with drill-down they can defend in an FTA audit.

Group Controller running multi-company ERPNext across GCC entities

Has UAE entities alongside KSA or Oman companies in one ERPNext instance. Needs UAE VAT treatment to apply per company without changing tax behaviour for the other entities, and the audit file exportable per TRN.

IT / ERP Manager who owns the ERPNext instance

Will not accept core patches that break at the next `bench update`. Wants a standalone app with a private repo, documented hooks and whitelisted methods, pinned to the branch their bench actually runs, so upgrades and future customisation stay predictable.

Free zone or designated zone business with mixed supply types

Sells a mix of standard-rated mainland supplies, zero-rated exports and out-of-scope intra-zone movements. Needs treatment decided by rule at document level rather than by whoever picks the tax template, with the reasoning recorded on the transaction.

How UAE Localization Pack for ERPNext Compares

Criterion	ECOSIRE	Custom Build	Competitor	ERPNext Native
UAE VAT tax setup	FTA-aligned accounts, tax templates and item tax templates shipped as fixtures and mapped to your chart of accounts	Built from scratch in-house; quality depends entirely on whoever configures it	Generic tax templates that assume a stock chart of accounts and usually need rework	Generic Sales/Purchase Taxes and Charges Templates with no UAE-specific structure
Reverse charge on imported services	Posted automatically as a GL pair on submit, landing in both output and input return boxes	Typically a manual journal entry or a bespoke script nobody documents	Often absent, or a tax template that never creates the offsetting entry	No reverse charge concept; handled by manual journal entry
Bilingual EN/AR tax invoice	RTL Arabic beside English, mandatory FTA fields, AED tax disclosure on foreign-currency invoices	Achievable, but Jinja RTL layout and font handling take longer than estimated	Arabic support varies widely; often a fixed layout you cannot adapt to your branding	English-only default print format missing the FTA tax invoice field set
VAT return preparation	`UAE VAT Return` DocType in FTA box layout with drill-down to source GL entries and emirate split	Usually a report built once, then maintained by whoever remembers how it works	Often a summary report without drill-down or emirate breakdown	GL and tax reports only; the return is rebuilt in Excel each period
Designated zone handling	Warehouse and Address flags driving out-of-scope treatment, reasoning stored on the transaction	Frequently descoped as an edge case, then patched in under filing pressure	Rarely covered; treated as ordinary zero-rating if at all	No concept of designated zones
Upgrade safety	Standalone app using hooks, fixtures and custom fields — survives `bench update` on ERPNext	Core patches and one-off tweaks that break or silently revert on upgrade	Depends on the vendor's cadence; you wait for their build on your version	Nothing to break, but nothing to keep either
Integration surface	Whitelisted methods over the Frappe REST API plus nightly pre-aggregation, documented with examples	Endpoints exist if someone thought to build them; documentation is the code	Desk-only in many cases; API access not guaranteed	Standard Frappe REST API over raw DocTypes, with no VAT-specific endpoints
Ownership and support	Private Git repo handover, technical docs, training session and a support window covering your first return	You own it and you maintain it, including the parts nobody wrote down	Licensed or subscription; source and roadmap stay with the vendor	Community support only; UAE compliance is your problem

Frequently Asked Questions about UAE Localization Pack for ERPNext

How long does delivery take?

This is a build-to-order app, not an instant download. Typical delivery is 2 to 4 weeks from confirmed scope: roughly the first week for tax setup, treatment engine and doc-event controllers, the second for print formats and the return/audit-file layer, then UAT on your staging bench and go-live. Scope that adds historical period migration, a third-party e-invoicing integration or heavy multi-company mapping extends this, and we give you the revised estimate before we start rather than after.

Which Frappe and ERPNext versions do you support?

We build against Frappe/ERPNext v15 or v16, targeting the exact branch your bench runs. The app is version-pinned because doc-event signatures, the GL entry API and the print stack differ between majors — we do not ship one branch and hope it works on yours. If you are mid-upgrade, say so at the scoping call and we build for the target version.

What does support and updates look like after go-live?

A post-go-live support window is included and covers defect fixes and configuration adjustments, deliberately spanning your first VAT return period so the first real filing happens with us on hand. After that, ongoing support and version upgrades — carrying the app to a new ERPNext major, or adapting to an FTA rule change — are quoted as a separate engagement. You hold the Git repository either way, so you are never locked to us to keep it running.

Does this modify ERPNext core?

No. It is a separate Frappe app with its own module and DocTypes. Behaviour is attached through `hooks.py` doc events, custom fields and fixtures rather than by editing `erpnext` files, so `bench update` on ERPNext does not silently revert the localization. Uninstalling the app returns invoicing to stock ERPNext behaviour.

Can we call the VAT return and audit file export from our own systems?

Yes. The audit file export and return aggregation are exposed as `@frappe.whitelist()` methods, callable over the standard Frappe REST API with an API key and secret; the technical documentation includes request and response examples. A scheduler event also pre-aggregates the current period nightly, so an external system can read a current figure rather than triggering a full recomputation.

Does it produce an FTA-accepted e-invoice?

The pack produces compliant bilingual tax invoice print formats and the data structures behind them. Transmission to an accredited service provider under the UAE e-invoicing programme is a separate integration — the data model here is built so that integration is a connector, not a rebuild. If you want it in scope from day one, tell us at the scoping call and we quote it together.

How do we know it is correct before it touches production?

UAT runs on a staging bench restored from a copy of your production data, against a written test script covering standard-rated, zero-rated, exempt, out-of-scope, reverse charge and credit note cases, with the resulting return reconciled to a period you have already filed. You sign that off before go-live, and a rollback plan is documented in case anything needs reversing.