What HR Teams Get Wrong About Gratuity Accruals

Someone resigns on a Tuesday and finance asks HR for the end of service figure by Thursday. What follows is usually an hour of reconstruction: a joining date from a scanned offer letter, a leave balance from a shared spreadsheet, a salary history assembled from three payroll exports.

Most gratuity accrual errors are not calculation errors. They are record errors. The formula is short and public. The inputs are scattered, and the scattering is what produces wrong numbers, late payments and the occasional dispute.

The inputs are simple, which is the trap

An end of service calculation needs a small set of facts: the date service started, the date it ended, the basic salary that applies, the reason for leaving, and any periods that do not count towards service. Because the list is short, teams assume those facts are easy to find. They are easy to find once. They are hard to find consistently, for every employee, on demand, going back years.

The test is simple. Pick any employee at random and try to produce all five facts from a single system in under a minute, with a source you would show an auditor. Most companies cannot.

Where the numbers go wrong

Joining date confusion. Offer date, visa issue date, first day in the office and payroll start date are often four different dates in four different places. Service usually runs from the actual start of employment, and picking the wrong one shifts the whole calculation.

Basic pay versus total package. UAE gratuity is generally calculated on basic salary rather than allowances, so a company that stores only gross pay has to reverse engineer the split. When allowance structures change mid career and nobody records the change date, the reverse engineering becomes a guess.

Salary history that only holds today. Many HR systems store the current salary and overwrite the last one. That is fine until a calculation needs to know what applied in a specific month, or until someone asks why the accrual jumped.

Unpaid leave that nobody logged. Extended unpaid absence can affect service length, but unpaid leave is often approved in a chat and never entered anywhere countable.

Rehires treated as new joiners. Someone leaves, is settled, comes back eighteen months later. If the old record is reused, the system may quietly count the gap as service. If a new record is created without a note, the history disappears.

Accruals booked once a year. If the liability is only calculated at year end, every month in between shows a finance picture that is out of date, and any headcount decision made on that picture is made on the wrong number. Employers moving to a funded savings scheme instead of traditional gratuity still need the years before the switch recorded correctly.

The pattern behind all of them

Each of those errors comes from the same shape of problem: the facts live in different systems, owned by different teams, updated on different schedules. Payroll knows salary. HR knows leave. The manager knows the actual last working day. Finance holds the provision. Nobody holds all four at once.

Then someone resigns and the four have to be reconciled under time pressure, by a person, from memory and files. The reconciliation is where errors enter, and because it happens per departure it never gets any easier. On the employee's side it decides what actually lands in the first thirty days after a gratuity payout.

What good looks like

A team that has this under control can answer four questions on any working day:

• What is our total end of service liability right now?
• Which employees drive most of it?
• If this person resigned today, what do we owe, and what is the source of each input?
• Has any of those inputs changed since last month, and who changed it?

Getting there is less about a clever formula and more about three habits. Keep one authoritative date of joining per person and never let a second one exist. Store salary as a dated history rather than a current value. Record every leave type, including unpaid, in the same place approvals happen, so the record is a by product of the approval rather than a separate task nobody enjoys.

One set of records instead of four

This is the case for keeping people data and work data together. Sicherhaven builds SicherOne, an enterprise workspace that puts project management, HR and AI agents on one set of records. A board knows who is on leave because leave and work sit on the same records rather than in separate tools that have to be reconciled later.

Because the agents read the same records, they work with full context rather than a copied summary, and a human approves agent output before it ships. SicherOne is sold per seat with modules separable, so a company can start with the HR side alone. For teams with policies about where employee data sits, private models can be self hosted.

Gratuity rules, qualifying service and the treatment of resignation against termination differ by contract type and change over time. Use your own legal or payroll advice for the calculation itself. The point here is narrower: get the inputs right, keep them in one place, and the calculation stops being a fire drill.