Moving payroll off spreadsheets: a practical checklist

Almost every growing Indian company runs payroll on a spreadsheet at some point. It is quick to set up, everyone knows how to use it, and for the first twenty or thirty employees it does the job. Then the team grows, salary structures multiply, a new state brings a different professional tax, someone joins mid-month, two people take unpaid leave, and the spreadsheet that once took an hour now takes three days and a lot of nervous checking.

Moving payroll into a proper system is not difficult, but it does need to be planned. Done carelessly, a migration simply moves old errors into new software. Done well, it gives you payroll that is accurate, auditable and largely routine. This guide explains why spreadsheet payroll breaks and sets out a practical checklist for moving off it safely.

Why spreadsheet payroll breaks

The trouble with spreadsheets is not that they are bad at arithmetic. It is that they allow anything, record nothing and depend on one or two people remembering how they work.

• Formula errors. A row inserted in the wrong place, a range that does not extend to the new joiner, or a hard-coded number typed over a formula. The total still looks plausible, so nobody notices.
• Version copies. "Payroll_March_final", "Payroll_March_final_v2" and "Payroll_March_final_revised" all exist. Which one did the bank transfer come from?
• No audit trail. When an employee queries their salary, there is no record of who changed their figures, when or why.
• Statutory deductions miscalculated. Provident Fund on the wrong base, professional tax using the wrong state's slab, or TDS that was never revised after an employee submitted their investment proofs.
• Payslips made by hand. Copying numbers from one sheet into a payslip template for every employee is slow and invites mistakes, and emailing them individually raises privacy risks.
• Attendance and LWP not linked. Leave without pay and absences are noted somewhere else and typed into the payroll sheet manually, if anyone remembers.

Each of these is manageable on its own. Together, they mean that the more the company grows, the less anyone can be sure the payroll is right.

Step 1: Clean the employee master data

Start with the people, not the payroll. Every employee needs a single, accurate record before the first payroll is run in the new system. Collect and verify:

• Full legal name, employee code, date of joining and, where relevant, date of leaving.
• Department, designation, reporting manager and work location (the state matters for professional tax).
• Employment type, such as permanent, probation, intern or freelancer, since this decides which deductions apply.
• PAN, UAN for Provident Fund, and ESI number where applicable.
• Bank account details for salary transfer.
• Current monthly gross or annual CTC and the date it took effect.

Expect to find gaps: missing PANs, duplicate records, people who left but were never marked as exited, or salaries that were revised by email and never updated. Fix them now. It is far easier to correct a record before migration than to explain a wrong payslip afterwards.

In Techno Team Via, the employee record is the single source for these details, so payroll reads from the same data HR maintains rather than a separate copy.

Step 2: Define the salary structure

Many spreadsheet payrolls have no written salary structure. Instead, the split between components lives inside formulas. Before migrating, write it down.

A common and simple approach is to define the gross salary and then split it into named components by percentage. For example, a company might use Basic at 50% of gross, House Rent Allowance at 15%, Leave Travel Allowance at 15% and Other Allowances at 20%. On a monthly gross of ₹60,000 that example would give Basic of ₹30,000, HRA of ₹9,000, LTA of ₹9,000 and Other Allowances of ₹12,000.

The split matters because statutory deductions are calculated on particular components, most importantly Provident Fund on basic wages. Changing the split changes deductions and take-home pay, so agree it with your finance lead and CA, document it, and apply it consistently. If you change it later, decide from which month the change applies so that months already paid are not affected.

Step 3: Set up statutory deductions

Next, configure the deductions the law requires. For most Indian companies this means Provident Fund, professional tax in the states where it applies, TDS on salary and, for employees in lower wage bands, ESI. Our plain-English guide to PF, PT and TDS covers what each one involves.

For each employee, confirm which deductions apply and on what basis. For TDS, record the tax regime the employee has chosen and their declarations, so the monthly deduction reflects their projected annual income rather than a flat guess. Check the professional tax state against the employee's actual work location, not the head office.

