Why WPS files bounce, and how to stop resubmitting

The Wage Protection System is the mechanism through which the Ministry of Human Resources and Emiratisation confirms that employees have actually been paid. The Salary Information File that carries it is a fixed-format record, and it fails on detail. A rejected file is not merely an inconvenience — repeated late payment carries real consequences for a company's ability to issue new work permits.

The failure modes

Identifier mismatches

The labour card number, the establishment ID and the employee's routing details must match what MOHRE and the bank hold — not what HR believes to be current. When an employee's visa is renewed and the labour card number changes, the payroll record has to change with it. This is the single most common cause of rejection, and it is entirely preventable with a reconciliation step before generation.

Period and pay-date logic

The salary period start and end dates must describe a real, contiguous month, and the pay date must be within the window MOHRE expects. Off-cycle runs, mid-month joiners and terminations are where date logic tends to break.

Totals that do not reconcile

The header record carries a count of employee records and a sum of fixed and variable pay. If the detail rows do not add up to the header — because a row was filtered out after the totals were computed, say — the whole file is refused.

Format drift between banks

Banks differ in how they expect the file delimited, padded and named. A file that one bank accepts will be refused by another. Treating 'the SIF format' as a single thing is a mistake; it is a family of variants.

What validation should run before submission

1. Every active employee has a current labour card number, and it matches the immigration record.
2. Record count and monetary totals in the header equal the sum of the detail rows.
3. The salary period is contiguous and the pay date falls inside the permitted window.
4. Every employee has a valid routing code and account number for the destination bank.
5. Zero and negative net-pay rows are flagged for review rather than silently included.
6. The output is generated in the variant specific to the paying bank.

In KLEDHR, WPS generation sits behind a validation corpus that has to pass at 100% before a run can be accepted — money-moving paths do not get averaged.