ERPNext Customization for UAE and KSA Compliance

1. Legal and Compliance Frameworks

To effectively localize ERPNext for the UAE and Saudi Arabia, it’s critical to understand each country’s legal requirements in accounting, tax, HR, and record-keeping. Below we summarize the key laws and regulations that will influence ERPNext configuration for private sector companies, free zone entities, and government institutions in each country. (Authoritative government sources are cited for each requirement.)

1.1 Accounting and Financial Reporting Standards

1. United Arab Emirates (UAE): All companies in the UAE are required by law to follow International Financial Reporting Standards (IFRS) for their financial statements[1]. The UAE Commercial Companies Law (Federal Law No. 2 of 2015) mandates IFRS for general purpose financial reporting[1]. Small and medium entities may use the simplified IFRS for SMEs standard if eligible (revenue ≤ AED 50 million)[2]. These requirements have been reinforced by the new corporate tax law in 2023, which explicitly designates IFRS as the acceptable accounting framework for tax purposes[2]. In practice, this means an ERPNext implementation in UAE must support IFRS-compliant charts of accounts and financial reports. All significant accounting policies (accruals, depreciation, revenue recognition, etc.) should align with IFRS standards to ensure compliance.
2. Saudi Arabia (KSA): Saudi Arabia has adopted IFRS with local adaptations. All publicly accountable entities in KSA must use “IFRS Standards as endorsed by SOCPA”, the Saudi Organization for Certified Public Accountants[3]. SOCPA’s endorsed standards include all IFRS issued by the IASB, with additional disclosure requirements for Zakat and other local matters[3]. Small businesses are permitted (and in some cases required) to use IFRS for SMEs[3]. Thus, ERPNext in KSA should likewise be configured for IFRS-compliant accounting. Additionally, because SOCPA has added certain disclosures (e.g. Zakat computation) not covered by IFRS[3], the ERP must capture and report those items. Government or public sector entities in KSA might follow IPSAS (International Public Sector Accounting Standards) for their accrual-based accounting, but if using ERPNext, aligning with IFRS as a base (with necessary fund accounting modifications) would be needed.
3. Audit Requirements: Both countries legally require annual financial audits for most companies. In the UAE, the Commercial Companies Law and the Auditing Profession Law mandate that companies have their financial statements audited by a registered auditor[1][1]. In Saudi Arabia, the Companies Law similarly requires businesses to maintain proper accounts and undergo yearly audits by licensed auditors (especially for LLCs and joint-stock companies). ERPNext should facilitate this by maintaining detailed transaction logs, supporting audit trails, and producing standard reports (general ledgers, trial balance, financial statements) that auditors can review. It should also accommodate multi-currency accounting (e.g. transactions in USD with local currency AED or SAR books) as allowed under IFRS.

1.2 Taxation: VAT, Corporate Tax, and Zakat

1. UAE Value Added Tax (VAT): The UAE imposes a 5% VAT on most goods and services under Federal Decree-Law No. 8 of 2017[4]. VAT applies on the supply of goods/services at each stage of the chain, with certain exemptions and zero-rated categories (e.g. exports, certain healthcare). Legally, a “Tax Invoice” must be issued for taxable supplies, containing the supplier’s Tax Registration Number (TRN), invoice date, a unique invoice number, the VAT amount and rate, and other particulars as per the VAT law and its Executive Regulations[4]. The UAE’s VAT regulations also allow simplified invoices for small sales (e.g. under AED 10,000) and require credit notes for adjustments. ERPNext must be configured to generate VAT-compliant invoices showing all required fields. It should maintain separate accounts for output VAT and input VAT to facilitate filing the quarterly VAT return (Form VAT 201). The system should also support excise tax accounting if relevant (for businesses dealing in alcohol, tobacco, sugary drinks, etc., which are subject to UAE excise tax).
2. UAE Corporate Tax: Effective financial years on or after 1 June 2023, the UAE has introduced a federal corporate income tax (CT) regime (Federal Decree-Law No. 47 of 2022) with a standard rate of 9% on business profits[5][6]. A 0% rate applies to taxable income up to AED 375,000 (to support small businesses)[5]. Free zone companies that qualify can continue to enjoy 0% taxation on their qualifying income, but they still must register and file returns. The corporate tax law requires taxable persons to maintain accounting records and financial statements for 7 years after the relevant tax period[7][8]. ERPNext will need to facilitate computation of taxable profit (largely based on accounting profit per IFRS, with certain tax adjustments) and perhaps generate schedules to assist in filing the CT return. Configuration may include setting up a Corporate Tax payable account, and a way to track deferred tax assets/liabilities if IFRS mandates. For free zone entities, the ERP should allow segregation of income streams to distinguish qualifying vs. non-qualifying income for tax purposes, and support any required reporting to the free zone authority. (Many free zones also require companies to submit audited IFRS financials annually as part of license renewal.)
3. KSA VAT: Saudi Arabia introduced VAT in 2018 at 5%, but in 2020 the standard VAT rate was increased to 15%[9]. The KSA VAT law and implementing regulations (issued by the General Authority of Zakat and Tax, now ZATCA) mirror many GCC VAT framework provisions. Businesses must issue VAT invoices in Arabic (at least bilingually) and include the VAT registration number, invoice date (Gregorian date required), a sequential invoice number, the VAT amount and rate, and for invoices above a certain amount, the buyer’s details[10][11]. ERPNext in KSA needs to handle 15% VAT calculations, distinguish zero-rated and exempt supplies, and produce a VAT return (the form has fields for total sales, taxable sales, imports, etc.). The system should support withholding tax postings as well, since KSA imposes withholding tax on certain payments to non-residents (with rates 5%–20% depending on the nature of payment[9]). Additionally, as of 2023, digital services and e-commerce VAT compliance may require special attention (e.g. for Saudi Arabia’s e-invoicing rules, discussed below).
4. Zakat (KSA): Zakat is a religious wealth tax applicable in Saudi Arabia on Saudi and GCC-owned companies. It is charged at 2.5% of the company’s Zakat base annually[12]. The Zakat base is roughly the net worth of the business, calculated per ZATCA’s rules (retained earnings, certain reserves and long-term assets are added back or adjusted). If a company has foreign ownership, then the foreign share of income is subject to corporate income tax (20% on net profits) while the Saudi share is subject to Zakat – the ERP must accommodate both calculations in such cases. All companies must file annually with ZATCA – either a Zakat return for wholly Saudi/GCC entities or both Zakat and tax returns for mixed ownership[12]. ERPNext should be customized to compute the Zakat base (which may involve pulling end-of-year balances of assets and liabilities and performing specific adjustments). For example, payable accounts to shareholders and long-term loans may be added to equity for Zakat purposes, and fixed assets held over a year might be deducted – these rules can be built into a custom financial statement or a script. Moreover, since SOCPA requires disclosures on Zakat in the financial statements[3], the chart of accounts could include dedicated Zakat expense and Zakat provision accounts.
5. Tax Invoices & E-Invoicing (KSA): Since December 2021, Saudi Arabia mandates electronic invoicing (“Fatoorah”) for all taxpayers. Phase 1 required that businesses issue VAT invoices through an electronic system that can generate a compliant invoice with a QR code (for simplified invoices) and store the invoices electronically. Phase 2, being rolled out in stages, requires integration with ZATCA’s systems for real-time clearance or reporting of invoices[13][13]. Key compliance points include: invoices must be in Arabic (though dual-language is allowed) and contain a QR code encoding seller’s name, VAT number, timestamp, and total with VAT (for simplified invoices), plus a cryptographic stamp and a unique UUID for each invoice in Phase 2[14]. Also, invoices can’t be edited or deleted – any changes must be via credit/debit notes, and the system must maintain tamper-proof logs. These legal requirements mean ERPNext needs significant customization for KSA:
6. For Phase 1, ensure the Sales Invoice print format includes all required fields in Arabic and English and generate the QR code as per ZATCA specifications. (ZATCA provides specifications for the QR code in base64 TLV format including five fields – seller name, VAT number, time, invoice total, VAT total).
7. For Phase 2, implement digital signing of invoices and integration with ZATCA’s API endpoints. Saudi law requires generating an XML invoice in UBL 2.1 format with XML Digital Signatures (XAdES), then obtaining a cryptographic stamp from ZATCA for clearance[15][15]. The ERP system must be able to produce the XML, sign it with the company's private key (using a ZATCA-issued digital certificate), and send it via API for clearance. The response from ZATCA (cleared invoice with a unique clearance ID and validated signature) should be stored in the ERP. All this must happen quickly (ideally in real-time when an invoice is submitted). These are strict legal requirements for doing business in KSA, so any company using ERPNext there must adhere to them to avoid penalties.
8. Free Zones and Special Territories: In the UAE, free zone companies are generally subject to UAE VAT (unless the particular free zone is a designated zone for VAT purposes where certain supplies can be treated as outside the UAE VAT scope). ERPNext should allow configuring tax rules for free zone scenarios – e.g. sales within the same designated zone might be non-taxable, but sales to the mainland UAE are taxable. Additionally, free zones often require companies to file audited accounts to the zone authority; ERPNext should be able to produce financial statements per IFRS for that. In Saudi Arabia, there are no VAT-free zones (except specific economic city incentives), but there are special economic zones starting to appear (which might have different tax rules). The system’s tax configuration needs to be flexible to accommodate any such zones or future changes (for instance, UAE is also introducing a 9% corporate tax but 0% for many free zone incomes – so ERPNext should support tracking income by source to apply the correct tax treatment).

1.3 Payroll, Labor Law, and HR Compliance