Techno IQ runs statutory payroll with PF, PT and TDS worked out for each employee, which removes the need to maintain those calculations in formulas. You should still have your CA review the set-up once before the first live run.

Step 4: Connect attendance and leave as payroll inputs

The most common monthly payroll adjustment is for days not paid: leave without pay, unapproved absences and joining or leaving mid-month. In a spreadsheet, these are typed in from a separate attendance record. In a system, they should flow in.

Make sure attendance is recorded consistently and that leave is applied and approved in one place. Leave beyond an employee's balance should be clearly marked as leave without pay so payroll can see it. Even when the inputs flow automatically, keep a human review step: the payroll team should see the month's LWP and absences as a suggested deduction and confirm them before the payroll is finalised.

When attendance and approved leave, including LWP, feed payroll directly, the month-end scramble to collect attendance from managers largely disappears.

Step 5: Run a parallel payroll

The most important safeguard in any payroll migration is a parallel run. For one or two months, run payroll in both the old spreadsheet and the new system, pay employees from the old one as usual, and compare the results line by line.

Differences are expected, and each one is useful. Some will be errors in the new set-up, such as a wrong state for professional tax. Others will reveal errors that the spreadsheet had been making for months. Investigate every difference, decide which figure is correct, and fix the source rather than adjusting the output. Only when the two runs agree, or every difference is explained and accepted, should you switch.

Use a comparison table like the template below for each employee or, at minimum, for the totals and a sample of employees.

Keep the completed tables. They are a record of why the new payroll is trusted, and they will help if a query comes up months later.

Step 6: Reconcile, lock and distribute

Once you go live, three habits keep payroll clean.

Reconcile every month

Before releasing salaries, reconcile the payroll total with the previous month. Explain every significant change: joiners, leavers, revisions, LWP and one-off payments. After payment, reconcile the bank transfer with net pay, and statutory deposits with the deductions shown in payroll.

Lock a month once it is paid

A paid month should not change. Once salaries have been transferred, mark the month as paid and lock it so that figures, payslips and reports for that month stay as they were. Corrections belong in the next month as arrears or recoveries, with a clear note, not as silent edits to history. Techno IQ locks a payroll month once it is marked paid, which is one of the clearest differences from a spreadsheet anyone can overwrite.

Distribute payslips properly

Generate payslips from the payroll itself, not from a separate template. Employees should be able to see and download their own payslips securely, rather than receiving attachments by email. This saves HR time each month and reduces the risk of a payslip reaching the wrong inbox.

The migration checklist

1. Agree the go-live month and the one or two parallel-run months before it.
2. Export the current employee list and payroll spreadsheet; archive a read-only copy.
3. Clean the employee master data: names, codes, joining and exit dates, PAN, UAN, ESI number, bank details, work location and employment type.
4. Remove or mark exited employees; resolve duplicates.
5. Write down the salary structure and component split; confirm it with finance and your CA.
6. List exceptions: fixed stipends, consultants, special allowances, pending arrears.
7. Configure PF, professional tax by state, TDS (with each employee's regime and declarations) and ESI where applicable.
8. Set up leave types and balances, and confirm how LWP is recorded.
9. Connect attendance and approved leave to payroll inputs.
10. Run the first parallel month; complete the comparison table and fix differences at source.
11. Run the second parallel month if the first had many differences.
12. Go live: pay from the new system, reconcile, and lock the month once paid.
13. Publish payslips for employees to view and download.
14. Review the process after the first three live months and tidy up anything still manual.

Making the switch

Moving payroll off spreadsheets is mostly about discipline: clean data, a written salary structure, correct statutory set-up, inputs that flow from attendance and leave, and a parallel run that proves the new numbers before anyone is paid from them. Once that groundwork is done, each month becomes a review rather than a rebuild, and paid months stay exactly as they were.

If you are planning the move, book a demo to see how Techno IQ handles statutory payroll, attendance-linked inputs, locked months and payslips.