A Saudi payroll run is no longer one number reaching one bank. The same employee's pay has to agree across three separate government systems at once: the contract registered in Qiwa, the wage recorded at GOSI, and the actual bank transfer reported through Mudad under the Wage Protection System. Where those disagree, the mismatch is flagged automatically.
That is the design constraint anyone building or integrating HR and payroll software for Saudi Arabia has to start from. It is not a reporting requirement bolted onto the end of the run. It is a consistency requirement that reaches back into how you model employment itself.
Engineering context, not legal or payroll advice. Thresholds, deadlines and obligations are set by MHRSD, GOSI and SAMA, and should be confirmed with them or with qualified advisers.
The four systems and what each one holds
Qiwa — the Ministry of Human Resources and Social Development platform for labour contracts and employment. It holds the employment relationship: who is employed, on what contract, at what stated wage. It also feeds Saudization classification.
GOSI — the General Organization for Social Insurance. It holds the wage on which contributions are calculated, and the contribution records themselves.
Mudad — the digital payroll and wage protection platform, launched by MHRSD in partnership with the Saudi Central Bank. It is where payroll is processed and WPS reporting happens, connected to approved Saudi banks.
WPS — the Wage Protection System itself: the mechanism ensuring salaries are paid in full, on time, through authorised Saudi banks.
The relationship worth internalising is that Mudad is the point where the other three meet. Salary data flows into GOSI to validate contributions, and Mudad data feeds Saudization classification and labour compliance reporting. Mudad cross-references wage data against GOSI records and Qiwa contract registration. An employee whose Qiwa contract, GOSI wage and actual bank transfer do not agree is flagged automatically.
What three-way agreement does to your data model
Most payroll systems built elsewhere carry a single notion of "salary" and a pile of adjustments layered on top. That model does not survive contact with this environment, because the three systems are asking about three different things and your system has to be able to answer each precisely.
Separate contractual wage from paid amount from contributory wage. These coincide in the simple case and diverge constantly in the real one — unpaid leave, mid-month joiners, end-of-service, allowances that count towards contributions and allowances that do not. If your schema has one salary column, every divergence becomes a manual correction, and manual corrections are what produce flags.
Model the contract as a versioned entity with effective dates. A raise is not an update to a number; it is a new state of the employment relationship with a date from which it applies, which has to be reflected in Qiwa and will change what GOSI expects. Overwriting the previous value destroys your ability to explain a historical payroll run — and explaining historical runs is precisely what an audit asks for.
Give every employee a stable identity that matches the government record. The join key across these systems is the national ID or Iqama number. If that field is free text, optional, or duplicated across records, reconciliation is impossible. Validate it at entry, make it unique, and treat a change to it as a significant event rather than a field edit.
Keep the bank details that were actually used for each payment, not just the current ones on the employee record. When a transfer is queried months later, "the account we have on file today" is not the answer to the question.
Build the reconciliation, do not hope for it
The single most useful thing a Saudi payroll integration can do is check agreement before submission, not after rejection.
Concretely: before a WPS file goes out, assert for every employee that the contract in Qiwa, the wage at GOSI and the amount about to be transferred are consistent — or that the difference is explained by a reason your system can name (unpaid leave, a mid-period start, a recorded deduction). Anything unexplained gets surfaced to a human before the run, with the specific discrepancy shown.
This is a meaningfully different product from one that submits and then displays whatever the platform says. It is also the feature payroll teams will notice, because the alternative — discovering a mismatch after the fact — costs far more to unwind than to prevent.
Two practical points about timing. WPS files must be submitted on or before the salary payment date, so the reconciliation has to run early enough to leave time to fix what it finds; a check that runs at submission is a check that runs too late. And payroll is monthly and unforgiving: there is no "we will catch it next sprint" when the next opportunity is thirty days away and the consequence is a compliance flag.
Integration realities
Access is the long pole, as everywhere in this ecosystem. These are not open APIs. Expect a registered local entity, a stated use case and an approval process with the operating authority, planned in months rather than weeks. The pattern is the same across Saudi government platforms and is covered in what you can actually get access to.
Bank connectivity is a separate integration with its own rules. WPS runs through authorised Saudi banks, and each bank's file format, cut-off times and failure handling are their own problem. Do not model "send to Mudad" and "money moves" as one step.
Arabic is not optional in this data. Employee names arrive and must be reported in Arabic. Storage, collation, rendering and PDF output all need to handle it properly, and a payslip that mangles an employee's own name is a visible failure.
Everything here is personal data, including wage data, which is sensitive by any reasonable reading. Retention, access control and audit logging need deciding at design time, not retrofitted — see Saudi PDPL for application architecture, and Saudi cloud data residency for where it may physically sit.
Payroll and invoicing are separate obligations. A company in scope for WPS is very likely also in scope for ZATCA Phase 2 e-invoicing, on a different timetable with different systems — Wave 25 closes on 1 February 2027. Teams that discover this as two projects rather than one usually discover it late.
A note on buying versus building
For a single company with straightforward employment arrangements, an established Saudi payroll product that already holds these connections is usually the right answer, and a good development partner will say so.
Building is justified when payroll is inside a product you sell, when the employment model is genuinely unusual — seasonal Hajj and Umrah operations are a standing example, covered in Hajj and Umrah software — or when payroll has to be driven by operational data — shift systems, project time, field attendance — that no off-the-shelf product sees. In that case the integration surface is the four systems above plus the bank, and the reconciliation described earlier is the core of the product rather than a feature of it.
Frequently asked questions
What is Mudad?
The digital payroll and wage protection platform launched by MHRSD with the Saudi Central Bank. It processes salary payments, handles WPS reporting and connects to GOSI, Qiwa and approved Saudi banks.
How do Qiwa, GOSI and Mudad relate?
Qiwa holds the employment contract, GOSI holds the contributory wage, Mudad handles payroll and WPS and cross-references the other two against the actual transfer. Disagreements are flagged automatically.
When must a WPS file be submitted?
On or before the salary payment date. Confirm the specifics for your establishment with MHRSD or Mudad.
Why is an employee being flagged when we paid them correctly?
Usually because "correctly" is true against one system and not another — a raise applied in payroll but not registered in Qiwa, or an allowance treated differently for GOSI. The fix is reconciliation before submission.
Can one system be the source of truth?
Internally, yes, and it should be. But it has to be able to produce each government system's view of an employee, which means holding contractual, contributory and paid amounts as separate facts.
Do we need a Saudi entity to integrate?
Expect one. Access to these platforms generally requires a registered local entity and an approved use case.
Is this the same project as ZATCA e-invoicing?
No. Different platforms, different obligations, different deadlines. Many companies are in scope for both.
Should we build or buy?
Buy for a normal company with normal employment. Build when payroll is part of a product you sell, or is driven by operational data an off-the-shelf product cannot see.
Sources
- Mudad
- Qiwa
- GOSI — General Organization for Social Insurance
- Ministry of Human Resources and Social Development
- Saudi Central Bank (SAMA)
The interoperability described here is corroborated across several payroll-platform sources rather than a single regulator document. Treat the three-way reconciliation as the shape of the system, and verify thresholds, deadlines and your own obligations directly with MHRSD, GOSI and Mudad.