Let’s Start with the Questions Everyone Is Asking

When the General Organization for Social Insurance (GOSI) introduced Maternity Compensation, two immediate questions come up in every discussion:

“If GOSI pays the employee… why don’t we just stop salary or reverse it?”
“And why is GOSI paying the employee directly, not the employer?”

Both questions are valid—and actually connected.

Why Does GOSI Pay the Employee Directly?

From a business perspective, many expect the payment to go to the employer first.
But the design from GOSI is intentional:

• The benefit is meant to support the employee directly
• It ensures the employee receives compensation without dependency on employer processing
• It reduces the employer’s burden, but does not replace employer payroll processes automatically

Which creates the core challenge:

“Payroll still pays salary… while GOSI also pays the employee separately.”

 

The Real Scenario Everyone Is Facing

Let’s look at what actually happens in companies:

• An employee takes paid maternity leave, then after a few months receives compensation from GOSI.

Now the employer asks:

“How do I recover the salary I already paid?”

 

First Thought: “Let’s Just Reverse It”

Idea:

Replace paid maternity leave with unpaid leave (retroactively)

Why it sounds correct:

• Aligns with the legal concept
• Removes employer cost
• Clean from a business perspective

Why it doesn’t really work:

• SAP payroll will reopen past periods
• Everything gets recalculated (even closed payroll)
• Financial postings may change
• Other wage types get impacted (not just maternity-related)

✔️So yes, it solves the business logic…
 ❎But breaks payroll stability

 

Second Thought: “Ok, Then Just Deduct It Later”

Idea:

Recover the amount through future payroll

Why we like it:

• No retroactive impact
• Keeps historical payroll unchanged
• Easy to control

But here’s the catch:

• We don’t know the exact GOSI amount
• No clear rule on:
• Basic vs Housing split

✔️So yes, it solves the technical issue…
❎But doesn’t solve the calculation ambiguity

 

Third Thought: “Can We Automate It Fully?”

Idea:

Build logic in payroll to calculate and distribute everything automatically

Why it’s attractive:

• No manual work
• Fully system-driven
• Clean process

Why we didn’t go there (yet):

• No confirmed formula from GOSI

–>To elaborate:

GOSI defines the compensation as 100% of the average insured salary over the last 12 months.
However, from a system perspective, this introduces multiple limitations:

• The 12-month average may include periods where the employee worked for different employers
• The current employer does not have visibility into salary or contribution data from previous companies
• There is no integration/API providing this cross-employer historical data
• Additionally, due to Personal Data Protection Law (PDPL) considerations, the employer does not have the authority to request or rely on the exact compensation amount received by the employee from GOSI

–>Which means:

Even if we automate the calculation in SAP, it would be based on incomplete or indirect data, and cannot be validated against the actual amount paid by GOSI

• No integration/API to validate results
• High risk of calculating the wrong amount

✔️So yes, it solves the automation need…
❎But risks compliance and accuracy

 

Fourth Thought: “What If We Handle It Correctly from the Start?”

Idea:

If the employee requests GOSI compensation during the same period, we directly record:

–> Unpaid maternity leave instead of paid leave

Why this is the best-case scenario:

• No recovery required later
• No retroactive changes
• Payroll remains clean
• Aligns with the GOSI concept

So… what’s still missing?

• No visibility on actual GOSI compensation amount
• No defined split between:
  • Basic Salary
  • Housing Allowance
• Requires strong coordination:
• Additionally, the employee may dispute the employer’s action based on Saudi Labor Law Article 151, especially if the expectation is to receive paid maternity leave from the employer

✔️ So yes, it solves the timing issue…
❎But introduces potential employee relations and legal interpretation risks, in addition to dependency on external clarity and internal discipline

 

So, What Did We Actually Do?

We stepped back and asked:

“What is the safest way to handle this—without breaking payroll or assuming unclear rules?”

–> That’s why we delivered this as a KBA (Knowledge-Based Approach)

 

Reference: SAP KBA

For detailed configuration steps and system behavior, please refer to the official SAP Knowledge Base Article: 🔗KBA 

This KBA provides:

• Step-by-step implementation guidance
• Detailed explanation of standard payroll behavior
• Recommended approaches (IT0014, IT0045, IT2001)
• Technical considerations for retroactivity and deductions

 

Why a KBA Instead of a Standard Solution?

Because:

• GOSI doesn’t provide full calculation details
• SAP doesn’t receive actual compensation values
• Customers handle cases differently
• Each scenario depends on timing and business decisions

–> A fixed solution would either:

• Be too rigid
• Or introduce incorrect calculations

–> A KBA provides:

• Flexibility
• Control
• Safe implementation

 

Let’s Be Honest About the Options

Let’s look at each option realistically:

• Unpaid Leave (Same Period)
  This is the cleanest approach from a process perspective, as it avoids any recovery later and keeps payroll aligned from the beginning. However, it depends heavily on early action and still suffers from unclear calculation rules.
• Unpaid Leave (Retroactive)
  This can correct past payments and align with the legal concept, but it comes at a high cost—triggering retroactive payroll recalculations and impacting payroll stability.
• Recurring Deduction (IT0014)
  A safe and practical method to recover the amount in future payroll periods. It is simple and controlled but relies on manual input since the exact calculation from GOSI is not available.
• Loan (IT0045)
  Provides structured tracking and visibility of the remaining balance, making it suitable for financial control. However, it is more complex to manage and still depends on manual calculation.
• Automation (PCR)
  This approach offers full automation and flexibility in distributing amounts across wage components. However, without a reliable calculation source from GOSI, it introduces a high risk of incorrect results.

 

The Hidden Problem: Net Pay & Arrears

Even with the best approach, another issue appears:

“What if the deduction is higher than the employee’s net salary?”

–> SAP will:

• Deduct partially
• Carry the remaining amount as arrears (claims)
• Recover it in future payroll periods

–> Meaning:

• Recovery becomes gradual
• Not guaranteed in one cycle

 

The Big Missing Piece

Everything comes back to one point:

We still don’t have a clear answer from GOSI on:

• Exact calculation method
• Component distribution
• Actual compensation value

 

So, What’s the Right Approach Today?

Not perfect but practical:

✅Handle correctly from the start when possible
✅Avoid retroactive payroll changes
✅Use forward recovery when needed
✅Keep logic flexible and controlled

 

Final Thought

This is one of those cases where:

The legal idea is simple…
But system reality is not.

Every solution we explored:

• Solves one part of the problem
• But not the full picture

–> That’s why flexibility not automation is the right approach for now

 

What We’re Waiting For

To move toward a standard solution, we need:

• Clear calculation rules from GOSI
• Integration or API availability
• Standardized scenarios

 

Stay Updated

To stay informed about upcoming updates, enhancements, and discussions related to this topic, we recommend visiting the MENA SAP User Group space, where we will be sharing the latest developments and guidance.