1. UAE Labor Law (Private Sector): The UAE’s labor law (Federal Decree-Law No. 33 of 2021, effective Feb 2022) governs employment terms, working hours, leave entitlements, termination, and end-of-service benefits[16][16]. Key provisions to implement in ERPNext HR include:
2. Working Hours and Overtime: Normal working hours are typically 8 hours per day (48 hours per week) unless otherwise specified. Overtime is permitted within limits (2 hours/day extra maximum in many cases) and must be compensated with a salary uplift (125% of normal rate for daytime overtime, 150% for late night hours or rest days) as per the law. ERPNext’s Attendance and Timesheet features can be used to track working hours, and custom scripts can calculate overtime pay on Salary Slips according to these rules.
3. Annual Leave: Employees are entitled to 30 calendar days of paid annual leave per year (after completing one year of service). For partial years, at least 2 days per month accrue[17][18]. The ERP’s Leave Allocation should grant 30 days annually, and Leave Application should ensure the balance is not exceeded. Any UAE-specific nuances (like carry-forward limits or encashment) can be configured via leave policies.
4. Other Leaves: The new UAE law introduced several leaves: e.g. maternity leave (60 days total, per amended law, with 45 days full pay + 15 days half pay), parental leave (5 days), compassionate (bereavement) leave, study leave (10 days for longer-service employees)[18]. ERPNext can have separate Leave Types for each and track usage. These should be set as per the minimums in law.
5. End-of-Service Gratuity (EOSB): In lieu of pensions for expatriates, UAE mandates a severance payment upon termination (except in cases of dismissal for cause). The standard formula: 21 days of basic pay per year for the first 5 years, and 30 days of basic pay per year beyond 5 years[19]. (The total gratuity is capped at 2 years’ pay by law.) ERPNext does not calculate this by default, so a custom script or report is needed to compute EOSB based on an employee’s salary and tenure. The computation should account for resignations: under UAE law, as of the new labor law, employees receive full gratuity even if they resign (the previous law had reduced entitlements for resignations before 5 years, but the new law removed that differentiation[18] – gratuity is now owed in full as long as the employee completes at least 1 year of service). The ERPNext implementation should reflect the latest law (full gratuity after 1 year service, none if less than 1 year).
6. Contract Types and Termination: All contracts are now fixed-term (renewable) contracts up to 3 years[18]. ERPNext’s Employee documents should capture contract start and end dates, and a notification (via Workflow or alerts) can be set for contract expiry. Termination and resignation workflows should be implemented: e.g. if an employee resigns, HR should record the last working day and trigger the final settlement process (gratuity, unused leave encashment, etc.) – ERPNext can automate parts of this via a Separation workflow.
7. Wage Protection System (WPS): The UAE’s Wage Protection System is an electronic salary transfer system to ensure timely payment of wages. Employers must pay all employees through bank transfers or exchange houses, generating a WPS file (SIF – Salary Information File) each pay cycle. The Ministry (MOHRE) and Central Bank have defined the .SIF file format (a fixed-length or delimited text file with details of the company, employees, IBANs, salary, etc.). UAE law requires all mainland and many free zone companies to use WPS; non-compliance can result in fines or blocking of new work permits[20][20]. ERPNext’s Payroll module should be extended to output this file: all necessary fields (employee unique ID – e.g., the labor card or Emirates ID, employee IBAN, bank codes, salary amount, etc.) need to be captured. A custom script or a custom Print Format (since it’s text output) can generate the SIF. Fortunately, most of the data is in the Salary Slip and Employee DocTypes; as one community proposal noted, “with all the fields in Employee and Salary Slip, the data is already present… we can generate [the WPS .sif file]”[21][21]. Indeed, a contribution was made to add this: an open-source extension was built to produce the UAE WPS file from ERPNext[21]. We can use or adapt that solution. In summary, ERPNext must allow HR to generate the WPS bank file every month to upload to the bank/MOHRE, with minimal manual intervention.
8. Employee Records and Documents: UAE law requires maintaining various employee documents. For example, copies of passports, visas, Emirates IDs, labor contracts, etc., should be stored. ERPNext can use the Employee Attachments section or File doctypes to keep scans of these. It’s wise to add custom fields for details like Visa Number, Visa Expiry Date, Emirates ID, Labor Card Number, Health Insurance Expiry etc.[21] so that these can be tracked and reminders set. The system can send automated email alerts to HR or the employee X days before a visa or ID expires (using Notification with a document date field trigger).
9. Record-Keeping: Under the new labor law, employment records must be retained for at least 2 years after an employee’s termination[18]. This means ERPNext should not delete former employee records or payroll data for at least that period. Instead, implement an “archive” status for employees who have left, but keep their data searchable for two years. Moreover, payroll registers, WPS files, etc., should be stored and backed up. (From a system perspective, simply ensuring that the database or backups cover that timespan suffices; from a policy perspective, advise the user not to purge any HR data before 2 years.)
10. KSA Labor Law: The Saudi Labor Law (Royal Decree M/51, as amended) sets out similar fundamentals with some differences:
11. Working Hours: Generally 8 hours/day or 48 hours/week maximum in ordinary days. During Ramadan for Muslim employees, hours are reduced to 6 hours/day. Overtime is paid at 150% of normal wage (or more if the employer agrees) for extra hours or work on rest days/public holidays. ERPNext’s time tracking and payroll rules should reflect these rates.
12. Annual Leave: Saudi employees are entitled to 21 days of paid annual leave per year, increasing to 30 days after 5 years of service[22]. The law explicitly states “not less than 21 days… and not less than 30 days for those with over 5 years”[22]. In ERPNext, one could configure an initial 21-day leave allocation, and then have a rule (via a small custom script) to increase entitlement to 30 days once an employee’s length of service crosses five years. All leave must be documented – the system should track leave taken and remaining balance. Unused leave typically must be paid out on termination, which the ERP can calculate by multiplying unused days by daily wage.
13. Sick Leave and Other Leaves: Saudi law grants 120 days of sick leave (with the first 30 days fully paid, next 60 at 75% pay, and rest unpaid), maternity leave (10 weeks; 50 days fully paid for the first child, etc.), and others like marriage or bereavement leaves by company policy. These can be handled by configuring different Leave Types and possibly custom salary components for paid vs. unpaid portions.
14. End-of-Service Benefit (ESB): Saudi Arabia mandates an end-of-service gratuity similar to the UAE, but the rules for resignation differ. The standard formula (for termination or completion of contract) is half a month’s wage for each of the first 5 years and one month’s wage for each additional year[19], based on the employee’s final wage. This is the full entitlement if the employer terminates the employee or the contract ends normally. If the employee resigns, Saudi law restricts entitlement: no ESB if service < 2 years; 1/3 of the calculated ESB if 2–5 years; 2/3 if 5–10 years; full if >10 years[19]. ERPNext’s leave and payroll module should be customized to compute ESB considering these scenarios. One approach is to create a Server Script that runs on Employee separation and computes the due amount based on the service duration and reason for leaving, then generates a Final Settlement Payroll Entry including that amount. The formula can be coded directly from the law[19][19]. This ensures compliance with KSA’s labor law and enables HR to seamlessly process employee exits.
15. Wage Protection System (WPS): Saudi Arabia also enforces a WPS for salary payments. Companies must upload an electronic payroll file to the Ministry of Human Resources (MHRSD) portal each month, via the employer’s bank. The WPS file format in KSA (per MHRSD technical specs) is a fixed text (TXT) file similar to UAE’s, containing each employee’s national ID, bank IBAN, salary, allowances, deductions, etc.[23][24]. ERPNext’s payroll data should be used to generate this file. Implementation can mirror the UAE SIF approach, but adjusted for any differences in layout (e.g., the KSA file might require the Iqama (residence permit) number as employee ID, etc.). By customizing a report or building a small utility in ERPNext, the user can select a payroll period and export the WPS file. Compliance is crucial: as of 2025, Saudi authorities have tightened WPS enforcement (requiring file upload within 30 days of salary due date)[25]. ERPNext should assist by perhaps sending an alert if a WPS file upload is overdue.
16. Employee Data and Language: Saudi labor regulations stipulate that Arabic is the official language for all employment records, contracts, and documents[26][27]. While bilingual documents are common in practice, in case of any dispute, the Arabic text prevails. Thus, all HR letters, contracts, payslips, etc., should be produced in Arabic or dual-language. For ERPNext, this means configuring print formats for these documents in Arabic. The system’s built-in translation can provide Arabic labels, but field values like employee name and contract terms might need to be stored or entered in Arabic. Legally, companies should also maintain a register of Saudi vs non-Saudi employees for Saudization (localization) tracking – ERPNext can help by capturing nationality for each employee and perhaps producing a Saudization ratio report.
17. Record Maintenance: Employers in KSA are required to maintain employment records (such as wage records, employee registers, etc.) for a number of years – best practice is at least 5–6 years. In fact, KSA’s tax/vat law requires accounting records retention for 6 years (see Record-Keeping below), and labor law inspections may look at past payrolls up to 5 years. So, similar to the UAE, do not purge HR data. Also, the employer must keep certain records at the workplace (like a log of replaced expat workers by Saudis, per Article 17)[11] and display work schedules publicly[11]. These are operational matters: ERPNext can’t enforce posting a physical schedule, but it can generate the schedule as a PDF in Arabic for printing.
18. Government and Public Sector Considerations: If implementing for government or semi-government entities, additional compliance might include public procurement procedures (tendering rules), budgetary accounting, and following state-specific HR rules (e.g., civil service grades). For example, UAE federal entities follow the Federal HR Law and often have grading and benefits schemes that differ from the private-sector labor law (though many principles overlap). In KSA, government entities might follow the civil service law rather than the labor law. These specifics are beyond ERPNext’s standard scope, but customizing DocTypes for things like budget approval workflows, commitment accounting (encumbrances), or grade-based salary scales might be necessary for a truly comprehensive solution in the public sector. Additionally, government organizations often require bilingual English/Arabic for all reports and may need to consolidate accounts under IPSAS (if adopting accrual accounting for government). Ensuring ERPNext can support fund accounting or segment reporting (for different departments or projects) would be useful in those cases.

1.4 Record-Keeping, Archiving, and Audit Obligations

Both UAE and KSA have laws specifying how long companies must keep books of account and other records, which directly affects data retention policies in ERPNext:

