Biometric devices in two UAE branches, one payroll close: how to stop duplicate or missing punches from blocking WPS

01Why this matters more after 1 June 2026

The practical change is not that biometric devices suddenly became mandatory for everyone. The practical change is that payroll timing discipline got tighter. The official resolution sets the unified wage due date as the first day of each Gregorian month for the preceding month, requires payment through the Wage Protection System approved by the Ministry, and treats payment after that date as delayed wage payment.

MOHRE said on 4 June 2026 that the updated decision uses a gradual approach with electronic monitoring and notifications, and that an establishment is considered compliant if it transfers at least 85 percent of the total wages due within the specified timeframe. EY’s summary adds that the updated framework introduces a clearer escalation timeline for delayed wage payments, with alerts from Day 2 and penalties escalating thereafter.

That means attendance defects that once sat in an HR queue for days now have a direct path to payroll delay. This is especially true where one company has two branches, separate clocks, inconsistent device settings, and a single payroll team trying to create one final attendance file for salary calculation and then WPS processing. The issue is not only missing data. It is conflicting data arriving too late to resolve safely.

The scale of the system explains why data discipline matters. MOHRE said in December 2025 that WPS covers more than 99 percent of private-sector workers, with total monthly transfers exceeding AED 35 billion. CBUAE also describes UAEWPS as a monitored flow in which wage information moves from the employer to contracted agents, while the Central Bank secures funds and provides frequent data feeds to the labour regulatory authority.

• Your attendance process now needs a cut-off discipline, not only a payroll discipline.
• A bad punch record is no longer a minor HR cleanup issue if it delays the salary file.
• Multi-branch environments fail more often because they create duplicate source systems, not just duplicate records.

02The four attendance defects that usually block a multi-device close

In a two-branch setup, most payroll delays come from four defect classes. They sound simple, but each needs a policy decision before it can be automated.

First, duplicate punches. These happen when an employee retries on the same device, uses two devices at one site, or clocks at branch A and branch B on the same day. If your attendance engine treats every event as equally valid, the shift can become overcounted or impossible to pair correctly.

Second, missing punches. The common example is a valid check-in with no check-out, but the more dangerous version is asymmetric data caused by an offline device that uploads late. At close, the employee appears absent or incomplete, then an old event arrives after payroll has already been calculated.

Third, identifier mismatches. The biometric platform may use an enrolment number, the HR system an employee code, and payroll a different master ID. If one branch re-enrolled users locally, the same person can appear as two workers in the raw attendance stream. This is one of the fastest ways to produce duplicate or missing attendance in final payroll.

Fourth, branch rule conflicts. One branch may allow grace periods, night shifts or cross-midnight pairing differently from the other. A central payroll close then receives structurally different time data. Even where devices are from the same vendor, the settings can drift.

Vendors themselves describe the architecture this way. CBUAE says WPS depends on reliable employer to agent data flows and monitoring. Device and platform vendors also position attendance systems as feeds into payroll, not isolated devices. For example, ZKTeco’s HRMS integration guide describes a typical flow in which devices send punches to an attendance platform, then an integration layer passes agreed attendance information to HR and payroll systems. That is exactly where duplicate and missing punch problems must be solved: between raw punch capture and payroll-ready attendance, not inside the final SIF step.

• Duplicate event, same person, same minute, two records.
• Unpaired event, one edge of the shift is missing.
• Identity split, one worker mapped to multiple IDs.
• Rule drift, branch A and branch B calculate attendance differently.

03Build one canonical attendance record before you calculate pay

The core design principle is simple: never calculate pay directly from raw device punches. First create a canonical attendance layer. That layer should turn many noisy events into one approved version of each worker day or shift.

Start with a master identity map. Every biometric enrolment ID, card number or device user ID should resolve to one payroll master ID. If you do nothing else, do this first. Without it, no duplicate or missing punch logic is trustworthy.

Then normalise timestamps. Put every event into one timezone standard, preserve the original source timestamp, and record device ID, branch ID, event type, ingestion time and upload batch. When a branch device comes online late, you need to know both when the punch happened and when your system learned about it.

Next, pair events by rule, not by hope. Define how a check-in is matched to a check-out, how cross-midnight shifts are handled, what grace windows apply, and when an event should be excluded as noise. If your branches use different shift templates, centralise those templates so the calculation engine is reading one controlled policy set.

After pairing, create exception states. Good payroll operations do not delete bad records. They classify them. A record should end up as approved, duplicate ignored, missing pair, cross-branch conflict, unknown employee, late-arriving event, or awaiting supervisor decision. This is where a proper data engineering approach matters more than another device purchase.

Finally, freeze and version the payroll input. Once payroll close reaches the agreed cut-off, attendance for that pay period should be locked as version 1. Any late changes must go through an adjustment workflow with auditability. This is essential if finance, HR and operations need to explain why WPS proceeded on one value and a later correction was carried into the next cycle.

• Master ID first.
• Timestamp normalisation second.
• Pairing and rule engine third.
• Exception workflow fourth.
• Payroll freeze and adjustment log fifth.

04Set branch rules that stop duplicates without hiding genuine work

