UAE EOSB Savings Scheme: A Payroll Integration Guide

The EOSB Savings Scheme payroll integration challenge is different from traditional UAE gratuity processing: the voluntary Alternative End of Service Benefits Scheme replaces future lump-sum accruals for enrolled employees with monthly contributions to an approved investment fund. MoHRE's November 2025 guidance clarified the operational process, including employer enrollment, employee selection, fund administration, and record-keeping. Payroll software therefore needs to track scheme enrollment, contribution rules, service periods, fund transfers, and previously accrued gratuity separately.

How the EOSB Savings Scheme Actually Works

The UAE Alternative End of Service Benefits Scheme was introduced under Cabinet Resolution No. 96 of 2023 as a voluntary alternative to the traditional gratuity system. Participating employers submit a request through MoHRE, select an approved investment fund, and register the employees they choose to include.

The November 2025 guidance clarified the operational model further. An employer does not simply switch its entire payroll from gratuity to savings. It makes an enrollment decision, selects the applicable investment-fund arrangement, and registers participating employees through the relevant fund administrator. Once an employee is enrolled, the traditional end-of-service system is suspended for that employee for future service, while the entitlement accumulated before enrollment remains protected.

The employer's participation is subject to a minimum one-year subscription period before withdrawal, subject to the applicable conditions. This is an employer-level commitment rule rather than a requirement that every employee must remain enrolled for one year before receiving a benefit.

Employee selection also needs to remain configurable. The employer can select employees or eligible professional categories rather than automatically applying the scheme to every person on the payroll. That makes employee-level enrollment status an important data point in the payroll architecture.

For payroll software, scheme participation should therefore be represented as an effective-dated employer configuration rather than a simple employee deduction. The system needs to know when the employer entered the scheme, which employees or categories were selected, which fund arrangement applies, and when contributions begin.

Who the Scheme Actually Covers

The Savings Scheme should not be implemented as a blanket "expatriate versus Emirati" switch. The federal scheme is available to participating private-sector employers, while UAE and GCC nationals can have separate mandatory pension and social-security obligations. Payroll software therefore needs to distinguish scheme participation from nationality and from pension registration.

For a mixed workforce, the system may have expatriate employees participating in the Savings Scheme, UAE nationals subject to applicable pension requirements, and other employees who remain under the traditional gratuity arrangement because the employer has not enrolled them. These are different payroll states and should not be represented by a single EOSB field.

MoHRE's November 2025 guidance also clarified that the employer determines which employees or professional categories are registered. Once an employee has been enrolled, participation applies to that employee under the scheme rather than giving the employee an ongoing option to switch back to traditional gratuity.

From a developer perspective, eligibility and enrollment should therefore be separate concepts. Eligibility describes whether the employee can participate under the applicable rules. Enrollment records the employer's actual decision to register that employee. The payroll engine can then use the enrollment date as the effective boundary between traditional gratuity treatment and Savings Scheme contributions.

This structure becomes particularly useful for companies with large or mixed workforces. A payroll administrator can change the employer's participating categories without rewriting historical payroll records, while each employee retains a clear record of when their Savings Scheme participation began.

Free Zone Exclusions and DIFC's Separate Scheme

Free-zone treatment needs to be handled by jurisdiction rather than by a blanket assumption that every free-zone entity is either included or excluded. MoHRE's public material describes the Savings Scheme as available to private-sector employers and provides an enrollment mechanism for participating establishments.

DIFC is a separate case. DIFC operates the DIFC Employee Workplace Savings Plan, or DEWS, under its own employment framework. DIFC describes DEWS as its employee workplace savings plan, introduced in 2020, and its current business guidance sets out separate requirements for DIFC entities.

That means payroll software serving DIFC entities should not automatically route employees into the federal Alternative EOSB Savings Scheme. The employer's legal jurisdiction needs to be evaluated first, after which the system can apply the relevant benefits framework.

DIFC's published guidance also illustrates why matching contribution percentages do not necessarily mean matching schemes. DEWS uses its own contribution rules and remains governed by the DIFC employment framework rather than Cabinet Resolution No. 96 of 2023.

