Overtime Disputes Are Really Data Disputes

When employees and management argue about overtime, they are almost never arguing about the multiplier. The rate is usually agreed. The argument is about the hours — whether someone actually stayed until 9 p.m., whether the extra Sunday was authorised, whether the 20 minutes before shift start counts.

This is why overtime cannot be solved inside payroll software alone. If the overtime figure is typed into a payroll sheet from a supervisor's notebook, no amount of calculation sophistication makes it defensible. The number has to come from the same verified attendance record the employee can see in their own app.

Once the hours come from a verified log, the argument collapses into something checkable. The clock-out time is recorded with a server timestamp, tied to a verified identity, and where geo-fencing is enabled, tied to a location. The remaining question is only whether the extra hours were authorised, which is a management decision rather than a data reconstruction exercise.

• Overtime arguments are about hours, not about rates
• A figure typed from a supervisor's notebook cannot be defended
• Hours must come from the same log the employee can see in their app
• Verified timestamps reduce the dispute to authorisation only

Building the Overtime Component

Overtime is a pay component with its own rules, and treating it as one keeps the payroll structure clean. In Attend Mitra you define pay components and assemble them into salary templates, which are then attached to employees as salary contracts. Overtime sits alongside basic, allowances, incentives, and deductions rather than being bolted on at the end.

The rules worth deciding explicitly are the threshold after which hours count as overtime, the multiplier — and whether it differs for weekly offs and declared holidays — and whether overtime is capped per week or per month. Many Indian businesses run a higher multiplier on week-offs and public holidays, and defining both rates up front avoids the recurring end-of-month question.

The interaction with statutory deductions is the part most often missed. Whether overtime forms part of wages for EPF and ESIC purposes affects both the employee's take-home and the employer's contribution, and it is a decision that should be made once, documented, and applied consistently rather than reconsidered each cycle. Attend Mitra keeps EPF, ESIC, professional tax, and TDS as configurable settings so this treatment stays consistent across every run.

• Define overtime as a pay component within the salary template, not an afterthought
• Set the daily or weekly threshold above which hours become overtime
• Configure separate multipliers for normal days, week-offs, and holidays
• Decide once how overtime is treated for EPF and ESIC, then apply it consistently
• Cap overtime per week or month if your policy requires it

Loss of Pay: The Other Half of the Calculation

Overtime adds; loss of pay subtracts. Both should be derived from the same record set, and both are the lines employees check first on a payslip. LOP is where manual payroll most often produces errors that damage trust, because it is calculated under month-end pressure from incomplete information.

The derivation should be mechanical. Paid days are days with verified attendance, plus approved paid leave, plus holidays and declared closures from the company calendar, plus rostered week-offs. Whatever remains is unapproved absence and becomes a loss of pay adjustment. Nobody makes a judgement call in the payroll run because the judgement was already made when leave was approved or rejected during the month.

Attend Mitra applies LOP adjustments within the payroll run and prorates accordingly. Because the underlying approvals carry a timestamp and an approver, a disputed deduction is answered by opening the record rather than by reconstructing the month.

• Paid days = verified attendance + approved leave + holidays + rostered week-offs
• The remainder is unapproved absence and becomes loss of pay automatically
• No judgement calls inside the payroll run — they happened at approval time
• Every LOP line traces to a dated approval with a named approver

Statutory Deductions Without the Annual Scramble

Indian payroll carries a statutory layer that has to be configured rather than remembered. EPF contributions with the wage ceiling and the split between the provident fund and the pension scheme. ESIC contributions with their eligibility threshold. Professional tax, which varies by state. TDS on salary income.

Attend Mitra holds each of these as configurable settings — PF settings, ESI settings, PT slabs, and TDS settings — with professional tax slabs available for multiple states. Keeping them as settings rather than hard-coded logic is what allows a rate revision to be a configuration change instead of a support ticket.

Be precise about the boundary between calculation and filing. Attend Mitra computes contributions and deductions and reflects them on payslips. Generating statutory return files, issuing Form 16, and provisioning gratuity are separate processes that happen outside the platform. Knowing exactly where that line sits is more useful than a vendor claim that everything is handled.

• EPF with wage ceiling and the provident fund versus pension scheme split
• ESIC contributions applied against the eligibility threshold
• State-wise professional tax slabs configured rather than hard-coded
• TDS settings maintained as configuration for annual revisions
• Calculation and reflection on payslips is distinct from statutory return filing

Running the Cycle and Paying People

A payroll run in Attend Mitra pulls attendance and leave for the period, applies each employee's salary contract, computes earnings including overtime, applies loss of pay, and applies statutory deductions. The result is reviewable as run items before anything is published, which is where errors should be caught rather than after payslips reach employees.

Payslips are generated as PDFs, downloadable individually or as a ZIP bundle for the entire run, and employees can access their own payslips in the mobile app rather than requesting them. That single change removes a recurring category of HR requests.

Payment is handled through a bank transfer file containing account numbers and IFSC codes in a NEFT-compatible format for upload to your bank's bulk transfer facility. Employee bank details are stored per employee, so the file is generated rather than assembled. Verify the format against your specific bank during the trial — bulk upload formats vary between banks and this is worth confirming before your first live cycle.

• Review run items before publishing, not after payslips are distributed
• Payslip PDFs individually or as a ZIP for the whole run
• Employees self-serve payslips from the mobile app
• NEFT bank transfer file generated from stored account and IFSC details
• Confirm the transfer file format against your bank during the trial