1. Accounting Records Retention: The UAE Tax Procedures Law and VAT regulations stipulate that all tax-related records (invoices, ledgers, etc.) must be kept for 5 years after the end of the tax period to which they relate[28]. For certain records like real estate, the requirement is 15 years. Meanwhile, the new UAE Corporate Tax law explicitly mandates 7 years retention for accounting records and documents from the end of the relevant financial period[7]. To comply, ERPNext must retain transactional data (sales invoices, purchase invoices, journal entries, payroll records) for at least 7 years. This means that archive or deletion scripts should be disabled for data younger than that. Also, the system’s backup routines should be configured to preserve long-term archives (perhaps yearly backups stored offsite) in case of audit.
2. In Saudi Arabia, ZATCA requires taxpayers to keep VAT and Zakat records for no less than 6 years after the tax year[29][30]. All books, invoices (including electronic invoices), and related documents must be available for audit during that period. Additionally, electronic records must be stored in Arabic and within Saudi Arabia or accessible from inside the Kingdom[10]. This has implications on deployment: Saudi companies should host their ERPNext instance on a server within KSA (or at least ensure a real-time copy of the data is stored in KSA) to satisfy data residency rules for e-invoicing. In practice, cloud providers or local hosting in Saudi (like in Riyadh or Jeddah data centers) are recommended[31]. ERPNext partners in the region (e.g. ERPGulf) even offer local hosting because “it is mandated by law that the ERP servers should be inside the geographical area” for Saudi and some other Gulf countries[31]. We must plan for this: ensure that if the user opts for a cloud deployment, it’s on a KSA server, or if self-hosted, the server is physically in KSA.
3. Audit Trails: Both jurisdictions expect businesses to maintain proper audit trails. UAE law (and good governance) requires that any adjustments or entries are traceable. Saudi regulations for e-invoicing require tamper-proof records of all invoices (each invoice has a unique hash and any attempt to modify must be recorded). ERPNext already has version logs for document edits; we should ensure these logs are enabled for all financial documents and not purged. Enabling two-factor authentication and proper access controls in ERPNext is also a compliance best practice to prevent unauthorized data changes.
4. Document Formats and Language: As mentioned, legal documents often must be in Arabic (especially in KSA). The official language clause in Saudi labor law (Article 9) states that employment contracts, records, and communications must be in Arabic; any foreign language text is for convenience and the Arabic will prevail[26][27]. Similarly, Saudi corporate law and courts generally require Arabic documentation for any official submission. In the UAE, Arabic is the official language of federal laws and courts, but English is commonly used in business; still, government-facing documents (e.g. audit reports submitted to ministries, labor contracts submitted through MOHRE, etc.) either must be in Arabic or bilingual. For ERPNext, this means all standard print formats for invoices, purchase orders, payslips, etc., should be modified to bilingual templates. We should include Arabic field labels and possibly Arabic-transliterated values (for names of products or customers) where feasible. For example, a VAT Invoice in KSA should have “فاتورة ضريبية” and “Tax Invoice” as the title, and the fields like Customer Name, Address, etc., should appear in Arabic. It may require storing an Arabic version of master data (like customer and item names) in custom fields, unless the user will input bilingual text directly.
5. Mandatory Document Contents: Some specific documents have legally mandated content:
6. UAE and KSA invoices must show the Tax Registration Number (TRN in UAE, VAT ID in KSA) of the seller (and in KSA, also of the buyer for B2B invoices). ERPNext already has a Tax ID field for companies; ensure it’s populated and printed[32].
7. Credit notes (for returns or discounts) must reference the original invoice number and date. ERPNext should enforce capturing the link between the credit note and the invoice (perhaps using the Return checkbox and linking to the original).
8. For government or free zone compliance, certain formats might be needed: e.g., in UAE, an Emiratization report (list of UAE nationals employed and their details) may be required by MOHRE for larger companies – the HR module should be able to produce such a report (with Employee nationality filter).
9. Companies subject to statutory audit must often produce a fixed format Trial Balance, General Ledger, and balance confirmations. We should verify that ERPNext’s standard reports meet the Ministry of Economy or ZATCA guidelines (for instance, ZATCA requires invoices to be sequentially numbered without gaps, so ERPNext’s naming series must be configured as non-editable and continuous).
10. Audit and Regulatory Access: Another aspect of compliance is being prepared for audits or inspections. In the UAE, the FTA (Federal Tax Authority) or Ministry of Finance can perform audits and expect the taxpayer to produce records in an understandable format. In KSA, ZATCA can request data or even conduct e-audits (for e-invoicing, they might request the XML archives). The ERP should make data export easy – e.g., ability to export all entries for a year to Excel or CSV for an auditor. Ensuring OCR-readable PDFs or standardized format for invoices (PDF/A-3 with embedded XML for KSA as required[14]) is part of compliance too. In fact, the ZATCA e-invoice regulations specify the archival format: invoices must be stored in PDF/A-3 format with the embedded XML file, and retained for the 6-year period. We must configure ERPNext to generate PDF/A-3 files (this may need a custom PDF generation step using a library that supports PDF/A standards) and attach the XML to it. This is a very technical requirement stemming from law, but crucial for large enterprises under Phase 2 e-invoicing.

In summary, the legal framework in UAE and KSA drives many ERPNext configuration needs: IFRS-based accounting structure, VAT/Zakat handling, robust payroll with WPS and end-of-service calculations, bilingual document outputs, and strong record retention and audit trail features. Next, we consider existing open-source solutions that address these requirements, which we can leverage or draw inspiration from.

2. Open-Source References for Gulf Compliance

To avoid reinventing the wheel, it’s wise to study open-source ERP localizations or modules that already tackle UAE/KSA compliance. Below we highlight relevant projects and features from the community:

