Odoo HR & Payroll for Saudi Arabia: The Complete Setup Guide

Out-of-the-box Odoo HR works well for generic payroll. Saudi Odoo HR is a different configuration task — GOSI contributions with nationality-split rates, WPS-compliant Mudad bank files, Qiwa portal synchronisation, Nitaqat Saudisation tracking, and end-of-service gratuity accruals under Saudi Labor Law each require specific setup decisions that the standard installation does not make for you. Getting them wrong in month one compounds into reconciliation backlogs and regulator friction that persist long after go-live.

This guide is the configuration reference iWesabe applies on every Saudi Odoo HR rollout. It covers module scope, the Saudi payroll rules that differ from international defaults, the GOSI setup protocol, government-portal connections, EOSB accrual mechanics, and the go-live readiness checklist. For the regulatory background — what GOSI, WPS, Qiwa, and Nitaqat actually require — see the companion guide on Saudi HR compliance.

What does Odoo HR cover for Saudi businesses?

Odoo HR for Saudi Arabia is not a single module — it is a cluster of six inter-dependent apps that, when configured together as a Saudi-localised stack, covers the full employment lifecycle from hire to end-of-service. The table below maps each app to the Saudi-specific function it serves. You only need the apps that match your business model, but the payroll-GOSI-time chain is non-optional for any Saudi entity with salaried employees.

Saudi payroll configuration — what goes beyond the standard Odoo setup?

Standard Odoo payroll assumes a single gross salary or a basic + simple-addition structure. Saudi payroll has five structural requirements that are either absent from the international default or present but misconfigured for the KSA context. Each one must be explicitly decided and locked at salary-structure level before the first payroll run — not adjusted retroactively month by month.

1. Three-part allowance structure: basic + housing + transport. Saudi salary packages separate these three components because they have different GOSI treatment (basic and housing are contributable; transport is not) and different leave encashment bases (annual leave encashment uses basic salary only). Collapsing them into a single field corrupts downstream calculations silently.
2. GOSI contributable-base formula at salary-structure level. The GOSI contributable base is basic salary + housing allowance — not total compensation. This formula must be baked into the salary structure so every new hire inherits it automatically. Any allowance type added later defaults to non-contributable unless explicitly classified; this is the right default and the one to preserve.
3. Nationality-category contribution rates. GOSI contribution rates differ by nationality category: Saudi nationals (and GCC nationals under the reciprocal agreement) carry the full combined rate — currently 9% employee + 13% employer (pension + unemployment + occupational hazards). Non-GCC nationals carry employer-only occupational hazard contribution. These live as named payroll structures the employee record inherits by nationality field — never entered manually per employee.
4. WPS-compliant Mudad bank file output. Saudi Labor Law requires payroll disbursement through the Wages Protection System (WPS), with Mudad as the Ministry of Human Resources platform that validates compliance. Odoo must be configured to generate the Mudad-formatted SIF (Salary Information File) at each payroll run. The file carries each employee's IBAN, net salary, and payment date — with the SAMA-format IBAN mandatory for validation acceptance.
5. End-of-service benefit (EOSB) accrual as a running provision. Saudi Labor Law Articles 84–87 mandate a gratuity calculation based on tenure and exit reason. Odoo must accrue this as a monthly provision in the payroll journal entries — not as a lump-sum recognised only at termination. Accruing monthly produces accurate balance-sheet provisions and prevents surprises at the EOSB payment event.

GOSI contribution setup — getting the calculation exactly right

GOSI contribution errors are the most expensive payroll misconfiguration in KSA — SAR 80–200 per employee per month adds up quickly on a 100-employee payroll. The three-variable interaction (contributable base × nationality rate × monthly ceiling) must be correct simultaneously. The table below is the reference iWesabe uses when validating GOSI setup on any new Saudi rollout.

Connecting Odoo HR to Saudi government portals — Qiwa, WPS/Mudad, and Muqeem

The Saudi government portal landscape is four platforms that HR must synchronise with, each on its own data set and timeline. Treating them as one integration problem causes configuration errors — they have different API endpoints, different data models, and different update cadences. The table below is the four-portal map iWesabe uses during Odoo HR architecture sessions with Saudi clients.

The architecture decision that matters most here is event-driven vs batch for Qiwa. iWesabe configures Qiwa sync as event-driven at the employee-record level — a Qiwa API call fires on every save where a Qiwa-relevant field changed. The daily reconciliation sweep catches any drift that slipped through. Batch-only Qiwa sync (monthly or weekly) is the most common cause of Qiwa lag that surfaces as work-permit delays.

End-of-service benefit (EOSB) — how Odoo handles the Saudi gratuity calculation

Saudi Labor Law Articles 84–87 create a mandatory gratuity obligation that accrues from day one of employment. The calculation formula is well-defined but depends on three variables that Odoo must track correctly: the employee's basic salary at termination (not historical average), exact tenure in completed years and fractional months, and the reason for exit — which determines the percentage the employee receives.

1. Years 1–5: half a month's basic salary per year. An employee completing exactly three years is entitled to 1.5 months basic salary, regardless of exit reason. Odoo calculates this from the contract start date stored in the employee record — fraction-of-year rules apply if the employee leaves mid-year.
2. Year 5 onwards: one full month's basic salary per year. After five completed years the rate doubles. An employee leaving after eight years is entitled to: (5 × 0.5) + (3 × 1) = 5.5 months basic salary. Odoo handles the tenure-band transition automatically when the salary structure is correctly configured.
3. Exit reason adjusts the entitlement. Termination by employer: full entitlement for any tenure. Resignation: 0% for under 2 years; 33% for 2–5 years; 67% for 5–10 years; 100% for over 10 years. Exit reason must be a mandatory field on the termination form — not entered as a free-text note — for the correct entitlement to calculate.
4. Monthly accrual provision in payroll accounting. Configure Odoo to post a monthly EOSB provision journal entry equal to the current month's accrual (1/12 of the annual entitlement at current basic salary). This keeps the balance sheet accurate and prevents EOSB from appearing as a one-period expense shock. The provision account clears against the EOSB payment at termination.

What does a production-ready Saudi Odoo HR go-live look like?

A Saudi Odoo HR go-live is ready when four bands are in the green simultaneously. None of these is a "nice to have" — each one maps directly to a regulator, a payroll obligation, or an operational exposure. The stat-block below is what iWesabe signs off on before recommending a client proceed to first live payroll run.

Odoo HR for Saudi Arabia is not a generic HR deployment with a localisation patch layered on top. The five payroll configuration decisions, the GOSI three-variable setup, the four-portal connection map, and the EOSB accrual mechanics are each structural choices that must be made correctly at deployment. Made correctly, they compound — six months into go-live the HR team is running clean payroll, reporting to regulators without reconciliation marathons, and building the labour-data foundation that Finance and Operations depend on.

iWesabe has configured Odoo HR & Payroll for Saudi enterprises across manufacturing, construction, distribution, retail, healthcare, and professional services — from 25-employee single entities to multi-entity groups with operations across multiple cities. If you are planning an Odoo HR rollout in KSA or already live but seeing GOSI mismatches, WPS rejections, or Qiwa lag, a focused 90-minute call is enough to identify the configuration gaps and the order to close them.

iWesabe Editorial Team

Practitioner insights on Odoo ERP, ZATCA compliance, and Saudi enterprise digital operations — written by iWesabe's consulting, finance, and engineering teams.

About iWesabe