The first payroll run at a new client
"We go live on the first of November. Five hundred people, and the salaries have to be right the first time. What do we do in the last week of October?"
What is really being asked
He wants a rehearsal. The answer is that the system gives you one for free: a payroll that is created but not posted can be looked at, argued about, deleted and created again as many times as you like. Nothing has happened until somebody posts.
So the first run is not a leap. It is a loop: create unposted, check, delete, fix, create again. Do it three or four times in the week before go-live and the real run is uneventful.
This page is the order to do it in. For the setup that has to exist before any of it, see the order of setup.
What you need in place first
Tick every one of these off before you create anything. A missing item here does not fail loudly; it quietly produces a wrong number.
- Payroll Period - the period exists and its dates are right.
- Wage Type - every earning and deduction the client pays, each with the right direction. See value lists.
- Salary Structure - the shape of pay per grade.
- Pay Rate - the bases the arithmetic uses.
- Employee Policy Profile - and every man assigned to one, because this is what carries his calendar, his tax calendar, his overtime pairing and the contribution schemes he is in.
- Calendar and Public Holiday - because attendance resolves through them. See calendars and shift times.
- Recurring Payments and Deductions - every man's salary on record, dated from his joining date or from go-live.
- Contribution Scheme - if there is a provident fund or a statutory contribution, ticked Active, with a rate line covering the period end. See set up a provident fund from nothing.
- Payroll Tax Slab - the current year's slabs.
- Opening balances agreed: leave entitlements, loan balances, and the contribution opening figure if there is a fund carried over from an old system.
Do this
Load the attendance for the period. Punches in, or the month's attendance accepted as complete. The run is only as good as this, and the commonest cause of a bad first run is a half-loaded month.
Create the Payroll Attendance document. Open Payroll Attendance for the period. This is the document that turns attendance into paid and unpaid days, and it is what pro-rates a joiner or a leaver - the payroll run does not. No document, no pro-ration, and a man who joined on the fifteenth is paid a full month. See a man joins on the fifteenth.
Check the day counts on a sample of five men now, before you go near the payroll. It is far cheaper to find a wrong day count here than in a payslip.
Process the period documents, in this order, so that each is in place before the run reads it:
- Process Overtime, if there is overtime. See overtime on a holiday pays a different rate.
- Employee Payroll Loan, if anybody has a loan.
- Employee Additional Payment Or Deduction, for anything one-off this period.
A document created after the payroll is not picked up. If you add one later, delete the payroll and create it again. There is no refresh.
Create the payroll, unposted. Open Payroll for the period and run it. Nothing is committed and nothing is paid. Treat this as the rehearsal it is.
Check the four totals, in this order. Each one is computed, so a figure that is not what you expect means something upstream is wrong, not that you need to type over it:
- Gross is basic plus the gross allowance.
- Net is basic plus allowance minus deduction.
- Payment is net minus tax.
- The headcount on the run, against the client's own list.
Start with the headcount. A run short of five men is a far bigger problem than a run whose total is a few thousand out, and it is the easier of the two to miss.
Check five men by hand, chosen deliberately. Not five at random. One of each of these:
Pick What it proves The highest-paid man The tax slabs, and the contribution ceiling The lowest-paid man The minimum wage floor, and that no deduction drives him negative A mid-month joiner That Payroll Attendance pro-rated him A man with a loan That the installment came across once, and once only A man with overtime That the hours and the rate both landed Work each one out on paper from the maths before you look at the payslip. Checking against your own arithmetic is the only check that finds a wrong configuration; reading the screen and nodding finds nothing.
Compare against the old system. Ask the client for last month's payroll register from whatever he was running before, and compare man by man on the top fifty by salary. Every difference is either a configuration fault you must fix or a deliberate change the client must sign off. There is no third category, and "it is close enough" is how a go-live goes wrong in month two rather than month one.
Fix, delete, re-create. Correct whatever you found, delete the payroll, and create it again. An unposted payroll deletes cleanly. Do this as many times as it takes, and expect three or four rounds on a first run. Nothing in the loop costs anything except your afternoon.
Only then post. Open Post Payroll and post the period. After this the accounting entries exist and the payroll is locked: an attempt to delete it is refused with "Payroll: 24 cannot be deleted. This Payroll already Post".
Know the way back before you need it. A posting can be reversed, and the reverse date may not be earlier than the posting date: "Reverse Date: ... cannot be less than Posting Date: ...". Reverse the posting, then the payroll deletes again. The full unwind order, with the attendance documents in it, is on a punch was wrong and payroll attendance is already made. Read it once before go-live rather than on the day.
Where two clients differ
| Factory, 420 workers | Office, 80 staff | |
|---|---|---|
| What drives pay | Attendance and overtime | Mostly a fixed monthly salary |
| The risk in the first run | Wrong day counts, wrong overtime | Wrong tax, wrong allowances |
| Contribution | Usually a statutory scheme | Often a provident fund as well |
| The five men to check | Mostly attendance cases | Mostly tax cases |
| Where the old system's register differs | Overtime and unpaid days | Tax and reimbursements |
How you prove it worked
- The headcount on the run equals the client's list of people to be paid. Not approximately.
- Your five hand-worked men agree to the rupee with the payslips.
- The top fifty agree with the old system's register, or every difference is written down and signed off.
- The four totals are internally consistent: gross minus deduction and tax arrives at payment. If they are not, a wage type has the wrong direction.
- No man's net is negative, and no man's net is zero unless somebody intended it.
- After posting, attempt to delete the payroll and confirm you get the refusal above. That is how you know the posting really happened.
What will go wrong
- No Payroll Attendance document, so nobody is pro-rated and every joiner is paid a full month. The most expensive first-run fault there is.
- The payroll is created before the loan or the one-off documents. They are not read, and nobody notices until the men do.
- The run is posted on the first go because it looked right. Posting is not the hard step; checking is. Use the unposted loop.
- The totals are checked and the headcount is not. Five men missing from a run is invisible in a total and very visible on the factory floor.
- The contribution scheme is not ticked Active, so the fund is simply absent from the first run with no error anywhere. Check for the deduction line, not for a message.
- Nobody worked a single payslip out by hand. Then the first configuration fault is found by an employee, which costs the client's trust in a way the arithmetic never will.