UAE WPS and the SIF file, explained

What WPS is

The Wages Protection System is how the United Arab Emirates checks that employees are actually paid what they are owed, on time. Rather than trusting a payroll report, it compares two things: the money that moved through the banking system, and a file the employer submits describing what that money was.

In practice you pay salaries through an approved agent — a bank or exchange house — and submit a Salary Information File for the same period. If the two agree, the period is clean. If they do not, the discrepancy is visible to the authorities, and the consequences attach to the establishment rather than to the payroll clerk.

What a SIF file contains

A SIF is a flat file with two kinds of record.

• One record per employee. Who they are in the labour ministry's records, the account the money went to, the period it covers, the days it covers, and the amounts — fixed pay separated from variable pay.
• One control record for the batch. Who the employer is, which agent processed it, the period, how many employee records there are and what they total.

The control record is the part people underestimate. It is a checksum: if the employee records do not add up to it, the file is wrong regardless of how correct each individual line looks.

Why files come back rejected

Rejections are usually a mismatch with a system elsewhere, not a typo in the file:

• Identifier mismatches. The employee identifier in the file has to match the labour ministry's record for that person. A new joiner whose paperwork has not completed will fail, however correct their payroll record is.
• Period mismatches. The period in the file has to match the period the payment covers — off-cycle runs and mid-month corrections are where this slips.
• Bank detail errors. An IBAN that fails validation, or an account that does not belong to the employee named.
• Totals that do not reconcile. Usually because an adjustment was made after the file was generated and the file was not regenerated.
• Leavers still in the file, or a final settlement paid outside the run and therefore invisible to it.

The common thread is that the file was assembled from something other than the pay run it describes. Every rejection above is a symptom of a second source of truth.

What payroll has to produce

• A file generated from the pay run itself, so it cannot describe numbers the run did not produce.
• Labour ministry identifiers and bank details held per employee and validated before the run, not at submission time.
• Fixed and variable pay kept as separate concepts throughout payroll, because the file needs them apart.
• Correct period and day counts for part-months, off-cycle runs and mid-period joiners.
• Regeneration after any adjustment, with the control totals recomputed rather than carried over.
• A record of which file was submitted for which period, so a query months later can be answered.

How Nova HRM handles it

The SIF comes out of the pay run that produced the salaries — not from a report assembled afterwards — so the file and the payroll cannot disagree. Establishment and agent details sit in payroll configuration; employee identifiers and IBANs live on the employee record and are validated as part of the run rather than discovered at the bank.

Because pay runs are recomputable, an adjustment regenerates the file with fresh control totals instead of leaving a stale one to be submitted by mistake. The same pay run posts to your general ledger in the same movement, so the payment, the file and the accounts all describe one event. Saudi Arabia's GOSI contributions work the same way, as do QPEN in Qatar and EOBI in Pakistan.

Common questions