Multi-Branch HR Engineering: PTO, SIF & ERP in MENA

The 3-Branch Problem Nobody Warns You About

An HR director at a 220-person logistics company once described her payroll process as "artisanal." She meant it as a complaint. Every month, her team exported three separate Excel files from three separate systems — Cairo HQ, an Alexandria depot, and a Dubai office — reconciled them by hand, and prayed nothing had drifted. Closing day took 11 working days. After moving to a unified system, it took 2.

That gap isn't about effort. It's about architecture. Single-entity HR tools were never designed to aggregate across legal entities, time zones, or payroll jurisdictions. When you force them to, humans absorb the complexity — and humans make mistakes on night-shift differentials and annual leave balances.

Multi-Branch Attendance Aggregation: Where the Data Breaks

The core challenge is deceptively simple: different branches generate attendance records at different times, in different formats, from different hardware. A fingerprint reader in Jeddah may push logs at odd intervals. A face-recognition terminal in Cairo syncs overnight. A Gulf entity may rely on a card-tap system the vendor stopped supporting in 2021.

A mature aggregation layer needs to:

• Accept multiple input formats (biometric API, CSV, manual override) and normalize them into a single timeline per employee
• Apply branch-specific shift rules — a factory running 6-day weeks has fundamentally different overtime logic than a corporate office on a Sunday-Thursday schedule
• Flag conflicts rather than silently resolve them (an employee clocking in at two branches on the same day is a data error, not a business trip)
• Lock attendance periods by branch before aggregating to payroll, so a late sync from one site doesn't reopen a closed pay run

If your current system can't do that last point, your payroll figures are probably slightly wrong every month. You just haven't found the error yet.

SIF File Export for the UAE — What HR Teams Get Wrong

The Salary Information File (SIF) is mandatory for UAE private-sector employers under the Wage Protection System. It sounds administrative until a file is rejected and 300 employees wait on salaries.

Common failure points:

• Agent codes: Each bank has its own agent code that must appear in the file header. Using a generic placeholder is the fastest way to get a bulk rejection.
• IBAN format: UAE IBANs are 23 characters. HR teams copying from employee onboarding forms regularly capture formatted strings with spaces. The Ministry portal won't tell you which record failed — just that the file did.
• Basic salary vs. total package: The SIF captures basic + allowances in discrete fields, not a single gross figure. Systems that only store gross pay cannot produce a valid SIF without manual decomposition every cycle.
• End-of-service timing: When an employee exits mid-month, the SIF for that period must reflect the exact number of working days, not a prorated fraction of the standard figure. The rounding convention matters.

For Saudi payroll under WPS, the structure differs — the GOSI registration number and IQAMA validity feed into the file — but the failure mode is the same: systems that treat WPS as a one-time export rather than a structured data pipeline generate exceptions you catch only after submission.

WPS Payroll Saudi: The GOSI and IQAMA Dependency

Saudi WPS compliance is tightly coupled to HR data quality in ways Egyptian-first systems don't expect. The Wage Protection Program cross-references GOSI contribution records against payroll submissions. If your HR system stores IQAMA expiry dates as free-text fields rather than structured dates, you'll miss the automatic alert that a worker's document expired 11 days before the pay run — and the resulting WPS exception will delay funds for everyone on that entity's payroll file.

Payroll engineers building for Saudi entities need to design for:

• Automatic GOSI contribution calculation split (9.75% employer / 1% employee for Saudi nationals)
• IQAMA expiry alerts at 90, 30, and 7 days before the next pay cycle closes
• Separate payroll entity records per Saudi legal entity, since GOSI registration is entity-specific

PTO Accrual Engines: The Logic Most Systems Approximate

"21 days per year" looks simple. The accrual mechanics underneath it are not.

A correct PTO engine needs to handle at least these cases cleanly:

