A Timesheet Is Not a Payroll File

A timesheet answers who worked, where, and for how long. A payroll file answers how those hours should be paid. Converting one into the other is a mapping and approval process, not an export button. If you send finance the raw in and out columns, payroll has to invent policy during the most time-sensitive week of the month. If you send only a net-hours total, payroll cannot apply overtime, holiday, leave, or contractor rates correctly. The conversion is finished only when a wage type, not a punch, is ready to post.

The conversion should produce a versioned hours file with one row per employee per pay period, or per day if the payroll engine needs daily buckets. Each row needs a stable employee or contractor ID, the period, regular hours, overtime hours, holiday or weekly-off hours, paid leave days or hours, unpaid leave or LOP, and any site or cost-centre code billing requires. Totals without those categories force finance to reverse-engineer decisions you already made on the floor, which is how two clerks produce two different salary files from the same week.

Decide the source of truth before mapping columns. For shift teams, the source is usually approved attendance plus approved leave, not a typed hours cell. For project or billable teams, the source may be an approved weekly timesheet with site tags. Mixing both without a rule creates two numbers for the same person. Write which source wins, and keep the losing source as supporting evidence rather than a second payable file. If both files are allowed to pay, you will double-pay the first time a busy month needs overtime and a project tag.

• Treat conversion as mapping and approval, not as a raw punch export
• Keep regular, overtime, holiday, leave, and LOP as separate columns
• Choose one source of truth per employee group
• Version the hours file so a later correction does not silently replace the original

Run Approval Before You Map Anything

Unapproved timesheets should not enter payroll mapping. The operational review belongs with the supervisor who knew the shift: confirm the person worked, confirm the site, confirm overtime was required, and confirm leave is already applied. Payroll’s job is to check identifiers, pay codes, and period totals, not to decide whether Tuesday’s extra hour was real. If mapping starts while those operational questions are still open, finance will either guess or delay, and both outcomes cost more than a 20-minute site review.

Set a cutoff that leaves time for that review. A practical pattern for a month-end salary run on the last working day is: employees raise corrections by the 22nd, supervisors approve by the 24th, HR validates leave and exceptions by the 26th, and payroll receives a locked file on the 27th. After cutoff, a change needs a higher approval and a new file version. A supervisor editing a cell on the 28th is how payslips and the hours file diverge. Publish the dates on a one-page calendar so sites do not treat cutoff as a rumour.

Reject incomplete rows instead of filling them during conversion. A missing check-out, an unapproved overtime value, a leave day still in pending, or a contractor row without a client site should stay on an exceptions list. Conversion of the clean population can proceed. Waiting to convert until every row is perfect often delays payroll; converting the dirty rows as if they were clean creates off-cycle corrections that are more expensive than holding ten people for 24 hours.

• Supervisors approve work and overtime; payroll approves identifiers and pay codes
• Publish employee, supervisor, HR, and payroll cutoff dates
• Lock ordinary edits after cutoff and version any late correction
• Convert the clean population while exceptions remain on a separate list

Map Columns Payroll Can Actually Post

Build a field map once and reuse it. Attendance or timesheet fields on the left, payroll fields on the right, with the transformation in the middle. Employee code in the timesheet must match the salary register or contractor master. Work date must land in the correct pay period. Paid duration becomes regular hours up to the threshold. Time above the threshold becomes overtime only if approved. A public holiday worked becomes a holiday or premium code, not generic overtime. Approved paid leave becomes leave days or leave hours, never absence.

Use a worked mapping for one employee. Priya’s approved week shows 40.00 regular hours, 3.50 approved overtime, 1.00 paid casual leave day, and 0 LOP. The payroll import should receive four buckets, not 43.50 net hours. If the engine expects days for monthly-paid staff, convert 40.00 hours at an 8.00-hour day into 5.00 payable attendance days, keep 3.50 overtime hours in the overtime wage type, and keep the leave day in the leave wage type. Collapsing those into one number makes PF, OT, and leave balances impossible to explain.

Holiday and weekly-off work need their own codes even when the multiplier looks like overtime. A weekly-off duty at 2x is not the same wage type as weekday overtime at 1.5x. If Tally, greytHR, or an in-house engine has separate overtime and holiday pay heads, sending one OT column will post the wrong ledger. Map the category first, then the hours, then the rate. The rate should live in payroll, not be hardcoded in the timesheet, unless you are producing a billing file rather than a salary file.

• Maintain a reusable map from timesheet fields to payroll wage types
• Example: 40.00 regular, 3.50 OT, 1.00 leave day, not 43.50 net hours
• Keep holiday and weekly-off hours out of the ordinary overtime column
• Let payroll own the rate; let the timesheet own approved hours and category

