Finance teams running ERPNext in Oman hit the same wall every filing period: the 5% VAT calculations are technically present, but the outputs the Oman Tax Authority (OTA) actually expects are not. Stock ERPNext gives you generic tax templates and a generic tax report, so accountants end up rebuilding the OTA VAT return in spreadsheets each quarter, hand-mapping standard-rated, zero-rated, exempt, reverse-charge and out-of-scope supplies, and manually producing the box-by-box figures. Add bilingual Arabic/English invoice requirements and the looming e-invoicing mandate, and the native setup runs out of road exactly where compliance risk is highest.

ECOSIRE builds a proper Frappe app (for example oman_vat) that installs cleanly onto your existing ERPNext site rather than a pile of loose customizations. It ships purpose-built DocTypes for OTA return periods, a VAT box-mapping configuration, and an e-invoice register, plus role profiles (Tax Manager, Accountant, Auditor) so the compliance workflow has real permissions instead of everyone sharing the Accounts Manager role. Tax categories and item tax templates are seeded for Oman's standard-rated, zero-rated, exempt and reverse-charge treatments, and every Sales/Purchase Invoice is validated against them at submit time.

Technically, the logic lives where Frappe expects it. hooks.py document events (validate, on_submit, on_cancel on Sales Invoice, Purchase Invoice and Payment Entry) enforce correct tax treatment, capture the buyer/seller tax IDs, and post figures into the return period. Server scripts and scheduler events aggregate the OTA VAT return and reconcile it against the GL, so the number on the return equals the number in the ledger. Client scripts drive the invoice form UX — Arabic field mirroring, VAT-ID validation, and the bilingual print format. A set of @frappe.whitelist() methods (and matching Frappe REST API endpoints) expose the return summary, invoice register export, and a structured e-invoice payload so your billing systems or a future OTA portal integration can pull clean data instead of scraping print output.

On e-invoicing readiness, we structure your data now so the eventual mandate is a switch, not a rebuild: canonical invoice numbering, UUID/hash fields on the e-invoice register, QR-ready payload assembly, and a bilingual UBL-style export scaffold. Where the OTA's technical specification is finalized we implement to it; where it is still evolving we build the data model and hooks so certified transmission can be added without touching your ledgers.

Because this is build-to-order, delivery starts with a short scoping call to confirm your ERPNext version (v15 or v16), chart of accounts, invoice volumes, and which OTA outputs you need first. We then build against a staging copy of your site, run UAT with your finance team, and cut over with a rollback plan. Typical delivery is one working week from confirmed scope. You receive the installable source for your version, a git repo handover, documentation, training, and a post-go-live support window — you own the app.