• Hire-date proration: An employee joining on the 17th of Ramadan accrues a partial month. How you calculate that partial month (calendar days vs. working days) must match your employment contract language.
• Grade-based accrual: Senior grades often earn 30 days; junior grades earn 21. When someone is promoted mid-year, the accrual rate should change from the promotion effective date, not from January.
• Carry-over caps: Egypt Labour Law 12/2003 permits employees to carry forward a maximum of half their annual entitlement if business needs prevented them from taking leave. Your system should cap carry-over automatically at the cycle close, not let balances grow indefinitely.
• Leave encashment on exit: Unused accrued leave must be paid out at the daily basic wage rate on termination. If your accrual balance and your payroll gross-to-basic ratio are stored in separate systems, this calculation is manual every time someone leaves.

Most mid-market HR tools store leave as a bucket that decrements on request and increments on a fixed annual date. That works for a 40-person company. At 200 people across two countries, you need a time-series accrual engine that can reconstruct any employee's correct balance on any historical date — because audits don't ask about today, they ask about 14 months ago.

Egypt Labour Law 12/2003: What the 2024 Amendments Actually Changed

Law 12/2003 has accumulated amendments that HR teams running older software often haven't encoded. The ones that generate the most payroll errors in practice:

• Overtime cap: Daily overtime is capped at two hours in most sectors. Night-shift supplements apply at 35% above ordinary hourly rate, not 25%.
• Probation rules: The probation period cannot exceed three months. Some systems default to 6-month probation periods inherited from older Gulf configurations — leaving Egyptian entities legally exposed.
• Sick leave structure: The first 30 days are at 75% pay; the next 60 at 85%; beyond 90 days, the employer may terminate with end-of-service entitlement intact. This three-tier structure is frequently collapsed into a flat percentage in misconfigured systems.

For a thorough breakdown of recent statutory updates, the Egypt Labour Law compliance guide covers what HR managers need to audit in their current configurations.

ERP Integration: Payroll Data Needs to Flow Both Ways

Finance teams want payroll costs in their GL the same day HR closes the pay run. That means your HR system needs a bidirectional ERP integration, not a monthly CSV export.

What bidirectional actually means in practice:

• ERP pushes cost-center and project-code changes to HR in real time, so payroll GL mapping is always current
• HR pushes approved payroll journals to ERP by entity, currency, and department — without a finance analyst rekeying figures
• Headcount changes in HR (new hire, termination, role change) automatically update ERP budget actuals

The integration failure mode that costs the most isn't the monthly reconciliation — it's the quarterly audit where Finance and HR have different headcount numbers and nobody knows which system is right. That happens when the integration is one-directional and one team updates their system without the other knowing.

Attendux is built specifically for this operational layer — multi-entity payroll, SIF/WPS export, and ERP sync for MENA companies where labour law varies by entity location. If you're evaluating HR SaaS for a company that spans Egypt and one or more Gulf entities, the architecture decisions in that product are worth understanding regardless of what you ultimately choose.

It's also worth noting that HR data complexity often mirrors the same build-vs-configure question that comes up in custom software decisions — the off-the-shelf vs. custom software trade-off applies directly when standard HR platforms can't accommodate your entity structure.

Choosing the Right Data Model Before You Sign a Contract

Ask every HR SaaS vendor these questions before you commit:

1. Can the system hold multiple legal entities under one tenant, with separate payroll runs and separate SIF/WPS outputs per entity?
2. Is PTO accrual calculated daily (time-series) or on a fixed annual date (snapshot)?
3. How does the system handle a mid-month promotion that changes both salary and accrual rate simultaneously?
4. What is the ERP integration method — API, flat file, or native connector? Who maintains it when the ERP version changes?
5. Can you reconstruct an employee's exact leave balance on any historical date, or only today's balance?

Vague answers to any of those questions mean manual workarounds — and manual workarounds compound every pay cycle.

For teams still evaluating the full HR software decision, the HR software buying guide covers the foundational criteria before you get to multi-entity complexity.

Ready to talk?

If your payroll close takes more than four working days, or your SIF rejections are running above zero per quarter, something in your data model is wrong — not your team's effort. We're happy to look at your current setup and tell you honestly where the gaps are. Reach out through the contact page and describe your entity structure; that's usually enough to start a useful conversation.