Apply Rounding, Breaks, and Period Cutoff

Round once, at the end, according to a written rule. Rounding every punch to the next 15 minutes and then subtracting a break that was also rounded produces a different month from calculating in minutes and rounding the payable hours. A common payroll-friendly rule is nearest 15 minutes on the final paid duration, or nearest 0.25 decimal hour. Document whether you use nearest, up, or down, because a month of 22 shifts can move a person by an hour if every punch was rounded in the same direction.

Subtract unpaid breaks before overtime is classified. If a shift includes a 30-minute unpaid lunch, 9 hours 30 minutes on site is 9.00 paid hours, which is 8.00 regular and 1.00 overtime at an eight-hour threshold. If the break is paid, do not subtract it. If the employee clocked a 50-minute lunch against a 30-minute unpaid rule, policy must say whether the extra 20 minutes are unpaid automatically or only after review. Conversion should apply that rule, not leave payroll to guess from a comments column.

Period ownership has to be explicit for night work and for corrections. A shift that starts on the 31st at 22:00 and ends on the 1st at 06:00 belongs to one pay period by rule, usually the start date. A correction approved on the 3rd of the next month for a missed punch on the 28th belongs to the period of the work date, not the approval date, unless you run an off-cycle. Put the work date, period code, and approval timestamp on the row so a late approval cannot move hours into the wrong month.

• Round the final paid duration, not each punch and each break independently
• Classify overtime after unpaid breaks are subtracted
• Assign cross-midnight shifts to one documented period owner
• Keep work date and approval date separate so late fixes do not jump periods

Export to Tally, greytHR, or In-House Payroll

Match the destination, not your favourite spreadsheet layout. Tally and many accounting-led payroll setups want employee code, pay-head, and amount or hours. greytHR and similar HR payroll tools often want an attendance import with present days, weekly offs, paid leave, LOP, and overtime hours in named columns. An in-house engine may want a CSV with wage-type codes. Produce the mapped file from the approved timesheet; do not retype numbers into each system’s screen. Retyping is how 3.50 overtime becomes 3.00 because someone rounded in their head.

Validate the file before import. Check that every employee code exists in the destination master, that joiners and exits are inside their employment dates, that overtime hours are not negative, that leave days do not exceed the period, and that the sum of regular hours matches the operations summary you already signed. A single unmatched employee code can fail the whole import, which is why a 10-row validation report is cheaper than discovering the failure after the bank file is due. Run that validation on a copy, not on live payroll.

Keep the source beside the mapped export. Store the approved timesheet, the mapping table version, the generated import file, and the import acknowledgement or error log. If greytHR rejects three rows, fix those rows in a new version rather than editing the live payroll screen and losing the link back to attendance. The goal of conversion is a reproducible handoff, not a successful paste that nobody can reconstruct in December when Form 16 questions arrive.

• Generate the import shape the destination expects; do not retype hours
• Validate employee codes, dates, overtime, leave, and total hours before import
• Retain source timesheet, mapping version, export file, and error log together
• Correct rejected rows in a new version instead of silent screen edits

Split Contractor Files from Employee Payroll

Contractors and employees can share a timesheet collection process and still must not share a payroll import. Employees need salary-register fields: LOP, paid leave, statutory-ready totals, and overtime wage types. Contractors often need billable hours by client site, a billing rate, and an invoice cycle that may not match the salary calendar. Putting both populations in one import is how a contractor receives a leave balance, or an employee is billed to a client at the contractor rate. Split the files even when one supervisor approved both groups on the same Friday.

Use different identifiers and different mappings. The contractor’s vendor code is not the employee code. Site hours that a staffing firm invoices to a client may include travelling or waiting rules that salary overtime does not. If a person converts from contractor to employee mid-month, close the contractor timesheet on the last contractor day and open an employee record on the joining date. Do not carry hours across the employment-type change on one row. A 15 August conversion with 80 contractor hours and 88 employee hours is two files, not a blended 168.

Attend Mitra is built for that connected conversion. Verified attendance, approved leave, and shift context can be turned into payroll-ready hours without a second typing step, while contractors and employees remain separable populations. Supervisors approve the timesheet, payroll receives mapped categories, and the same record can support a Tally or greytHR import without asking finance to interpret raw punches. The mapping is then a configuration you reuse, not a monthly invention in a new spreadsheet tab. Build the source grid with how to create employee timesheets, classify extras using how to calculate overtime from timesheets, and if punches still live on devices see how to export biometric attendance to payroll. Integrations sit under payroll software.

• Export employees and contractors as separate files with separate mappings
• Do not send contractor billable hours into the employee salary import
• Split mid-month employment-type changes on the conversion date
• Keep approval, mapping, and destination import in one auditable chain