Ask any HR or finance lead running payroll off spreadsheets what the worst day of the month is, and almost all of them will name the same one: the day attendance gets reconciled against pay. Biometric exports, manual leave registers, shift rosters kept in someone's head, and a payroll sheet that has to somehow agree with all three — it's the single most error-prone, most manual, most dreaded process in the HR calendar. This guide walks through how a proper HRMS handles it end to end, from the moment a shift roster is published to the moment a compliant payslip is generated.
None of this is theoretical. Every process described here — shift scheduling, attendance capture, grace periods, leave and LOP, overtime, statutory payroll — is a workflow that either runs itself correctly inside a connected system, or gets redone by hand every single month inside a spreadsheet. The difference between those two outcomes is almost entirely about where attendance, leave and payroll data live: three separate places, or one.
Why Manual Attendance and Payroll Breaks Down
Most businesses don't set out to run HR on spreadsheets — it accumulates. A biometric device exports a raw punch log. A payroll executive downloads it, cross-checks it against a paper or Excel leave register, manually converts unexplained absences into Loss of Pay, re-keys overtime hours from a supervisor's WhatsApp message, and only then hands the whole thing to the person actually calculating salaries. Every one of those hand-offs is a place where a number can quietly change or drop out.
Three failure points show up in almost every manual setup, regardless of company size. First, attendance gets reconciled against payroll manually every month, which means the same late-marking rule or LOP threshold can get applied inconsistently from one cycle to the next, depending on who's doing the reconciling and how much time they have. Second, shift swaps between employees — common on factory floors and in retail — often go untracked in the source system, so the roster on paper stops matching who actually worked when, and overtime or night-shift allowances get calculated against the wrong shift entirely. Third, leave balances get calculated by hand, carried forward in a spreadsheet formula that one person understands, and it's common for balances to silently drift out of sync with the actual leave policy after a few cycles of manual edits.
None of these are people problems — they're data-location problems. When shift rosters, attendance punches, leave records and salary structures each live in a different place, reconciling them is unavoidably a manual, repetitive, error-prone task. The fix isn't asking people to be more careful; it's collapsing those four data sets into one system so there's nothing left to reconcile by hand in the first place.
Shift Scheduling: Fixed and Rotating Shifts
Shift management starts with defining shift templates — the start time, end time, break duration and grace period that apply to a given shift code. A fixed shift assigns one template to an employee permanently: an office role working 9:30 to 6:30 every working day is the simplest case, and it needs almost no ongoing scheduling effort once set up.
Rotating shifts are where manual scheduling starts to hurt. A factory running three shifts — morning, evening, night — typically rotates each worker through the cycle on a weekly or fortnightly basis, and the roster has to be published in advance, respect minimum rest periods between shift changes, and account for weekly-off rotation so the same people aren't always working the least desirable slot. Doing this in a spreadsheet is manageable for a dozen employees; it becomes genuinely difficult past fifty, especially once shift swaps enter the picture.
Shift swaps deserve specific attention because they're where manual systems most often lose accuracy. An employee scheduled for the morning shift asks a colleague to cover their night shift; the supervisor approves it verbally; and unless that swap gets recorded against the actual roster, every downstream calculation — late-marking, overtime, night allowance — runs against the wrong shift definition for both employees. A shift-management module that supports request-and-approve swaps directly against the roster closes that gap: the swap is logged once, and attendance is evaluated against whichever shift each employee is actually assigned to that day, not the one originally published.
Attendance Capture: Biometric and Geo-Tagged
Attendance capture needs to fit how and where people actually work, which is why most HRMS platforms support more than one method rather than forcing a single standard across the business. Biometric devices — fingerprint or face recognition — remain the standard for a fixed factory floor or office location, because they're fast, tamper-resistant, and don't depend on an employee's personal phone.
Field staff, delivery teams, site engineers and sales executives don't report to one location, so biometric hardware doesn't fit them at all. Geo-tagged mobile check-in solves this by capturing a timestamp alongside GPS coordinates at the moment of check-in and check-out, so a manager can confirm not just that someone marked attendance, but that they marked it from the expected site or territory. Combined with a photo capture at punch-in, this gives field attendance roughly the same integrity as a biometric device without needing hardware deployed at every location.
The important design point is that both methods should feed the same attendance record, evaluated against the same shift and grace-period rules. A business running biometric at head office and geo-tagged check-in for site staff shouldn't end up with two attendance systems that get reconciled separately at month-end — that just reintroduces the manual reconciliation problem this whole guide is about solving.
Grace Periods and Late-Marking Rules
A grace period is the buffer — commonly 10 to 15 minutes — after a shift's official start time during which a check-in still counts as on-time. It exists because treating every punch after the exact shift start as "late" is both unrealistic and demoralizing; traffic, a slow lift, a queue at the biometric device all eat a few minutes without anyone actually being negligent about attendance.
What matters operationally is what happens after the grace window closes, and this is where a written, system-enforced policy earns its keep. A typical structure works in tiers: a punch inside the grace period is on-time; a punch after the grace period but within a further short window is marked late with no immediate penalty; and a defined number of late marks within a month — three is a common threshold — automatically converts into a half-day deduction on the next occurrence, or on the one that crosses the threshold. Some policies also allow a small number of permitted late marks per month before any deduction applies at all, to absorb genuinely occasional delays.
The value of encoding this in the HRMS rather than applying it by eye each month is consistency. A manager reviewing attendance manually might let a valued employee's fourth late mark slide, while flagging someone else's third — not out of bad intent, just because manual judgment calls vary. A system-enforced rule applies the same threshold to everyone, every month, and the manager's role shifts from being the enforcer to reviewing and approving exceptions where a genuine reason exists.
Leave Application, Approval and Balances
Leave management has two halves that need to work together: the request-and-approval flow, and the balance that flow draws down against. An employee applies for leave against a defined leave type — earned leave, casual leave, sick leave, or a company-specific type — and the request routes to their reporting manager for approval, with the applicable balance visible to both parties before the decision is made.
The balance side is where manual spreadsheets consistently drift. Leave balances typically accrue on a defined schedule (monthly or annual), carry forward within policy limits at year-end, and get consumed as applications are approved — three separate calculations that have to stay in sync continuously. A spreadsheet formula that handles this correctly in January can silently break in June after a few manual edits, an inserted row, or a policy change nobody updated the formula for — and nobody notices until an employee's leave balance and the HR register disagree, usually at the worst possible moment: resignation or full-and-final settlement.
An HRMS keeps accrual, carry-forward and consumption as one continuously updated number rather than three things a person reconciles periodically. Because that same balance is what payroll checks before booking a day as paid leave versus unpaid, keeping it accurate in real time isn't just a leave-management convenience — it's a direct input into whether payroll gets LOP right.
See attendance, leave and payroll running as one system
Book a free QTT-ERP demo and we'll walk through shift setup, LOP rules and a live payroll run against your own attendance data.
Book a Free DemoAutomatic Loss of Pay (LOP) Conversion
Loss of Pay conversion is the step that turns attendance and leave data into an actual payroll deduction, and it's the single most common source of disputes in manual payroll runs. LOP applies whenever a day's attendance can't be covered by an approved, available leave balance or permission — an unexplained absence, a leave request that exceeds the remaining balance, or an unapproved half-day that never got regularized.
In a manual process, this means a payroll executive going day by day through an attendance sheet, cross-referencing it against a separate leave register, and manually deciding which gaps convert to LOP — a task that's tedious, slow, and inconsistent between employees and between months, especially under deadline pressure at month-end close.
An HRMS automates this by evaluating every day in the payroll period against the employee's shift, recorded attendance, and live leave balance, and booking any uncovered day as LOP automatically according to the configured policy — including how late-marking thresholds and half-day rules described earlier feed into the same calculation. Because the rule runs against the same data every cycle, an employee can see exactly why a particular day was marked LOP, rather than receiving a payslip with a deduction nobody can fully explain after the fact. That transparency alone eliminates a large share of the payroll disputes HR teams deal with every month.
Overtime Calculation
Overtime should be calculated against the shift an employee was actually scheduled for on that date, not a generic assumption of a standard workday — which matters as soon as rotating shifts or shift swaps are involved, since shift lengths and end times differ across the roster. Minutes worked beyond the shift's defined end time, after the grace period, are logged as overtime.
Overtime policy typically defines a rate multiplier — commonly 1.5x or 2x the employee's hourly rate, sometimes varying by whether the overtime falls on a weekday, weekly off, or statutory holiday — along with any minimum threshold before overtime is even counted, such as requiring at least 30 minutes beyond shift end before it's logged at all. In a manual process, this is usually collected from supervisors informally and re-keyed into payroll by hand, which is exactly the kind of hand-off where hours get rounded, missed, or double-counted.
When attendance capture, shift assignment and overtime policy live in the same system, overtime hours are computed directly from the actual punch data against the actual shift for that date, and the resulting value flows straight into the payroll run rather than arriving as a separate spreadsheet someone has to merge in before salaries are finalized.
Payroll Processing Tied to Attendance
Once shift data, attendance, leave and overtime are all resolved for a payroll period, the payroll run itself should be close to mechanical: take each employee's salary structure, apply LOP deductions for uncovered days, add overtime pay where applicable, apply statutory and voluntary deductions, and generate the payslip. The reason this step is so often the slowest part of the month in manual setups isn't the arithmetic — it's that the inputs to that arithmetic are scattered across a biometric export, a leave register and a supervisor's notes, and someone has to assemble them correctly before the calculation can even start.
A connected HRMS collapses that assembly step because attendance, leave and shift data are already resolved and correct by the time payroll runs — there's no separate reconciliation phase, because there was never a second copy of the data to reconcile against. A payroll executive's role shifts from data-gathering and cross-checking to reviewing exceptions: an employee flagged for unusually high overtime, a new joiner whose salary structure needs confirming, a resignee whose full-and-final settlement needs the final leave balance applied correctly.
This is also where connecting payroll to the rest of the financial system pays off beyond HR itself. Once salaries are processed, the payroll journal entry — gross pay, statutory liabilities, net payable — needs to land in the general ledger correctly and on time for the books to close. Keeping payroll inside the same platform as accounting means that entry posts automatically instead of being a manual journal someone builds from the payroll summary each month.
Statutory Compliance Basics: PF, ESI, PT, TDS
Indian payroll carries a fixed set of statutory obligations that apply regardless of industry, and getting them wrong carries real compliance risk, not just an accounting inconvenience. Provident Fund (PF) contributions apply to eligible employees based on basic wages up to the statutory ceiling, with both employee and employer contributions calculated and deposited on a defined schedule. Employee State Insurance (ESI) applies to employees below a defined gross wage threshold, again split between employee and employer contribution, and is recalculated whenever gross wages cross that threshold up or down.
Professional Tax (PT) is a state-level deduction with slabs that vary by state — a business with employees across multiple states needs the correct slab applied per employee's work location, not a single rate applied uniformly, which is a common manual error for multi-branch businesses. TDS on salary is computed based on the employee's declared tax regime and investment declarations, projected across the financial year and deducted proportionally each month, which means it has to be recalculated whenever salary structure, bonus, or declarations change mid-year.
What makes these genuinely hard to manage by spreadsheet isn't any single calculation — each one is well documented — it's that all four have to recompute correctly every time an upstream number changes: an LOP deduction reduces gross pay, which can shift the ESI threshold; a mid-year increment changes the TDS projection for the rest of the year; a transfer to another state changes the PT slab. An HRMS payroll module that keeps these rules configured against live attendance and salary data recalculates each of them automatically whenever an upstream figure changes, instead of requiring someone to remember every downstream statutory calculation a single change might affect.
Bringing It All Together
None of the individual pieces here — shift rosters, grace periods, leave balances, LOP rules, overtime, statutory deductions — are complicated in isolation. What makes HR and payroll hard in practice is that they all have to agree with each other, every single cycle, and manual processes have no mechanism to guarantee that agreement beyond someone's careful attention. QTT-ERP's HRMS module keeps shift management, attendance, leave and statutory payroll compliance in one system, connected to the same financial platform that runs the rest of the business, so a shift swap, a late mark or an LOP day is resolved once and reflected correctly everywhere downstream — instead of being reconciled by hand every month.
If month-end attendance reconciliation is still the worst day on your HR calendar, the fastest way to know whether that needs to change is seeing the shift, attendance and payroll rules from this guide running against your own roster and your own employees — not a generic demo dataset.
Stop reconciling attendance against payroll by hand
Book a free QTT-ERP demo and we'll configure a shift, a grace period and an LOP rule live, then run it through payroll.
Book a Free DemoFrequently Asked Questions
A fixed shift assigns an employee the same start and end time every working day, while a rotating shift moves them through a defined cycle — for example morning, evening and night across successive weeks — according to a published roster. HRMS software tracks which shift definition applies to each employee on each date, so attendance and late-marking rules are always checked against the correct timing rather than a single default.
A grace period is a configurable buffer, typically 10 to 15 minutes, after the official shift start time during which a check-in is still counted as on-time. Punches after the grace window are marked late, and most HRMS platforms let you set a second threshold — for example, three late marks in a month converts automatically into a half-day deduction — so the policy is enforced consistently without a manager reviewing every case by hand.
LOP conversion typically triggers when attendance falls short of what paid leave or approved permissions can cover — an absence with no leave application, a leave request beyond the available balance, or an unapproved half-day. The system compares the day's attendance status against the applicable leave policy at the moment payroll is processed and books any shortfall as unpaid, rather than a payroll executive deciding case by case at month-end.
Overtime is calculated against the scheduled shift duration for that specific date, not a fixed 9-to-5 assumption, which matters once employees rotate across shifts of different lengths. Minutes worked beyond the shift's defined end time, after any grace period, are logged as overtime and valued at the rate your policy specifies — often 1.5x or 2x the hourly rate — and carried straight into the payroll run instead of being tallied separately in a spreadsheet.
Both are valid capture methods and most HRMS platforms support either or both together. Biometric devices (fingerprint or face) suit a fixed factory or office location where employees report to one site. Geo-tagged mobile check-in suits field staff, delivery teams or multi-site businesses, since it captures location alongside the timestamp without requiring hardware at every site. Many businesses run biometric at head office and geo-tagged check-in for field and site staff, feeding one attendance record.
A properly configured HRMS payroll module calculates Provident Fund and ESI contributions against the applicable wage ceilings, applies professional tax per the employee's state slab, and computes TDS based on the employee's declared regime and investment declarations — recalculating each of these automatically whenever attendance, LOP or salary structure changes, rather than requiring a payroll executive to re-run each formula by hand every cycle.
Written by the QTT-ERP Team
Queen Touch Technology builds QTT-ERP, a connected ERP platform for Indian manufacturers, distributors and service businesses. This guide draws on patterns we see across HR and payroll implementations.