Field notes · Saudi Arabia · 8 minute read
Qiwa quota rules: what new Saudisation regulations mean for SAP customers.
Saudi Arabia's labour-market platform has tightened the Nitaqat bands and added new compliance checks at Qiwa. For SAP customers running SF and ECP in KSA, this is master data, reporting, and hire-workflow work. Here is what to plan around.
What changed in 2026
Saudi Arabia's Ministry of Human Resources and Social Development has updated Qiwa, the Ministry's workforce platform, with tighter Nitaqat band structures, new sector classifications, and stricter real-time visibility into employer compliance. [VERIFY: specific date of the 2026 regulation update and the exact band threshold changes against the published Ministry circular.]
The headline shifts that matter to a SuccessFactors customer:
Nitaqat
Tighter bands
The threshold at which an employer moves from one band to the next has shifted. [VERIFY: percentage changes per band.]
VerifySectors
Re-classification
Several sectors have been split or merged, which changes the Saudi quota an employer is measured against. [VERIFY: affected sectors.]
VerifyHiring
Real-time hire validation
New non-Saudi hires are validated against the employer's current Saudisation position at the moment of work-permit issue, not after the fact.
BlockingCounting
Higher-skill-tier weighting
Certain Saudi roles count for more in the calculation depending on skill classification. [VERIFY: weighting rules per skill tier.]
VerifyAll of this lives in Qiwa. None of it lives in standard SuccessFactors. That gap is where the configuration work happens.
How Qiwa enforces it
Qiwa is not just a portal. It is the integration point for work-permit issuance, employment-contract registration, and Nitaqat reporting. Three flows matter to a SAP customer.
Exhibit · Integration flow
Qiwa clears every non-Saudi hire before the work permit issues
The compliant Nitaqat position must hold before SuccessFactors can commit the offer.
SuccessFactors EC
Employee master and Recruiting
Pre-offer Qiwa gate
Raptors-configured check and write-back
Qiwa (MHRSD)
Work permits and Nitaqat
SuccessFactors EC
Employee master and Recruiting
Pre-offer Qiwa gate
Raptors-configured check and write-back
Qiwa (MHRSD)
Work permits and Nitaqat
What runs through the channel
Source: Saudi MHRSD Qiwa platform, 2026 Nitaqat update. [VERIFY: regulation date, band thresholds, and re-classified sectors against the published Ministry circular.]
Registration
Employee master registration
Every employee, Saudi or non-Saudi, is registered against the employer's Qiwa entity. The SF record is not Qiwa's source; the relationship runs the other way.
Authorisation
Hire authorisation
A new non-Saudi hire needs a compliant Nitaqat position at the moment of work-permit issuance. Out of band, and the work permit is blocked.
BlockingReporting
Continuous reporting
Headcount, role, contract type and salary report back to Qiwa periodically. Mismatches against the employer's actuals are flagged.
Impact on SuccessFactors master data
The SF Employee Central record was not designed for Qiwa's data model. To stay in compliance, the master data needs to carry the attributes Qiwa expects, and those attributes need to be maintained at hire and on every status change.
Identity
Nationality and equivalency
Standard SF carries nationality. Qiwa needs the specific equivalency category (Saudi, GCC, other expat tiers) that drives Nitaqat counting.
Taxonomy
Skill and role classification
The Saudi role-skill tier is not free text. It maps to Qiwa's published taxonomy. Configure the lookup; do not let it drift.
Contract
Contract type and duration
Fixed, indefinite, project-based. Qiwa counts each differently in the band calculation.
Entity
Sector classification
After the re-classifications, some legal entities now sit in a different sector. Re-tag the entity in SF and confirm against Qiwa before the next reporting cycle.
Impact on Recruiting workflows
The single biggest workflow change. Under the new rules, a non-Saudi hire cannot be committed without a compliant Nitaqat position. That means the recruiting workflow needs a Qiwa check before offer, not after.
The pattern we configure:
Pre-offer compliance check
Before an offer reaches a non-Saudi candidate, the system queries the employer's current Nitaqat position. If the hire would push the employer out of band, the offer is blocked or escalated.
Saudi-first routing
Where the role-skill tier needs a quota-eligible Saudi hire, the workflow prioritises Saudi candidates and surfaces the compliance implication of going outside the pool.
Real-time Qiwa write-back
Once a hire is committed in SF, work-permit registration in Qiwa fires synchronously. A delay between the SF hire date and the Qiwa registration is the most common compliance gap we see.
Under the old rules we could fix a Saudisation mismatch in the quarterly report. Under the new rules the offer itself gets blocked. That changes who is in the workflow.
Impact on reporting
The reporting side is what most KSA enterprises hit second. Once the master data is right and the recruiting workflow is tightened, the question is: can the HR director answer "what is my Nitaqat band today" without a spreadsheet?
Dashboard
Live Saudisation dashboard
A real-time read against SF master data, calculated with Qiwa's current band rules. The number that matters is where we land at quarter-end if nothing changes.
Projection
Hire pipeline projection
Open positions by Saudi or non-Saudi, projected forward: does the planned hire mix keep the employer in band? The question line managers need answered before approving an offer.
Reconciliation
Quarterly reconciliation
The Qiwa-reported number against the SF-calculated number. Mismatches are caught here, before the regulator does.
Three implementation calls
What we have seen go right and wrong when KSA enterprises absorb the new rules:
Keep the equivalency taxonomy controlled, not free text
The attributes that drive Nitaqat counting are a controlled vocabulary. Build the picklist in SF, lock the values, align them to Qiwa's current taxonomy, and refresh quarterly.
Build the pre-offer check before you re-train recruiters
If the system does not block a non-compliant offer, the recruiter's memory is the weakest compliance posture. Make the system the authoritative gate.
Plan for sector re-classification
If your entity has moved sector, historical Saudisation calculations against the old classification are no longer the regulator's measure. Run both bands in the dashboard during the transition. [VERIFY: sectors re-classified in 2026.]
Where to start
Three concrete moves for any KSA enterprise running SF + ECP in the wake of the 2026 changes:
Audit the master-data attributes
Nationality equivalency, role-skill tier, contract type, entity-sector classification. Fix gaps before the next reporting cycle.
Wire the pre-offer Qiwa check
Add it to your Recruiting workflow. The cost of building it is small; the cost of a blocked work permit on a senior hire is large.
Build the live Saudisation dashboard
So the HR director and the country manager look at the same number, in the same place, against the current Qiwa band rules, not a copy from last quarter.
None of this is hard. All of it is configuration, picklist discipline, and integration plumbing. The failure mode we see most often is leaving the Saudisation calculation outside SF: in a separate spreadsheet, in a separate report, against a different cut of master data. Bring it inside the tenant. Make the SF record the authoritative source. The compliance posture follows from that.
Next step