The practical architecture is therefore jurisdiction-aware benefits routing. A mainland or eligible free-zone employer can be configured against the federal Savings Scheme where applicable, while a DIFC employer can be routed to DEWS rules. The same payroll platform can support both without hard-coding one EOSB calculation across every UAE entity.

Any implementation involving a financial free zone should still be checked against the current rules of that jurisdiction before deployment. The distinction between the federal scheme and separate qualifying schemes is material enough that a payroll system should make the governing framework explicit in its employer configuration.

The Contribution Calculation Payroll Software Needs to Run

The Savings Scheme uses a contribution model that differs from traditional end-of-service gratuity accrual. For an employee with less than five years of service, the employer's basic subscription is 5.83% of monthly basic salary. After five years of service, the rate becomes 8.33%.

The payroll engine therefore needs more than the employee's current salary. It needs the employee's service start date, current basic salary, Savings Scheme enrollment status, and applicable contribution rate. The five-year threshold should be calculated from the relevant service period rather than maintained as a manually entered flag.

The contribution base also needs to remain distinct from total gross compensation. The system should identify the employee's basic salary component and apply the applicable contribution rate to that amount rather than automatically applying the percentage to allowances, bonuses, or other payroll components.

Each payroll cycle should generate a contribution record containing the employee, contribution period, basic salary used, applicable rate, calculated amount, and payment or transfer status. Where the fund administrator provides a transaction reference, that reference should be retained so finance teams can reconcile payroll output with actual fund transfers.

Salary changes need to be handled on a period-by-period basis. If an employee's basic salary changes, the contribution for the affected payroll period should use the applicable salary rather than carrying forward the previous contribution base. Historical payroll records should remain fixed once processed.

The five-year threshold also needs careful date handling. A production payroll system should derive service duration from the employee's service history and apply the relevant rate automatically. That removes the need for HR teams to monitor individual anniversaries and manually change contribution percentages.

From an architecture perspective, the Savings Scheme contribution engine should sit alongside the existing payroll calculation engine. It should receive employee and salary data, calculate the contribution, create the fund-transfer record, and pass the result into reconciliation without replacing the broader payroll system.

What Happens to Gratuity Already Accrued Before Enrollment

Enrollment in the Savings Scheme is not retroactive. Workers retain the gratuity they earned before the employer registered them in the scheme, while the traditional end-of-service system is suspended for employees registered in the alternative scheme from the point of participation.

For payroll software, this creates a defined transition point. The system needs to preserve the employee's accrued gratuity as of the enrollment date and then start the Savings Scheme contribution workflow from that point forward.

The November 2025 guidance further clarified that preserved gratuity entitlements are calculated at the enrollment date using the employee's basic salary at that date. Employers are not required to make retroactive Savings Scheme contributions for service before enrollment.

This means the payroll system should not maintain one continuously changing EOSB balance across both mechanisms. The pre-enrollment entitlement should be stored as a historical benefit value, while post-enrollment periods should generate separate monthly contribution records.

The distinction matters when the employee's salary changes after enrollment. A later salary increase should affect future Savings Scheme contributions according to the applicable rules, but it should not rewrite the preserved pre-enrollment gratuity calculation.

The final settlement process then needs to identify both components. The system should be able to show what gratuity was accrued before enrollment and what contributions and investment-related balances accumulated after enrollment, rather than attempting to reconstruct the entire employment history from one EOSB field.

For developers, this is best handled through two linked benefit ledgers: a preserved pre-enrollment gratuity record and a post-enrollment Savings Scheme contribution ledger. Both belong to the same employee, but they follow different calculation and settlement rules.

Why Most Payroll Systems Aren't Built for This Yet

Traditional payroll systems are often designed around a single gratuity calculation: salary and service duration produce an accrued liability that remains on the employer's books until termination. The Savings Scheme introduces an ongoing contribution workflow with employer enrollment, employee selection, investment-fund administration, monthly transfers, and separate treatment of historical gratuity.