1. ERPNext’s Native GCC Localizations: ERPNext itself introduced basic support for UAE and KSA when those countries implemented VAT. For example, ERPNext v10 (released around 2017) was “KSA/UAE VAT ready out of the box,” providing the ability to issue VAT-compliant invoices in both simple and detailed formats as mandated by law[32]. This included printing invoices with the required tax breakdown and presumably the ability to configure the 5% (now 15% for KSA) rates. ERPNext also added regional settings for these countries: the system has a UAE Chart of Accounts preset (aligned to IFRS and FTA categories) and a KSA Chart of Accounts. When creating a new company in those countries, ERPNext can install these charts. It’s beneficial to use those as a starting point, since they often include basic accounts for Output VAT, Input VAT, Zakat, etc.
2. UAE Regional Module in ERPNext: The maintainers added specific DocType fields to meet UAE requirements. The ERPNext documentation mentions “UAE Regional Fields”, which include:
3. In Item Master: a checkbox “Is Zero Rated Item” (to flag items that are zero-rated for VAT)[33].
4. In Sales and Purchase Invoices: fields for TRN (Tax Registration Number) of customer/supplier, and possibly fields to distinguish Designated Zone supplies. These help generate VAT returns correctly (e.g., the UAE VAT 201 return has separate boxes for standard-rated, zero-rated, exempt, and imports).
5. The official ERPNext docs confirm a UAE VAT 201 Report is built-in[34][34]. This report compiles the data needed for filing the UAE VAT return (VAT201) – it likely shows Output VAT, Input VAT, zero-rated sales, etc., for a given period. Using ERPNext’s UAE localization means we can generate that report without custom development. We should verify it aligns with the latest FTA form, but since it’s core to ERPNext, it’s a solid base.
6. KSA VAT and Zakat in ERPNext: Similarly, ERPNext added a “KSA VAT Management and Reporting” module[34]. This likely provides a report equivalent to the Saudi VAT return form and may include features to handle Zakat. (Zakat is not a transactional tax, so it might not appear in day-to-day ERP operations; however, an ERPNext financial statement extension could compute the Zakat base or at least provide the balances to plug into a Zakat computation worksheet.) The community has also shared scripts for Zakat calculation given the standard formula (essentially 2.5% of net assets after certain deductions). We might find these on forums or GitHub. At minimum, the Chart of Accounts for KSA (available via the l10n_sa module in Odoo and similarly in ERPNext) includes accounts like “Zakat Provision” and “Zakat Expense” which indicate how Zakat is treated – typically as an appropriation of retained earnings or a deductible expense depending on company policy.
7. Open-Source E-Invoicing Solutions (ZATCA Integration): This has been a big area of development given Saudi’s regulations. Several ERPNext partners have created apps for ZATCA compliance:
8. ERPGulf’s ZATCA App: The company ERPGulf open-sourced an app for Phase 2 E-Invoicing on GitHub. It’s described as “An app for e-invoicing in Saudi Arabia” under MIT license[15]. The app handles:
9. Generating the XML invoice in the format required (UBL 2.1) with all invoice data[15].
10. Computing the cryptographic hash (digest) of the invoice and the digital signature using XAdES standards[15].
11. Embedding the company’s digital certificate and the signature into the XML (as per ZATCA’s guidelines)[15].
12. Connecting to ZATCA’s API to send the invoice and retrieve the Clearance or Reporting response (including the unique UUID/CSID that must be included on the final invoice)[15].
13. Storing the cleared invoice and providing the QR code with the cryptographic stamp.
14. The README of the repo explicitly lists steps like generating UBL XML, XAdES signature, and calling the ZATCA API[15][15] – essentially a blueprint of what we need to implement. We can reuse this app or its logic to save time. It’s also noted that an updated version (for 2024 guidelines) exists[15], indicating the solution is evolving with ZATCA’s requirements.
15. ERPGulf’s Enhanced App (zatca_erpgulf): Another repository by ERPGulf (possibly the same app updated) lists features such as “Integration with ZATCA APIs for clearance & reporting,” “Automatic CSR (certificate signing request) generation & compliance checks,” “Secure token management,” “Invoice submission and retrieval of QR codes,” and audit logs[35]. It supports ERPNext v13–v15[35]. The feature list basically covers everything a business needs to comply:
16. Full Phase 2 compliance (digital signing and clearance).
17. Handling credit/debit notes too (as those also must be reported).
18. A dashboard or reports to reconcile invoices in ERPNext with what’s reported to ZATCA (important for audits)[35].
19. This app can likely be installed directly (via bench) since it’s open-source. It provides a huge head-start for KSA compliance. Instead of writing a custom integration from scratch, we could fork this app and adapt it to our deployment. It’s also a good reference to understand how to structure the integration.
20. Beveren Software’s Solution: Another ERPNext partner, Beveren, has a ZATCA solution (though it might be proprietary). They published a Medium article (2024) describing their ERPNext ZATCA Phase 2 integration[14]. They emphasize features like 150+ validation checks, instant clearance with ZATCA, and storing data on KSA servers[14]. Notably, they mention PDF/A-3 invoices with embedded XML, containing the UUID, invoice hash, QR, and digital signature[14] – confirming that their ERPNext can output fully compliant e-invoice PDFs. While their code isn’t public, their description validates the approach we need. They also highlight archiving invoices for 6 years on cloud and tamper-proof security[14][14], which aligns with the legal requirements. The takeaway from Beveren’s write-up is the importance of:
21. Rigorous data validation (e.g., customer VAT IDs must be 15 digits, addresses must include building and block numbers as required by ZATCA, etc., otherwise the invoice will be rejected).
22. User-friendly workflow: The user shouldn’t have to manually sign or upload invoices – the system should handle it and just notify if an invoice was cleared or if there was an error.
23. Multi-company support: If one ERPNext instance serves multiple companies, the integration must handle multiple sets of API credentials and certificates[14].
24. We can incorporate these pointers when building our solution – perhaps by creating a “ZATCA Settings” DocType in ERPNext where each company’s VAT details, certificate, API credentials, etc., are stored, as presumably done in these apps.
25. Odoo’s Localization (for reference): Odoo, another open-source ERP, has official KSA modules that we can reference for functionality. The Odoo 18.0 documentation shows that they provide modules l10n_sa (accounting), l10n_sa_edi (e-invoicing), and l10n_sa_pos[13][13]. The e-invoicing module in Odoo implements ZATCA’s requirements and even guides users to use the Fatoora simulation portal for testing[13][13]. Interesting pieces from Odoo’s doc:
26. They require filling detailed address fields including Building No. and Plot ID for companies[13], which is a ZATCA requirement for invoices. So we should add those fields in ERPNext’s address template for Saudi (and make them appear on invoice printouts).
27. They allow choosing an Identification Scheme (like Commercial Registration, etc.) for a company and entering its number[13] – this might be used to populate the <BuyerIdentifier> in the XML for e-invoices.
28. They have a “Simulation mode” to test invoices on ZATCA’s sandbox[13], which is smart. We could implement a sandbox mode in ERPNext as well (ZATCA provides sandbox API endpoints).
29. Odoo’s localization also likely includes Saudi payroll modules (to handle GOSI and WPS). Community blogs (Technaureus, etc.) mention that Odoo covers GOSI calculation and a basic WPS file. Even if we don’t use Odoo, their experience confirms the necessity: e.g., define GOSI contribution as a payroll component: in KSA, employer pays 12% and employee 10% of salary to GOSI for Saudi nationals (and for expats a smaller percentage for occupational hazard insurance). This can be set up in ERPNext payroll rules (salary structure) easily, but it’s something to remember to include.
30. Wage Protection System (WPS) Tools: For UAE, an open-source contribution was mentioned on the forum (by user Zubaer) that implemented WPS file generation[21]. It was said they created “a separate payslip module which generates the WPS file.” We should search Frappe’s app store or GitHub for “wps” – possibly a repository exists (e.g., “erpnext_wps” or similar). Even if not publicly available, developing a WPS exporter is straightforward given the format is documented by the Central Bank and MOHRE. Some companies also open-sourced their WPS solutions; for instance, there’s a mention of Oracle’s PeopleSoft or SAP scripts being shared on forums[36]. For our purposes, we can use the specifications (like the PDF from hrsd.gov.sa for Saudi WPS[23], or the MOHRE guidelines for UAE) to map ERPNext fields to the required output.
31. If an open library exists in Python for SIF, we could integrate it, but likely it’s custom. Instead, we’ll build a Python script within ERPNext to generate the file when HR finalizes the payroll.
32. HR Localization Projects: Some community-driven projects target Gulf HR needs. For example, one might find an “Arabic HR” extension or a fork of ERPNext with GCC labor law features. As of now, much of it is in forums rather than a central repo. However, there is a project called Frappe HR (official separate app) which might incorporate additional HR features. We should check if Frappe HR (by the core team) has any region-specific support like configurable gratuity rules or more flexible payroll formulas. If yes, adopting Frappe HR in our deployment could give advanced HR features beyond vanilla ERPNext.
33. External Compliance Libraries/APIs: Another category of open-source resource: libraries for local services. For instance:
34. ZATCA QR code generation – earlier, developers shared code to generate the base64 TLV QR for Phase 1. This is a small snippet but widely circulated on Stack Overflow and GitHub Gists. We can reuse such a snippet in our custom print format to ensure the QR prints correctly on the invoice.
35. Arabic text handling – Python has libraries like python-bidi and reportlab that can help format RTL text in PDF. If we need to generate bilingual PDFs with proper alignment, leveraging such libraries through server scripts might be necessary (though Frappe’s PDF engine wkhtmltopdf can handle Arabic if the html/css is set up with dir="rtl" and an Arabic font).
36. IBAN validation – Both countries use IBAN for bank accounts. Possibly incorporate an IBAN validator (there are open-source Python packages for IBAN). This could ensure that IBANs entered for employees (for WPS) or for company bank accounts (for customer payments) are valid, catching errors early.
37. Community Knowledge Base: The ERPNext forums and Telegram groups for the Middle East are treasure troves of specific solutions. For example, threads about UAE PDC (post-dated cheque) management or Kuwait indemnity calculations can often apply to UAE/KSA with slight tweaks. It’s wise to search and keep those references. The “UAE localization fulfillment” YouTube webinar[37] by a community member indicates that a lot of these features have been discussed and possibly coded.

In summary, leveraging open-source contributions can accelerate our project. We have confirmed available modules for VAT, charts of accounts, and e-invoicing (especially for KSA). We should incorporate these modules (after reviewing their code quality and compatibility with ERPNext v15) or at least draw on their methodologies. Next, we’ll outline concrete recommendations for implementing all these compliance features in ERPNext v15.

3. Implementation Recommendations for ERPNext v15 Customization

Using the legal requirements and open-source insights above, this section provides a detailed game plan for adapting ERPNext v15 to fully support UAE and KSA companies. We break down the recommendations by functional area, and suggest whether to achieve each via configuration, custom scripts, custom apps, or third-party integrations. We also point out where a single core solution can serve both countries versus where separate handling is needed.

3.1 Accounting and Financial Configuration

3.1.1 Chart of Accounts and Financial Statements:

Start by using the built-in country chart of accounts templates when creating the Company in ERPNext (select UAE or Saudi Arabia as country). These charts are IFRS-compliant and include key accounts:

1. UAE: Standard IFRS accounts in AED, plus a default VAT Output and VAT Input account (5% rate configured) under Duties & Taxes.
2. KSA: IFRS accounts in SAR, VAT Output 15%, VAT Input 15%, and often a Zakat Provision (under Equity or Liabilities).

Review and modify the chart to ensure:

1. Zakat: In KSA, decide how to record Zakat. Many companies accrue Zakat expense monthly or quarterly. You could create a monthly Journal Entry via Auto Repeat to debit “Zakat Expense” and credit “Provision for Zakat” (liability) to smooth it out rather than a big hit at year-end. Alternatively, calculate at year-end and pass one entry. Either way, have those accounts ready.
2. Corporate Tax: For UAE corporate tax, create a “Corporate Tax Payable” liability account and “Corporate Tax Expense” in the P&L. Since ERPNext doesn’t have tax filing built-in, the user will compute the tax outside or via a report, then book an expense JE. You can automate a provisional tax accrual at year-end: e.g., when closing books, use a Period Closing Voucher or manual entry for CT expense.
3. Multi-Currency: Many businesses in UAE/KSA deal in USD or EUR. Ensure the AED and SAR are set as the company base currencies respectively, and add other currencies in ERPNext currency list. For free zones, sometimes accounts are kept in USD – if needed, set up secondary currency or even separate books (but generally using base local currency is safer compliance-wise).
4. Financial Statement Formats: Use Account Trees to structure statements per local conventions. For example, a UAE financial report might need to classify expenses by function (if IFRS). KSA companies might need to separate Zakat and Income Tax in the income statement (some show Zakat below net income as it’s akin to distribution of profits). Customize the print format of financial statements if needed to include an Arabic title and any notes required by local authorities (like “These financial statements are prepared in accordance with IFRS and local regulations”).

3.1.2 Fiscal Year and Calendar:

Both countries follow the Gregorian calendar for financial reporting (Jan–Dec by default, except some firms choose a different year-end). Set the Fiscal Year accordingly in ERPNext. Government entities might follow the Hijri calendar for budgets, but in financials they usually convert to Gregorian. So we can stick to Gregorian in ERPNext and avoid confusion.

3.1.3 VAT Setup:

Leverage ERPNext’s Tax Template features:

1. In UAE company, create a Sales Tax (VAT) template: 5% rate, account = Output VAT. Mark it as included/excluded based on pricing needs (usually excluded). Do similar for Purchase Tax (VAT) 5% on expenses.
2. In KSA company, tax templates at 15%. Also add any specific codes: e.g., Zero VAT (0%) template for zero-rated items (exports, etc.), and Exempt template for exempt sales (like healthcare, if applicable).
3. The invoices should automatically pick the correct template based on item or customer settings. Possibly use Tax Rules: For example, define a rule that if Customer is foreign (out of GCC), apply 0% VAT (export). Or if item is marked “Is Zero Rated Item”, apply 0%. ERPNext’s condition-based tax rule system can handle this.
4. Ensure the Tax ID (TRN) of the company is stored in the Company master (ERPNext has a field “Tax ID” which you can label appropriately). Enter the 15-digit VAT ID for KSA, the TRN for UAE (usually 15 digits as well). When printing invoices, include a label and this number in both languages.

3.1.4 Invoicing and E-Invoicing:

This is a critical piece:

