WPS & Mudad Payroll Integration with Odoo (Saudi Arabia)

WPS — the Wage Protection System — is how every Saudi employer above the GOSI registration threshold pays salaries. The mechanism is a Salary Information File (SIF) lodged through Mudad, validated by SAMA, and disbursed by employee banks. When the SIF lines up cleanly with the contracts on Qiwa and the contributions on GOSI, payroll is a 15-minute monthly task. When it doesn't, it becomes the most expensive HR fire-drill in the calendar.

This guide walks through how iWesabe configures Odoo HR + Payroll so that the Mudad SIF is generated natively from the same employee dataset used by Nitaqat and GOSI — no bridging spreadsheets, no re-keyed IBANs, and a same-day path for the inevitable bank rejection that arrives at 09:00 on transfer day.

What is WPS and how does Mudad sit on top of it?

WPS is the regulatory framework — employers must pay employees electronically to a Saudi bank account within a specified window each month. Mudad is the operational platform run under HRSD that delivers the SIF to participating banks via SAMA's settlement layer. Inside Odoo, the work is producing a SIF that conforms to the current Mudad schema and matches the employee + contract records on Qiwa, to the riyal.

How is Odoo Payroll configured to generate a Mudad-ready SIF?

Odoo Payroll ships with a configurable rules engine — earnings, deductions, GOSI bases, end-of-service accrual — but the Mudad SIF schema is KSA-specific. The configuration work is encoding the SIF column structure, mapping each Odoo payslip line to its SIF position, and adding validation rules that block the file from generating if any required field is missing.

1. Make IBAN a validated, single-source field

Every employee's IBAN must pass the Saudi IBAN check-digit validation before the record can be saved. We add the validator at the employee form level so a wrong IBAN can never enter payroll in the first place. This single rule eliminates the most common rejection reason at the bank.

2. Encode the SIF-aligned salary structure

Mudad's SIF expects specific components — basic salary, housing allowance, other allowances, deductions, and net pay — in fixed positions. We build the Odoo salary structure so payslip lines map 1:1 to SIF columns. Anything earned outside the structure (one-off bonuses, leave encashment) routes through a deliberate SIF mapping rule, never an ad-hoc adjustment.

3. Add the Mudad-format SIF export action

A single button on the payroll cycle closes the period, generates the SIF in Mudad's expected character set + line terminator + column order, and locks the cycle against further edits. We sign the file with a checksum line so any manual tampering between Odoo export and Mudad upload is detectable on the lodgement screen.

How does Odoo reconcile WPS against GOSI in the same cycle?

GOSI contributions are calculated on a defined base — generally basic salary + housing allowance — and the employer share + employee share must match what was actually paid through Mudad. A mismatch surfaces as a GOSI portal warning that takes weeks to resolve once it has built into a backlog. Odoo runs the reconciliation inside the same close cycle, before the SIF is even exported.

1. Eligible-base calculation: Odoo derives the GOSI base per employee from the salary structure — the same fields that produce the SIF amounts. One source, two outputs, zero drift.
2. Contribution register: a per-employee register lists the employer share + employee share + total contribution, summed at the establishment level. The total must reconcile against the GOSI portal balance for the period before close.
3. WPS-vs-GOSI delta report: a single Odoo report shows any per-employee gap between the SIF gross and the GOSI eligible base — typically zero, but instantly visible when a one-off payment was routed incorrectly.

Spreadsheet payroll vs Odoo + Mudad — what is the operational difference?

Many KSA SMEs still build payroll in Excel and export a SIF by hand each month. That works at 10 employees and breaks at 50. The table below compares spreadsheet-based payroll against an Odoo HR + Payroll setup configured the way iWesabe deploys it for KSA clients.

The operational lever is consistency. A spreadsheet payroll works until the cycle that does not — and the absence of an audit trail makes the next month's cleanup expensive. Odoo's value is that every cycle looks the same, every variance is visible, and every correction is logged against the named user who made it.

Which WPS KPIs should the payroll lead see every cycle?

Once Odoo is generating the SIF natively, four KPIs are enough to keep the payroll cycle inside a safe operating envelope month after month.

The fifth KPI we maintain — not in the stat block but on the payroll dashboard — is rejection recurrence by employee. The same IBAN failing two cycles in a row points to a stale bank record, not a one-off — and the cheapest moment to fix it is before the third cycle compounds the backlog.

What are the most common WPS/Mudad failure modes Odoo prevents?

Five failure modes account for nearly every WPS issue iWesabe has remediated in Saudi Arabia. Each is preventable when payroll is run from a configured Odoo instance instead of a spreadsheet + ad-hoc SIF generator.

• Invalid IBAN at the bank. Manual entry without a check-digit validator routinely produces typos that pass Mudad validation but fail at the bank. The fix is upstream — never let an invalid IBAN save in the first place.
• Mismatched name between SIF and bank record. The bank rejects when the employee name on the SIF differs even slightly from the registered account name. Odoo enforces a single canonical name field used by Qiwa, Mudad, and the contract.
• Out-of-period salary corrections. A correction processed after the SIF has been lodged creates a GOSI mismatch in the next cycle. Odoo blocks payslip edits after cycle close so corrections always route through a properly dated next-period adjustment.
• One-off bonuses outside the salary structure. Routed through a free-text adjustment they break the WPS-vs-GOSI reconciliation. Routed through a configured rule with explicit GOSI treatment, they don't.
• Late lodgement past the Mudad window. Delayed cycles trigger HRSD penalties and visible compliance flags. Odoo schedules the close + lodge sequence as a calendar item so the cycle never runs ad-hoc.

“A clean WPS cycle is the most boring thing in a Saudi payroll calendar. That is the goal.”

WPS is not a monthly emergency — it is a 15-minute regulatory event when the underlying data is clean and the cycle order is right. Odoo HR + Payroll, configured for KSA the way iWesabe deploys it, converts payroll from a recurring fire to a routine cycle the CFO can ignore on every normal month.

iWesabe has configured this Odoo setup for KSA establishments across construction, retail, manufacturing, healthcare, hospitality, and services. If you are running payroll in a spreadsheet today, or fighting recurring bank rejections, a 60-minute call is enough to scope the migration.

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

Related Articles

Compliance

Nitaqat & Saudisation Compliance with Odoo HR (KSA)

How KSA employers stay in the green Nitaqat band — automating headcount ratios, Qiwa filings, and Mudad payroll inside one Odoo HR setup.

Implementation

Odoo ERP Go-Live in Saudi Arabia: A 2026 Readiness Playbook

How Saudi enterprises ship Odoo cutovers that pass ZATCA, VAT, and GOSI on day one — and what the eight-step readiness plan actually contains.

Compliance

Odoo + ZATCA E-Invoicing Compliance in Saudi Arabia

Fatoora integration, cryptographic stamps, and the Phase 2 conformance checklist.