The first architectural requirement is employer-level scheme configuration. The payroll platform needs to store whether the employer participates, when participation began, which fund arrangement applies, and which employee categories are included.

The second requirement is employee-level enrollment. Because an employer can choose which employees or categories participate, the system cannot simply activate the Savings Scheme for every employee when the employer enrolls. Each employee needs an effective participation status and enrollment date.

The third requirement is a dedicated contribution engine. The system needs to calculate the applicable monthly subscription from basic salary and service duration, record the resulting amount, and connect it to the fund-transfer workflow.

The fourth requirement is reconciliation. A payroll system should retain the calculated contribution, transfer status, payment date, and available fund reference so finance teams can compare what payroll calculated with what was actually transferred.

The fifth requirement is jurisdiction routing. UAE payroll platforms may serve mainland companies, ordinary free-zone entities, and financial free zones with separate employment-benefit frameworks. DIFC's DEWS is a clear example of why the system needs to identify the governing jurisdiction before selecting an EOSB workflow.

There is also the transition problem. The system must preserve gratuity accrued before enrollment while preventing subsequent Savings Scheme contributions from being mixed into the historical liability. That requires effective-dated benefit records rather than a single editable EOSB balance.

A clean implementation is therefore to treat the Savings Scheme as a dedicated benefits module connected to the payroll engine. Employee master data supplies service and salary information, the benefits layer determines enrollment and contribution rules, and the fund-transfer layer records what was remitted.

UAE EOSB Savings Scheme Payroll Integration: What the System Needs to Track

Scheme Element	What It Requires	What Payroll Software Must Do
Employer enrollment	Participation is voluntary and requires employer registration through the applicable MoHRE process	Store participation status, enrollment date, fund arrangement, and participating categories
Employee enrollment	Employer can select employees or eligible professional categories	Maintain employee-level enrollment status and effective dates
Minimum commitment	Employer withdrawal is subject to a minimum one-year subscription period and applicable MoHRE conditions	Track employer commitment status and prevent invalid withdrawal-state changes
Contribution calculation	5.83% of basic salary for service below five years and 8.33% after five years	Calculate the applicable rate automatically from service duration and basic salary
Pre-enrollment gratuity	Gratuity earned before enrollment remains protected	Preserve the historical entitlement separately from post-enrollment contributions
Jurisdiction handling	Financial free zones can operate under separate employment-benefit frameworks	Identify the governing jurisdiction and route employees to the correct scheme rules

Frequently Asked Questions

Is the EOSB Savings Scheme mandatory for UAE employers?

No. The EOSB Savings Scheme is a voluntary alternative to the traditional end-of-service benefits system. MoHRE introduced it under Cabinet Resolution No. 96 of 2023 as an optional scheme for participating employers. The November 2025 guidance clarified how employers can enroll and administer the scheme; it did not turn the scheme into a universal mandatory replacement for gratuity.

Does the EOSB Savings Scheme apply to Emirati employees?

The Savings Scheme should not be treated as a replacement for the mandatory pension and social-security arrangements applicable to UAE nationals. Payroll software should therefore distinguish an employee's nationality and pension registration from their Savings Scheme enrollment status. UAE nationals may have separate mandatory pension obligations, while the federal Savings Scheme operates as an alternative EOSB framework for employees selected by participating employers.

Do DIFC-based employers use the same EOSB Savings Scheme?

Not automatically. DIFC operates the separate DEWS workplace savings framework, and DIFC guidance sets out its own employment-benefit requirements. Payroll software serving DIFC entities should therefore route those employees according to DIFC's current employment-benefit rules rather than assuming the federal Savings Scheme applies.

---

The EOSB Savings Scheme is the expat half of the broader UAE end-of-service payroll picture, while GPSSA and other applicable pension arrangements form the Emirati/GCC half for employees subject to mandatory pension requirements. For the payroll implementation side, see the existing UAE WPS payroll compliance guide and GPSSA/ADPF pension integration guide. A discovery session can map the applicable EOSB, pension, payroll, and fund-transfer rules into the software architecture before implementation begins.