1. Standard Invoice Format: Design a custom Print Format for Sales Invoice that is bilingual (English/Arabic). Include all mandated fields:
2. Invoice title: “Tax Invoice (فاتورة ضريبية)”.
3. Seller name, address, and Tax ID in Arabic and English.
4. Buyer name and address. In KSA, if the buyer is VAT-registered, their Tax ID must appear; add a field for Customer’s Tax ID on the customer master and pull it into the invoice.
5. Invoice date in Gregorian (and optionally Hijri if desired – not mandatory but some companies include it).
6. Unique Invoice Number. (Use ERPNext naming series like KSA-{year}-{#####} to ensure continuity. Lock it so users cannot manually change after submission to maintain sequence integrity.)
7. Item descriptions – if all customers are Arabic-speaking, you might maintain item names in Arabic; otherwise show both. Possibly maintain a custom field “Item Name (Arabic)” in the Item doctype for printing.
8. Quantity, unit price, line total, VAT amount per line (if required by law for detailed invoice).
9. Total exclusive, VAT, and total inclusive amounts in figures and in words (English and Arabic). The law doesn’t force amounts in words, but it’s common in the region to show it.
10. QR Code: For KSA, on simplified invoices (typically B2C cash sales), a QR code must be printed. Even for B2B, Phase 2 requires a QR containing the cryptographic stamp. We will:
11. Write a custom script to generate the base64-encoded QR data after invoice submission. In Phase 1 (if we assume initial compliance), the QR contains: Seller name, seller VAT, timestamp, total, VAT total (all in a structured TLV). For Phase 2, it contains a shorter version of the cryptographic stamp (usually the invoice hash and ECDSA signature). We can initially implement the Phase 1 QR (which is easier) and then Phase 2 QR once we do the full integration.
12. Add an HTML field in the print format with an <img src="data:image/png;base64, {{ qr_image_data }}"> that renders the QR code. We can generate qr_image_data using a server-side method (perhaps using Python’s qrcode library or an API) and store it in a custom field on the Sales Invoice on submit.
13. Terms and conditions: if there are any legally required notes (e.g., in UAE, usually invoices say “Thank you for your business” etc., but not mandated; in KSA, for example, if a simplified invoice, you can note “Simplified Invoice - not for tax credit by buyer” as a precaution).
14. E-Invoice Integration (KSA Phase 2): We strongly recommend installing or developing a custom Frappe app for ZATCA integration:
15. Consider using the open-source ERPGulf ZATCA app[35]. This can be installed via bench get-app as per their instructions[35]. Once installed and migrated, you’ll get a new module in ERPNext for ZATCA. It likely provides a ZATCA Settings doctype to configure API keys, and it hooks into the Sales Invoice submission event.
16. Configure the ZATCA Settings with the company’s certificate (ZATCA issues a digital certificate after registration), the API credentials (client ID/secret for the API), and the chosen integration mode (clearing vs reporting). For larger companies, clearance (real-time approval for each invoice) is required; for smaller, reporting (sending a batch within 24 hours) might be allowed – ZATCA stipulates who is in which wave.
17. Test the integration in sandbox mode: The app or our custom integration should allow switching endpoints to the sandbox. Use the ZATCA provided keys for sandbox and try posting some invoices. Verify ERPNext receives a response with a UUID and that the invoice’s QR code updates to the compliant one.
18. Adjust ERPNext workflows: likely, once an invoice is submitted, the app will prevent printing until it’s cleared (to ensure only stamped invoices go out). If using our own integration, implement that logic: e.g., have a custom field “Clearance Status” (Pending, Cleared, Failed). When a Sales Invoice is submitted, call a Python function to:
19. Generate UBL XML from the invoice (map ERPNext fields to XML structure).
20. Sign the XML (we might need to use a library like signxml or ZATCA’s SDK which is Java, maybe use a subprocess or an API if available).
21. Send to ZATCA through their API (requests library).
22. Get response: if success, store the UUID and a copy of the signed XML in an attachment or in a doctype. Mark status Cleared.
23. If failure, log the error, mark status Failed, and alert finance users. The user can then resolve the issue (maybe missing address info or the system clock off sync) and retry submission via a button.
24. Ensure the final PDF invoice includes the required fields from the response:
25. The UUID (Invoice hash) usually must be printed (some print it as a long hex string on the invoice).
26. The QR code now representing the signed invoice (ZATCA’s specifications say the QR should encode at least: seller name, VAT, timestamp, total, VAT, plus cryptographic stamp or a link – their Phase 2 QR spec includes the stamp).
27. Optionally, a note like “Cleared by ZATCA” or the clearance ID could be included on the invoice for transparency.
28. Because this is complex, relying on the open-source app is beneficial. The app’s README indicates it covers certificate handling and API token management[35], which is non-trivial (the ZATCA API requires OAuth2 token exchange). Using a community-vetted solution reduces risk of non-compliance.
29. Electronic Records and Archiving: Configure automatic PDF attachment upon invoice submission. ERPNext has a feature to attach a PDF copy of an invoice on submit (via Print Settings). Enable that for audit trail. In KSA’s case, ensure it’s PDF/A-3 – if wkhtmltopdf output is not PDF/A, we might need an external converter or use a custom PDF generator. Possibly, after getting the cleared XML, we can embed it into the PDF’s metadata (this is advanced; maybe not in first iteration, but plan for it). At minimum, store the XML file as an attachment to the invoice for the 6-year period.
30. Recurring and Draft Invoices: In free zones or government contracts, sometimes recurring billing is used. ERPNext can auto-generate draft invoices. We should be careful to only trigger ZATCA API when an invoice is finalized (submitted). Also, note that KSA e-invoice rules prohibit deletion – so once an invoice is made in ERPNext (even a draft), if you need to cancel, you should use the Cancel with Credit Note approach rather than hard delete. We might enforce via permissions that Sales Invoices once saved cannot be deleted, only cancelled (to keep number sequence continuous).

3.1.5 Other Taxes and Fees:

1. If the company deals with withholding tax (KSA scenario for services from abroad), they might need to accrue that. We could add a feature: e.g., a custom field on Purchase Invoice to mark if WHT applies, and at what rate. Then on submission, auto-create a Journal Entry to credit a WHT payable and debit an expense or the supplier’s account accordingly. However, this might be overkill; they can do manual entries. Just ensure the chart has an account for WHT payable if needed.
2. For Excise tax (if our user is in a business that requires it, like a tobacco importer in UAE or KSA), ERPNext would need an Excise module – which is complicated because it involves warehouse stock movements. This may be beyond our scope unless specifically required. We note it as a potential third-party integration (some companies use external solutions for excise and integrate with ERPNext’s accounting via entries).

3.2 Human Resources and Payroll Adaptation

3.2.1 Core HR Settings:

1. Set up Working Hours properly: In ERPNext, define the default Working Time (Shift) as 8 hours/day, Sunday-Thursday for UAE (as many companies in UAE now align with Monday-Friday weekend, but government shifted weekend to Sat-Sun in 2022 for public sector; private sector can choose). We should confirm the client’s practice. For KSA, workweek is typically Sunday-Thursday. Configure Weekly Holiday accordingly in HR Settings.
2. Create a Holiday List for each country (public holidays). UAE has approx 14 public holidays (Prophet’s birthday, National Day, etc. – which change date each year since some follow Hijri calendar). KSA has ~10 (Eid al-Fitr, Eid al-Adha, National Day). Input these for at least 1–2 years ahead.

3.2.2 Employee Doctype Customization:

Add custom fields to Employee to capture local details:

1. Nationality (if not already present – it might be, but ensure it’s there to identify locals vs expats).
2. Passport No., Passport Expiry.
3. Residence Visa No., Visa Expiry (or Work Permit details). For KSA, Iqama No. and Expiry.
4. Labor Card/Work Permit ID (for UAE MOHRE).
5. Social Insurance Numbers: e.g., in KSA, GOSI Number; in UAE, for Emirati employees, the GPSSA (pension) number.
6. WPS Unique ID: In UAE, MOHRE assigns each employee a Person ID for WPS (usually mentioned in the labor card or contract). Include that since the WPS file needs it[21].
7. Health Insurance Expiry (since law requires providing health insurance to employees in UAE and some KSA regions). Tracking expiry ensures renewals on time.
8. Bank Account (IBAN): Although ERPNext has a Bank Account child table for Employee, it may not store IBAN explicitly. Perhaps add “IBAN” field and “Bank Name”. The WPS file will need the Bank’s routing code as well (in UAE, a 3-digit bank code, in KSA possibly the bank short code). We might maintain a doctype for Banks with codes, or just have HR input the code.

Many of these fields can be grouped under a section “Government IDs” in the Employee form. Set permissions so that only HR can see/edit sensitive fields like salary, and maybe employees can see their own visa expiry via Employee Self-Service (if enabled).

Use Notification features for expiry dates: e.g., a weekly email to HR listing any visas/passports due to expire in next 60 days. This ensures compliance with immigration rules (not directly ERP compliance, but important operationally).

3.2.3 Payroll Configuration:

1. Salary Components: Define components to reflect common earning/deduction categories:
2. Basic Salary
3. Housing Allowance, Transport Allowance, etc. (In GCC, it’s common to split salary into basic + various allowances for housing, car, etc., especially for expats.)
4. Overtime Pay – you can have a component where the amount is calculated via formula from timesheets or attendance. Alternatively, handle OT as separate “Additional Salary” entries each month computed by HR.
5. GOSI (KSA): Create two deduction components: “GOSI Employee” (10% of gross or of a defined salary portion) and “GOSI Employer” (12%). ERPNext allows marking a component as payable by Company (employer contribution) vs deduction. Mark the 12% as Company contribution so it doesn’t reduce net pay but is recorded as cost. These should only apply to Saudi nationals (expats don’t contribute except a minimal workplace injury insurance ~2%). To enforce that, use Salary Structure Assignment conditions or a custom script: if employee.nationality == ‘Saudi’, include GOSI components; else, exclude or set amount 0.
6. Pension (UAE Nationals): If the company has Emirati or other GCC national employees, they must register them with the pension authority (GPSSA in UAE) and contribute (typically ~5% employee, 12.5% employer of salary). That can be mirrored in payroll as well, similar to GOSI. Those contributions differ by emirate (Abu Dhabi has a different pension fund with slightly different rates, e.g., ADGP has 5%/15%). We can incorporate as needed.
7. End-of-Service Gratuity Accrual: Some companies choose to accrue EOS gratuity monthly (by expensing 1/12 of the annual gratuity cost). You could introduce a component “Gratuity Accrual” with a formula like: basic_salary * (if tenure <5 years, 0.583%, else 0.833%) per month – these percentages come from (21 days/365) and (30 days/365) respectively. However, this might be too granular; many just calculate at termination. So this is optional.
8. WPS allowances: If the WPS file needs a breakdown (basic vs allowances is often required in UAE’s .SIF), ensure you categorize accordingly. E.g., MOHRE wants to see Basic, Housing, etc., separately in the file. So design Salary Structure with clear components for those. The custom WPS report can then map them to the file fields.
9. Payroll Process:
10. Use Salary Structure for each category of employee if needed (e.g., different structures for expat vs local due to GOSI vs Pension differences).
11. Each month, run Payroll Entry -> create Salary Slips -> submit them. We will hook at this point to generate the WPS file:
12. After submitting payroll, run a custom server script or report “Generate WPS File”. The script will query all Salary Slips of that period, join with Employee data (to get WPS ID, IBAN, etc.), and output the text file in the specified format. We can add a button on the Payroll Entry doctype (via Customize Form) labeled “Download WPS File”. This button calls our Python method to produce the file and give it as downloadable content.
13. The .SIF format (UAE) contains sections: one header line (with company bank code, payroll date, etc.), multiple detail lines (each employee’s details), and a footer line (totals). Write the logic carefully and test against sample files. Use official guidance like MOHRE’s technical specs to ensure field positions are correct[21].
14. For KSA, do similarly based on the HRSD specs (the PDF or Oracle help can guide on columns like sequence number, employee ID = Iqama, etc.). Some banks generate the WPS file themselves when you upload salary info; but since a direct upload is common, we assume we need to generate it.
15. In both countries, after uploading the WPS, if any salaries fail (like bank rejects an account), adjustments might be needed. We should advise using Payroll Entry corrections (or manual bank transfer then re-upload). This is outside ERPNext’s automation, but at least having records helps.
16. Leave Management:
17. Configure Leave Types: Annual Leave (30 days/yr UAE, 21 or 30 days KSA depending on service – we might just set 30 for simplicity; employees in KSA won’t reach 30 until 5 years anyway), Sick Leave, Maternity, etc. Use “Max days allowed” and “Carry forward” options as per law or company policy.
18. For UAE, any unused leave must be paid out on exit (at basic salary rate). For KSA, the same (actually labor law says you compensate unused leave). We can handle this at separation: when marking an employee as Left, HR should compute unused leave and include it in final settlement. We could automate: a Final Settlement Tool could be created that reads remaining leave days from Leave Ledger, and creates a line in a final payroll (or JV) to pay that. Possibly outside current scope, but something to note.
19. Employee Self-Service:
20. If the user wants, ERPNext’s Employee Portal can allow staff to see payslips, apply for leave, etc. Given the bilingual need, we should enable Arabic in the portal as well. The employee might prefer Arabic UI. We will discuss language support below (section 5), but from HR perspective, making the system usable for Arabic-speaking staff means translating doctype labels like “Leave Application” to “طلب إجازة” etc. ERPNext translation should cover standard ones, but custom ones (like custom fields we added) we will provide translations for.
21. Performance and Contracts:
22. Although not explicitly legal, tracking probation periods (UAE law probation max 6 months, KSA 90 days extendable to 180) is practical. We can use the Probation End Date field in Employee (if not present, add it) and set a notification to remind HR to confirm or terminate employment by then.
23. Maintaining Contract documents: We can use Employee -> Contracts or attach the signed contract PDF. In KSA, ensure it’s in Arabic and submitted to MOL’s online portal (Mudad). We can’t integrate directly with those government portals (no open APIs known), so just ensure data is easily accessible for manual entry into those if needed.
24. Third-Party HR Integrations:
25. If the user decides that ERPNext’s HR is not fully sufficient (some organizations prefer specialized local payroll software), we can integrate at a minimal level. For instance, there are local payroll solutions like MenaITech or SAP SF which handle Gulf payroll intricacies. In such a case, we would disable ERPNext payroll and instead do a ledger integration: import a monthly JV from the external payroll (Debit salaries expense, etc., Credit bank/WPS, etc.). The user would use the external system to generate WPS and payslips. However, given our goal is a unified ERPNext solution, we aim to avoid this by enhancing ERPNext as above.
26. One area where a third-party might still be needed is time attendance (fingerprint or biometric systems) and HR workflows (like recruitment or performance management). If so, ERPNext offers integration points (APIs) to fetch attendance logs or push leave requests. We can use those if needed.

3.2.4 End-of-Service Processing:

Implement a standard operating procedure in ERPNext for when an employee leaves:

1. HR marks Employee as “Left” and inputs a Relieving Date.
2. Trigger a Server Script “on_change” of status to Left that:

 1- Calculates gratuity (EOSB) using the formula:

      if years_of_service < 1:
        gratuity = 0
      else:
          if resignation:
            if years<2: gratuity_pct=0
            elif years<5: gratuity_pct=1/3
            elif years<10: gratuity_pct=2/3
            else: gratuity_pct=1
          else:
        gratuity_pct = 1
    # base daily wage = basic salary / 30 (assuming 30 days month as per law)
    daily_wage = basic_salary / 30
    # first 5 years:
    amount_first5 = min(years_of_service,5) * 21 * daily_wage
    # subsequent:
    amount_after5 = max(0, years_of_service-5) * 30 * daily_wage
    raw_gratuity = amount_first5 + amount_after5
    gratuity = raw_gratuity * gratuity_pct

   (We must handle fraction of year too – include months pro-rata.)

 2- Fetch unused leave days from Leave Ledger and value them (typically at full daily wage, or basic wage depending on company policy – by default, unused leave often paid at full salary rate).

 3- Create a Final Settlement document (we may create a new DocType for this or just use a JV/Payslip). E.g., make a JV debiting “EOSB Expense” and “Leave Salary Expense” and crediting “Accrued EOSB” (if any) and “Cash/Bank” or “Employee payable” for net amount. Or generate a one-off Salary Slip for that month with only gratuity and leave encashment components.

1. This automation ensures consistency and reduces manual errors in compliance payouts.

3.2.5 Saudization and Other Compliance:

1. For KSA, track the percentage of Saudi employees. Possibly create an HR Dashboard or use a Custom Script Report: number of Saudi nationals vs total headcount, and highlight if below required percentage for the sector (Nitaqat system). While ERPNext can’t integrate with MOL to confirm compliance, giving HR this visibility helps avoid penalties.
2. Another KSA-specific requirement: companies of certain size must hire persons with disabilities at a certain ratio (each counts as more in Nitaqat). We could add a field “Disability (Y/N)” in Employee to flag and consider in the Saudization report calculation.
3. Labor Contracts Submission: In KSA, after signing an employment contract, the employer must register it on the online portal. We might generate a Standard Employment Contract print (Arabic/English) from ERPNext with all details (there’s a standard form by MOL). Then HR can use that to input online. In UAE, MOHRE requires using their system for labor contracts (which generate a unified contract). We can’t automate that, but at least store the contract number and expiry in ERPNext.

3.2.6 Government Sector HR Differences:

If the implementation extends to government or semi-government:

1. The concept of Grades/Steps: Government employees often have a grade scale. We could use the Department or Designation doctype to store a grade, or create a new DocType “Grade” and link it. Salary Structures could be per grade. This helps to automatically assign salary components if the grade changes.
2. Leave entitlements may be higher (e.g., 30 working days, etc.), and there may be airfare allowances every year or two for expatriate employees (common in public sector and some private – paying a ticket home). That can be a component accruing monthly or paying annually. We might incorporate an “Airfare Allowance” component that accumulates.
3. Training and Development tracking: not core compliance, but some government units need to track Emiratization targets and training given. Possibly out-of-scope, but mention that ERPNext has a Training doctype which can be used.

3.3 Sales, Purchasing, and Other Modules

3.3.1 Customer and Supplier Information:

Enrich the Customer and Supplier doctypes with fields for:

1. TRN/VAT Number (both UAE and KSA businesses will have this if they’re registered). Label it appropriately per country.
2. For KSA customers, perhaps a field “Customer Type” (Business or Consumer) could be useful to identify if a simplified invoice can be issued. But the law requires even B2C receipts to be e-invoiced, so likely treat all the same. Instead, maybe mark if the customer is outside KSA/UAE (to apply export tax rules).
3. Ensure addresses capture needed info: For KSA, as Odoo’s localization suggests, include Building No., Street, District, City, Postal Code, Additional No. – these are part of the official Saudi address format (per national address standard). We can customize the Address Template for KSA accordingly. In UAE, addresses are a bit less formal (no postal codes widely except P.O. Boxes), but including “Emirate” (Dubai, Abu Dhabi, etc.) is needed. We should add an Emirate field (perhaps use “State” field as Emirates, with dropdown options).
4. Default Currency for customers/suppliers: Many UAE companies have foreign suppliers in USD or Euro. Set default currency in their master so that transactions auto-pick currency and rate.

3.3.2 Sales and Purchase Workflow:

1. Quotation, Sales Order, Purchase Order formats can also be made bilingual for consistency, though not a legal must, it's professional. Government tenders often require Arabic POs.
2. If selling to government entities, might need to include their registration details on invoices. E.g., in KSA some government require the supplier’s Commercial Registration (CR) number on the invoice. We can easily add such info to print headings if needed (just by customizing letterhead or format).
3. Some free zones require a certain disclaimer on invoices if the entity is in a free zone and the supply is considered outside scope of VAT. For example, an FZE in JAFZA selling within JAFZA might stamp “VAT not applicable as supply within designated zone”. These can be handled by using Terms & Conditions section on the invoice or a custom field that toggles such a note.
4. E-Invoicing beyond Sales Invoices: Note that KSA e-invoicing rules also apply to Debit Notes and Credit Notes (they must also be electronic). ERPNext treats Sales Credit Note as just a negative Sales Invoice (via Credit Note checkbox). We must ensure our e-invoice integration also processes those. The open-source apps likely cover it (the feature list mentions support for credit/debit notes[35]). So we must not neglect return invoices in testing.

3.3.3 Record-Keeping and Audit Tools in ERPNext:

1. Enable GL Audit Trail: ERPNext by default allows editing of submitted GL entries via Repost, etc., only by admin. We might disable those abilities for normal users and encourage use of cancellation & amendment which keeps an audit trail.
2. Use Versioning on critical doctypes (Sales Invoice, Purchase Invoice, Journal Entry) so any change in draft is logged. This can help in internal audits.
3. Data Export for auditors: Create custom reports or utilize existing ones:
4. Trial Balance in Arabic – possibly by translating account names to Arabic (could maintain Arabic name in chart of accounts via translation or custom field).
5. General Ledger report – ensure it can be filtered by date and exported to Excel for auditors.
6. Stock reports – if dealing with inventory, the Ministry or ZATCA might want to see inventory logs. ERPNext’s stock ledger is useful here.
7. Attach Documents: Encourage scanning and attaching source documents in ERPNext (e.g., attach the supplier’s invoice PDF to the Purchase Invoice record). Laws often require preserving original documents; having them in ERPNext (with backups) helps fulfill that in a paperless way. UAE tax law and KSA regulations accept electronic copies as long as they are tamper-proof. ERPNext attachments are timestamped and can be made non-editable after submission (maybe remove delete permission for attachments).
8. Audit Compliance Reports: Possibly create a “Compliance Checklist” DocType or even just a Wiki page in ERPNext for the company, listing tasks like “Annual financial statements submitted to Ministry by X date – Yes/No”, “Zakat filed – attach receipt”, “WPS file submitted for month – date”. While not typical ERPNext functionality, a simple custom doctype for Compliance Tasks with date, description, responsible person, status can be helpful for the user to track obligations.

3.4 Separation of UAE vs KSA Customization and Shared Features

We aim to implement a core solution with country-specific extensions:

Common Core Features (Shared):

1. IFRS-compliant accounting framework (charts of accounts, multi-currency, financial reports).
2. Base HR features (employee master data, leave management, payroll process).
3. VAT functionality in ERPNext (the tax engine is similar for any % or rules).
4. WPS concept (generating a bank file for payroll).
5. Bilingual document capability (the approach to translations can be shared).
6. Data retention and backups – policy is essentially the same (5–7 years).
7. General system hardening for audit (logs, versioning, etc.).

We implement these once and use configuration or slight adjustments for each country:

For example, WPS file generator can be one tool that outputs UAE format if Company.country = UAE, or KSA format if country = KSA. The difference is mainly in columns and some values (UAE requires MOHRE company ID, KSA might require MOL ID, etc. – we can make those fields conditional).

UAE-Specific Implementations:

1. VAT @ 5% and specific return format (VAT201): The built-in UAE VAT 201 report suffices[34]. We ensure it's correct and perhaps adapt it if corporate tax requires any integration (not directly, since CT is separate).
2. Corporate Tax computations: only UAE has this new CT (KSA’s corporate tax is only for foreign portion and Zakat covers local portion). We might design a Corporate Tax Estimate Report for UAE – taking accounting profit from P&L, adjusting for non-deductibles (like entertainments 50% disallowed, etc., based on law), but this might be too detailed and better done by finance manually. At minimum, ensure records for depreciation, etc. are clearly available for any tax adjustments.
3. End-of-Service formula: UAE’s simpler formula (no resignation penalty) vs KSA’s conditional formula. Our EOSB script should detect country and apply relevant rules. We can store a field in Company doctype or use the Company’s country field to branch logic in the code.
4. MOHRE reporting: possibly UAE companies have to file quarterly Emiratization reports or labor accommodation reports. Not in ERP scope normally, but we could create a simple report of employees by nationality (just to assist).
5. Free Zone handling: Perhaps maintain a flag on Company (e.g. “Free Zone Company”) which triggers certain behaviors: e.g., if free zone, treat local sales as exports for VAT (0% to UAE mainland?), or mark that corporate tax might be 0%. This flag could be used in tax rule scripts or in the VAT201 report to exclude certain sales (though legally free zones still report VAT if they have it, but might have a lot of zero-rated).

KSA-Specific Implementations:

1. VAT @ 15% and Saudi return: If ERPNext doesn’t have an official KSA VAT report, we may create one (or ensure the community one is installed). It would gather total sales, exports, exempt, etc., similar to UAE but with 15% rate and any KSA-specific fields (ZATCA’s form might ask for Zakat if combined? Actually Zakat is filed separately).
2. E-Invoicing (ZATCA): Only for KSA. This is a big separate module as discussed. We will modularize it so that if Company.country == "Saudi Arabia", the e-invoice app triggers; if not, it remains inactive. That way, UAE companies won’t be affected by that overhead.
3. Zakat: Only KSA requires this. Possibly create a Zakat Calculator tool in ERPNext. This could be a simple form where the user inputs certain balances (or picks a fiscal year and the tool fetches balances of equity, non-current assets, etc.) and it computes Zakat payable. Not strictly needed if the user is comfortable doing it externally, but adding it increases value. Since open-source references (like the IFRS profile[3]) mention Zakat requiring additional disclosures, we ensure our financial statements or notes can be edited to include “Zakat base: SAR X, Zakat provided: SAR Y”.
4. GOSI and Saudization: Only KSA. So, the payroll structure with GOSI contributions will be used for KSA companies (and only applied to Saudi employees). The Saudization report likewise only relevant in KSA.
5. Language Enforcement: While both need Arabic, KSA is more stringent legally. We should possibly by default set the default print language for documents to Arabic in KSA, whereas in UAE many businesses use English as primary. For UAE, we still provide bilingual, but perhaps English can be first. In KSA, ensure Arabic is displayed first or on top as per conventions.

We will maintain separate Custom Apps or Scripts for any very country-specific logic:

1. Perhaps create two apps: erpnext_uae and erpnext_ksa to hold respective customizations (like print formats, reports, and API integrations).
2. Shared customizations (like bilingual support, base enhancements) could reside in a common app or just configured in core.

3.5 Integrations and Third-Party Tools

3.5.1 Banking Integration:

1. Instead of just outputting WPS files, we might integrate with banks via APIs for salary transfers or vendor payments. Some UAE banks (e.g. Emirates NBD) have ERP connectivity for bulk payments. If the user needs, we could build an API integration where ERPNext pushes the salary payments directly to bank (this would still produce a WPS file under the hood). However, given security and complexity, the safer approach is to generate the file and have the finance team upload it on the bank portal.
2. For customer receipts, both countries still primarily use bank transfers and cheques. Cheques could be managed via ERPNext’s Cheque Print or a custom doctype. (In UAE, post-dated cheques are common; an enhancement might be to list PDCs and their due dates, but that’s more a feature than compliance.)

3.5.2 Government Portals:

1. VAT Returns Filing: FTA (UAE) and ZATCA (KSA) have online portals where the finance team manually inputs the figures from the ERP reports. An ambitious integration would be using any available API to submit returns directly. However, currently, the UAE’s FTA doesn’t have an open API for VAT return submission (as far as known). ZATCA does for e-invoicing but not for Zakat/vat filing (which is done on their portal). So we stick to providing accurate reports for manual filing.
2. Import/Export Declarations: Some companies might want integration with customs (e.g., Saudi’s SABER or Fasah for import clearance, or UAE’s Dubai Trade). These are specialized and outside ERPNext standard. We simply ensure the ERP can record import fees, duties, etc., and perhaps attach customs docs.

3.5.3 External Payroll or HRMS:

1. As noted, if certain advanced features (like detailed employee self-service, performance evaluations, local regulatory reports) are needed, a third-party HRMS could be integrated. For example, a cloud service that handles local labor law updates might be used. Integration strategy: use APIs to sync employee master data and basic payroll results. Keep ERPNext as the primary financial system.
2. Given our approach is to empower ERPNext to do it natively, we suggest third-party only if absolutely needed. One scenario might be if the user’s company has hundreds of employees and they prefer a specialized payroll outsource (like RemotePass or Mercans, which are mentioned in sources[24]). In that case, we can plan to export necessary data from ERPNext (attendance, leave) to that system, and import the payroll journal back. Or use that system’s API to fetch results monthly.

3.5.4 Document Translation Tools:

1. If real-time bilingual data entry is a challenge, we could integrate with a translation API for descriptions. But since most items and terms will be static, better to just store translations manually. Perhaps leverage ERPNext’s Translation doctype: enter Arabic translations for all item names, UOMs, etc., so that when user switches language to Arabic, these appear. This is a built-in mechanism we can use rather than third-party.

3.5.5 Business Intelligence and Compliance Monitoring:

1. We could consider linking ERPNext to a BI tool (like Metabase or an internal dashboard) to continuously monitor compliance KPIs: e.g., “WPS not uploaded for this month – alert”, “VAT return due next week – alert if not submitted”, etc. However, this might be overengineering; simpler is to use ERPNext’s Notification and Alert framework (which can send emails based on conditions, as we plan for visa expiry, etc.) for compliance reminders too. For instance, set a notification for CFO on the 15th of the month after quarter-end: “Have you filed the VAT return for QX?”.

In conclusion, implementing these recommendations will involve a combination of ERPNext’s native features (leveraging existing UAE/KSA localization elements), custom configuration (charts, taxes, print formats), server scripts and custom apps (for WPS, e-invoicing, advanced EOSB handling), and ensuring the system environment meets legal expectations (e.g., hosting location, backups).

All custom developments should be documented and tested against actual scenarios: e.g., generate a sample VAT return and cross-verify with a known manual computation; simulate an employee leaving after 7 years with a resignation to see if gratuity matches law; validate that a generated KSA e-invoice passes ZATCA’s portal checks, etc. Because laws evolve, we’ll also set up a process to keep an eye on changes (for instance, if UAE introduces e-invoicing in the future or changes VAT rate, or if KSA changes labor law). The system should be built with flexibility to accommodate such updates – e.g., have tax rates in a doctype (already the case), or maintain EOS formulas in a script that can be quickly edited.

4. Distinct UAE vs KSA Requirements and Shared Solutions

As we design the solution, it’s important to separate country-specific functionality from shared features, to maintain clarity and ease of maintenance:

1. Accounting & Tax: Shared IFRS backbone, but VAT rates and Zakat differ. We will maintain separate tax templates and reports for each country (UAE 5% vs KSA 15%; UAE VAT201 vs KSA VAT return). The Zakat module will be only activated for KSA companies. In ERPNext, we might achieve this by checking the Company’s country in scripts or by only installing the Zakat app for KSA companies. Shared aspects like multi-currency, account structure, and financial statement logic can remain common.
2. HR & Payroll: The WPS module will have conditional logic per country (different file layouts). Gratuity calculation as noted will branch for UAE or KSA rules. Most other HR pieces (leave, attendance) are common, but we’ll incorporate conditionals where needed (e.g., only KSA employees get GOSI, only UAE nationals get GPSSA). Documentation for HR users should clearly outline: “If you are using the KSA instance, note X, Y, Z differences” and similarly for UAE.
3. E-invoicing: Entirely a KSA-specific extension currently. We encapsulate it in a module so it doesn’t interfere with UAE operations. For example, UAE users don’t need to see ZATCA menu items or deal with digital signatures when saving invoices. We ensure these triggers only attach to KSA company’s transactions. Perhaps the app could detect company country at install and self-disable if not KSA. If down the line UAE implements e-invoicing, we could extend the same framework but with FTA requirements (likely similar, but so far not announced).
4. Language and Localization: Both require Arabic support, but perhaps the degree differs (KSA mandates Arabic on all external docs by law, UAE encourages but not strictly mandated for private dealings). So, we will implement full bilingual capability for both, but enforce Arabic as default output for KSA. We can have two sets of print formats if needed, or one dynamic print format that adjusts headings language based on company/country.
5. Compliance Reporting: UAE has things like Economic Substance Regulations (ESR) and Ultimate Beneficial Owner (UBO) filings for certain companies, whereas KSA has Saudization reporting. These are outside ERP but if needed, we could provide data to help (like list of legal entities and whatnot). However, that’s probably beyond ERP scope.

A good practice will be to maintain a configuration file or doctype called “Regional Settings” for each company, where we can tick options like “Apply KSA Labor Law” or “Apply UAE VAT Law” etc. But since country is already a field, that may suffice for branching logic in code.

Documentation and training materials delivered to the user should have separate sections for UAE and KSA to avoid confusion. For example, an end-user guide: “How to process payroll – UAE” vs “Payroll – KSA” highlighting the differences (like additional GOSI step in KSA, etc.).

5. Bilingual (English/Arabic) Implementation Guidance

Supporting both English and Arabic in the ERP interface and outputs is crucial for user adoption and legal compliance. Here’s how to achieve robust bilingual support in ERPNext:

1. ERPNext UI in Arabic: ERPNext comes with an Arabic translation for most standard terms. In System Settings, set up Available Languages to include Arabic (ar) and English (en). Users can then select their preferred language in their user profile. For Arabic:
2. The UI will flip to right-to-left (RTL) layout automatically for Arabic locale. Verify this in a test user account. Some custom pages or apps might need additional CSS to fully align RTL (we should test forms and reports after enabling Arabic to fix any alignment issues).
3. Ensure our custom field labels and custom DocType names are translated. Since we’ll add fields like “Visa Expiry”, we should provide Arabic equivalents (“انتهاء صلاحية التأشيرة”). We can do this by adding entries in the Translation doctype (or a CSV) with language = Arabic, source text = “Visa Expiry”, target text = that Arabic. Alternatively, name the custom field with an Arabic label directly if the user base is primarily Arabic. But best to keep English internally and use translations for flexibility.
4. The date, number formats can remain as is (most GCC companies use Western numerals even in Arabic docs). But if needed, we could apply an Arabic locale for dates (to show Arabic month names). This is not strictly required legally; Arabic language with Gregorian dates is acceptable.
5. Documents in Arabic and English: For official documents like invoices, purchase orders, payslips, etc., we recommend dual-language formats:
6. One approach is to have two columns in the print format table for each field (one English, one Arabic). E.g., an invoice line description could show “Description (الوصف)” as heading, and each item shows English name / Arabic name.
7. Alternatively, show English and Arabic text in one line separated by a slash or newline.
8. Use clear fonts that support Arabic. The built-in PDF generator usually uses a font that has Arabic glyphs, but if not, we might need to specify a web font (like Google Noto Kufi or Arial Unicode). We can embed CSS in print format to use a suitable font for Arabic sections.
9. We must not put the 【...†embed_image】 syntax for images here as it’s not relevant; instead, ensure the company logo (if any) on letterhead has both English & Arabic or a bilingual logo.
10. For terms and conditions or long text that need bilingual, consider maintaining two versions. For instance, create a Terms and Conditions record for “Invoice Arabic” containing the standard legal text in Arabic (like “This is a tax invoice…” translated). Then in the print format, render both English and Arabic terms.
11. Data Entry in Arabic: There may be fields where data itself should be stored in Arabic, e.g., employee names for government forms, or item names if the business is Arabic-first. We have options:
12. Use one field with English and Arabic together (not great for searching).
13. Use two fields: e.g., “Name (English)” and “Name (Arabic)” as custom fields on Customer, Item, etc. Then in forms, show both. The user can fill both. This is explicit but requires duplication in entry.
14. Use ERPNext translation: If the user interface is switched to Arabic, ERPNext can display certain values in translated form if a translation is provided. But that mostly applies to system labels, not user data. There is a feature for translating Item names: in the Item doctype, you can maintain translations of item name/description for different languages (via the Translation doctype or by uploading a CSV). Then, if you print an invoice while user’s language is Arabic, it will print the Arabic name of the item. This is a neat feature to exploit:
15. We can maintain a custom translation file for all Item names and perhaps UOMs. But for things like customer names, those are proper nouns – better to store bilingual directly if needed.
16. Considering the complexity, a pragmatic approach: Store critical master data in both languages. For example, add custom fields for “Arabic Name” on Customer and Supplier. For items, maybe translate via the built-in mechanism because an item might have one name and a clear Arabic equivalent. For addresses, have an address line in Arabic if needed.
17. Printing RTL correctly: Ensure that in the print format HTML, whenever we have a block of Arabic text, we set dir="rtl" on that container (e.g., <div style="text-align: right" dir="rtl">). This will order the words properly. Without it, Arabic text might appear but in wrong direction or punctuation oddly placed.
18. We should test printing an invoice with a lot of Arabic content to see if the PDF generation handles line wrapping correctly. Sometimes, PDF generators can misplace diacritics or join letters incorrectly. If that happens, we might switch to using an image for the Arabic text (less desirable), or ensure the chosen font is robust.
19. User Training: Some staff may prefer using the ERP in English but need outputs in Arabic. We will provide simple toggles: for instance, we can add a custom print format parameter where the user can choose language for the print. Alternatively, create two print formats (Invoice-ENG and Invoice-AR). But maintaining two is extra work. A dynamic single format that shows both languages is easiest for compliance (no chance of accidentally giving an English-only invoice to a Saudi customer).
20. Arabic Numerals: Typically, even Arabic documents in Gulf use “Arabic digits” which are actually Western (0,1,2…). They don’t usually use the Eastern Arabic numerals (٠١٢...). We will use Western digits to avoid confusion, as is common in invoices and financials in UAE/KSA. If required by a government form to use Eastern numerals, that could be done by a font that displays digits as Eastern, but likely not needed.
21. Language in HR documents: Offer employment contracts and letters in bilingual form. We can create Letter Templates in ERPNext (using Jinja to pull employee data) for things like salary certificates, NOCs, etc., with both languages. This is more a value-add for the user.
22. System Messages and Errors: If Arabic-only users will use the system, consider translating custom validation messages or error texts. E.g., if a user tries to submit an invoice without a TRN for a customer, we might show: “Customer VAT ID is required – يجب إدخال الرقم الضريبي للعميل”. We can either concatenate both languages in one message or detect user language and show one. Doing both might be simplest to ensure clarity.
23. Support RTL in the web portal: The Employee and Customer web portals should be checked in Arabic mode to ensure menus align right, etc. Frappe generally does a decent job, but custom web pages (if any) should be adjusted.

By implementing the above, ERPNext v15 will be fully bilingual: users can operate in their preferred language, and all outputs that go to external parties (invoices, payslips, etc.) will be in both languages as needed. This not only meets legal needs (especially in KSA where Arabic is a must) but also makes the system accessible to Arabic-speaking accountants, HR officers, and employees.

Conclusion: With these in-depth configurations and customizations, ERPNext 15 will be transformed into a UAE/KSA-ready ERP system. It will handle IFRS accounting with local tax compliance (VAT, corporate tax, Zakat), enforce labor law rules in HR (working hours, leave, WPS, end-of-service), produce documents and reports that meet government standards (invoice formats, bilingual content, audit trails), and integrate with necessary government systems (like Saudi e-invoicing via ZATCA API). We leveraged open-source modules and community knowledge to accelerate development – from VAT reporting tools[32] to full-fledged ZATCA integration apps[35] – ensuring that we are not starting from scratch but building on proven solutions. The result will empower the user to confidently deploy ERPNext for businesses in the UAE and Saudi Arabia, knowing that legal compliance and localization are thoroughly addressed.

All the above recommendations should be implemented with careful testing and user training. Once live, the user should also stay updated on law changes (for instance, any new UAE decisions on e-invoicing, or changes in Saudi GOSI rates, etc.) and update ERPNext configurations accordingly – but the groundwork laid out in this research provides a solid, extensible foundation for ongoing compliance in both jurisdictions.