One employee record

Every HR system claims to be integrated. Here is a test that cuts through the claim: when an employee's approved leave changes, does the payroll module find out because the data changed, or because a sync job ran? In most suites the honest answer is the sync job, and everything wrong with HR software downstream of that answer.

What breaks in bundled suites

Most HR platforms at scale are acquisitions wearing a shared login page. The leave product was bought in one deal, payroll in another, and each keeps its own employee table. Between them run integrations: nightly syncs, CSV bridges, webhooks with retry queues. Each bridge is a place where two copies of the truth can drift apart.

And drift they do, always in the same miserable ways. An employee marked exited in the HR module draws a salary because payroll's copy had not synced. A leave approved on the 28th misses the payroll cutoff export, so loss of pay is deducted anyway, and refunded next month, with an apology that blames "the system", which is accurate, because the system is the problem. Anyone who has run payroll on a stitched-together suite has a version of this story. The employee experiences it as the company lying to them about their own attendance.

The vendor's fix is reconciliation reports: tooling to detect that your two copies of the truth disagree. We find this darkly funny. The disagreement is only possible because there are two copies.

The bet we made instead

ZekoHR is built on one employee record. Not one login, not one navigation bar: one record. Leave, attendance, payroll, expenses, documents and tax declarations are views and workflows over the same data, in the same database, in Mumbai.

So the chain works by construction rather than by integration. An approved leave is the attendance state for that day; there is no second table to update. Attendance for the month is the loss-of-pay input to payroll; the payroll run reads it directly, and the pre-flight checks flag anything unresolved, like a pending regularization sitting inside the pay period, before the run can be finalized. When payroll publishes, the payslip the employee opens is a view of the finalized run itself. At no point does anyone export anything into anything.

The same record extends outward: multi-company setups share the model, and the API and webhooks expose the record itself, so whatever you build on top reads the truth rather than a copy of it.

What it costs us

We want to be honest about the price, because this bet is not free.

First, flexibility. If you love your current attendance system and want only our payroll, we are a poor fit, and we will say so. A design whose whole value is that the modules share one record cannot casually bolt onto someone else's record. We lose deals over this. We prefer losing them at the demo to losing them at the reconciliation report.

Second, engineering discipline, forever. With one record there is no sync layer to quietly absorb bugs; a wrong write is wrong everywhere, immediately. Every module change has to respect invariants that other modules depend on. This makes us slower to ship certain features than a suite that can let module five contradict module two for a quarter. We think slower and coherent beats faster and contradictory, but it is a real tax and we pay it weekly.

Third, it concentrates responsibility. When there is one record, there is no other vendor to blame. We accept that; our security page already lists our gaps in public, so accepting blame is becoming something of a house style.

What it buys users

One word: truth. The number on the payslip traces to the attendance record, which traces to the leave approval, which traces to a request the employee made and can still see. When an employee asks "why was I deducted two days", the answer is a chain of records, not a shrug at a sync log. We launched recently, and plenty about ZekoHR is still unfinished. But this part, the shape of the foundation, is the part you cannot retrofit, which is exactly why we started there. The why ZekoHR page is, in the end, a longer way of saying this one thing.