HRMSandPayrollinBangladesh:WhattheSoftwareActuallyHastoHandle

Payroll is the least forgiving software a company runs. An inventory system that is wrong by one unit is a discrepancy. Payroll that is wrong by one day of leave is a person who was not paid correctly, and they will know before you do.

We have built payroll for factory floors, field teams, hospitals and offices. What follows is what we have learned has to be true of the system — whether you build it, buy it, or inherit it — for a workforce in Bangladesh.

One thing first, said plainly: statutory figures change and your own service rules may be more generous than the statutory floor. Every entitlement below should be configured from your service rules and verified against the current text of the Bangladesh Labour Act and the rules made under it, with your own advisers. Software that hardcodes a number instead of configuring it is software you will be fighting the first time anything is amended.

Start with the leave model, not the salary calculation

Everyone building payroll starts at the salary calculation. It is the wrong place to start, because it is the easy part. The part that generates support tickets for years is leave.

Bangladeshi leave entitlements are not a flat annual grant. Several of them accrue against days actually worked rather than being handed out on 1 January — annual leave in particular is earned in proportion to service during the preceding period. That single characteristic breaks most imported payroll products, which model leave as a yearly balance with a reset date.

What the data model needs to support:

• Accrual as a computed series, not a stored number. Store the events — days worked, leave taken, adjustments — and compute the balance. A stored balance is a number you will not be able to explain to the employee who disputes it eleven months later.
• Multiple leave types with different rules. Casual, sick, annual and festival holidays behave differently: some carry forward, some do not, some are encashable, some require documentation. A single "leave days" field cannot express this.
• Per-category entitlement. Entitlements can differ between adult and adolescent workers and between establishment types. If your workforce spans categories, the entitlement has to be a property of the employment, not a global setting.
• Mid-period joiners and leavers. Proration is where arithmetic disagreements begin. Decide the rule, write it in one place, and make the payslip show the working.

The test we use: can an employee open their own record and see why their balance is what it is, as a list of dated events? If not, HR will answer that question by hand, forever.

Attendance is a connectivity problem before it is an HR problem

Payroll is only as good as the attendance data underneath it, and attendance is captured in exactly the places where connectivity is worst: a factory floor, a construction site, a guard post, a delivery route.

If the capture device assumes a live connection, one of two things happens. Either attendance goes missing, or — much more common — someone starts keeping a register, and the register becomes the real system while your software becomes a place data is retyped at month end. Every payroll dispute after that is a dispute about the retyping.

What we build for instead:

• Local-first capture with durable queueing. The punch is recorded on the device and survives an app restart, a dead battery and a day with no signal.
• Server-authoritative time. Trusting the device clock means trusting anyone who can change it. Record the device time and the server's receipt time, and reconcile on the server.
• Conflict rules decided up front. Two punches for the same shift, a punch that arrives three days late, a shift that crosses midnight. These are not edge cases on a real roster; they are Tuesday.
• Roster-aware evaluation. A punch means nothing without the shift it belongs to. Night shifts crossing midnight, split shifts, and rotating rosters all have to resolve to a specific expected shift before overtime can be calculated at all.

Overtime, and why the basis matters more than the multiplier

Overtime rules are usually described as a multiplier, which makes them sound simple. The multiplier is the easy half. The half that causes disputes is what it is a multiple of.

Decide, configure and document: which components make up the hourly basis (basic only, or basic plus which allowances), how the hourly rate is derived from a monthly salary, how it rounds, and at what granularity overtime is counted. Then make the payslip show that working. An employee who can see basis × hours × rate does not file a grievance; an employee who sees only a total does.

The same applies to any holiday or rest-day premium your service rules provide for. Configure the basis; never hardcode it.

The things that only show up in production

These are the requirements nobody writes on the specification and everybody needs by month three.

Arrears and retroactive change. A salary revision is approved in September, effective from June. Three months of payroll now have to be recomputed — with the leave, overtime and tax of those months, not of today. A system that cannot recompute a closed period will produce an adjustment line that nobody can reconcile back to anything. Payroll must be recomputable, not merely stored. This is the single most important architectural property on this list, and the one most often missing.

Loans and advances. Deducted in instalments, sometimes paused, sometimes settled early, always needing a running balance the employee can see.

Multiple pay cycles and pay groups. Monthly staff and weekly or piece-rate workers in the same company, on different calendars, with different rules.

Piece-rate and production-linked pay. For RMG and manufacturing, pay can be a function of output, and output comes from a different system entirely. That integration has to be reliable, because it is pay.

Disbursement. Bank EFT files in each bank's own format, mobile financial services for workers without bank accounts, and cash for the remainder — usually all three at once, in one pay run, with one reconciliation afterwards. Treat disbursement as a first-class part of payroll rather than an export, or you will reconcile it by hand.

Final settlement. Leave encashment, notice, any gratuity or provident fund obligation under your rules. It happens rarely and is scrutinised heavily when it does.

Audit: assume someone will ask, years later

The question will be some version of why was this person paid this amount in this month? Your system needs to answer it without anyone reasoning from memory.

• Immutable pay runs. Once a period is closed, it is closed. Corrections are new, dated, attributed entries — never edits to history.
• Every input versioned. Salary structures, entitlements, tax settings, rosters: all of them effective-dated, so recomputing June uses June's configuration and not today's.
• Attribution on every change. Who approved the revision, who ran the payroll, who released it. "The system did it" is not an audit trail.
• A payslip that shows its working. Gross, each component, each deduction, and the basis for anything calculated. This is not a design nicety — it is the document that resolves disputes before they become formal ones.

Income tax deduction at source on salary income is its own topic and genuinely does change; treat rates, slabs and exemptions as configuration with effective dates, verified against current NBR guidance each year, and never as constants in code.

If you are buying rather than building

Five questions that separate products that work here from products that demo well:

1. Show me an employee's leave balance as a list of dated events. If the answer is a single number, accrual is not modelled properly.
2. Recompute a closed period after a backdated salary revision. Watch whether it recalculates or posts an adjustment line.
3. Take the device offline, record attendance, bring it back. Confirm nothing is lost and nothing is duplicated.
4. Produce the bank disbursement file for my bank. Not "we support EFT" — the file, in the format, for that bank.
5. Change a statutory value and re-run last quarter. It should be a configuration change with an effective date, not a support ticket.

Any product that passes all five is a serious product, whoever built it.

Where we land

Payroll is a place where the boring properties matter more than the features: entitlements as computed series, effective-dated configuration, recomputable periods, an audit trail with names on it, and a payslip that explains itself. Everything else is easier than it looks. These five are what separate a payroll system from a spreadsheet with a login.

That is the model WaveHR is built on, and it is also what we would tell you to look for in something we did not build. If you want a second opinion on the system you are running now, we are happy to give one.