A common mistake is to overcorrect. Companies hit by duplicate punches often introduce blunt deduplication, then accidentally remove valid events. The better approach is layered rules.

Rule 1 is same-device retry control. If the same employee creates the same direction event repeatedly within a very short window, keep one event and mark the rest duplicate. The exact window depends on your device behaviour and queueing pattern. Do not guess it, measure it from your own logs.

Rule 2 is cross-device, same-branch conflict control. If two different devices at the same branch capture the same employee within a short interval, decide which device takes precedence or whether the earliest valid event wins.

Rule 3 is cross-branch conflict control. If the same employee appears in two branches too close together to be physically credible, route that day to exception handling. Sometimes it is fraud, sometimes transfer duty, sometimes a bad ID map. You need workflow, not automatic deletion.

Rule 4 is late-sync protection. Device manuals and vendor ecosystems commonly support networked upload and central platforms, but network or configuration issues still leave branches uploading late. Your design should allow ingestion of late events while preventing silent rewrites of already-approved payroll periods. This is usually handled by a controlled integration layer or API service rather than direct database writes. If you are rebuilding this path, API integration and quality engineering matter more than replacing every terminal.

Some device ecosystems also support anti-passback or in-out sequencing logic. For example, Suprema documents anti-passback as a way to force users to use designated entry and exit devices, and a ZKTeco user manual describes in-out anti-passback settings that preserve attendance state while controlling sequence. These features can reduce certain duplicate patterns, but they are access-control features first. They are not a substitute for payroll-side reconciliation, especially across branches.

• Use device controls to reduce noise.
• Use central rules to determine payroll truth.
• Never let late sync silently recalculate a closed payroll period.

05The operating checklist for payroll week

Most teams do not need a large transformation project to stabilise this. They need a stricter operating rhythm in the final days before payroll close.

• Five to seven days before close: confirm both branches have synced device users, branch rosters and shift templates.
• Three to five days before close: run an exception report for duplicate events, unpaired punches, unknown IDs and no-punch absences.
• Two days before close: force supervisor review of unresolved exceptions above a defined threshold, especially branch transfers and missing check-outs.
• One day before close: freeze attendance intake for the pay period at a named cut-off time, then generate the payroll input version.
• After freeze: allow only controlled adjustments with reason codes, approver, timestamp and affected employee list.
• Before WPS submission: reconcile employee count, payable count and gross wage totals between payroll and the approved attendance-derived inputs.
• After submission: review late-arriving punches separately, do not patch the submitted period invisibly.

06What to ask a vendor or internal IT team before you trust the fix

If you are buying software or asking an internal team to rebuild the process, ask questions that expose whether they understand payroll close risk, not just device connectivity.

Ask how they create a canonical employee identity across device IDs, HR records and payroll master data. Ask whether raw punches are immutable and whether derived attendance records are versioned. Ask how they handle late-arriving events after payroll freeze. Ask for the exact exception statuses and approval workflow. Ask how branch-specific shift rules are controlled and audited. Ask how they test cross-midnight shifts, duplicate same-minute punches, offline device backfill and cross-branch same-day events.

Also ask how they prove completeness before payroll. CBUAE describes WPS as a monitored employer-to-agent flow with employee-level balances and receipt and disbursement information in the system. Your attendance side should show a similar discipline: what was received, what was ignored, what was unresolved and what was approved for payroll.

A credible answer usually includes sample data mappings, event schemas, rule tables, audit logs and test cases. A weak answer focuses on device brands, dashboard screenshots or promises that the software will eliminate manual work entirely. It will not. It should eliminate unsafe manual work and make the remaining exceptions visible, owned and time-bounded.

This is the kind of narrow systems work that a product engineering team such as SyncTrix would typically treat as an integration and workflow problem, not a hardware procurement problem.

• Show me the master ID map.
• Show me the exception queue.
• Show me the payroll freeze behaviour.
• Show me how late events are handled.
• Show me the audit trail for every changed attendance record.

07What this costs in effort, even without quoting dirhams

Where publishing checks are strict, it is better not to invent effort numbers. But decision-makers still need a realistic shape of work.

If your branches already feed a central attendance platform and the main problem is duplicate or missing event handling, the work is usually a targeted integration and rules project: identity mapping, event normalisation, exception states, payroll cut-off logic, test coverage and reporting. The heavier part is often data cleanup and policy agreement, not code.

If each branch runs separately and payroll still depends on exported spreadsheets, the effort grows because you need a proper source-of-truth layer. That means branch-to-central data movement, standardised event schemas, role-based approvals and better observability. In those cases, the real cost is operational risk during migration. You must run at least one parallel close where the old process and new process are compared before the new one becomes authoritative.

This is also why a narrow technical engagement is often enough. You may not need to replace payroll. You may need to stabilise the handoff between devices, attendance logic and payroll, with clean APIs, tests and exception workflows. If that is the problem, start with the smallest system that can prove one clean close across both branches, then harden it for the next cycle.

• Expect policy work and data cleanup before automation pays off.
• Parallel close is worth the effort if payroll risk is already visible.
• Do not let the attendance tool write directly into final payroll without controls.