Skip to main content

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.

Do this​

  1. 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.

  2. 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.

  3. Process the period documents, in this order, so that each is in place before the run reads it:

    1. Process Overtime, if there is overtime. See overtime on a holiday pays a different rate.
    2. Employee Payroll Loan, if anybody has a loan.
    3. 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.

  4. 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.

  5. 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.

  6. Check five men by hand, chosen deliberately. Not five at random. One of each of these:

    PickWhat it proves
    The highest-paid manThe tax slabs, and the contribution ceiling
    The lowest-paid manThe minimum wage floor, and that no deduction drives him negative
    A mid-month joinerThat Payroll Attendance pro-rated him
    A man with a loanThat the installment came across once, and once only
    A man with overtimeThat 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.

  7. 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.

  8. 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.

  9. 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".

  10. 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 workersOffice, 80 staff
What drives payAttendance and overtimeMostly a fixed monthly salary
The risk in the first runWrong day counts, wrong overtimeWrong tax, wrong allowances
ContributionUsually a statutory schemeOften a provident fund as well
The five men to checkMostly attendance casesMostly tax cases
Where the old system's register differsOvertime and unpaid daysTax and reimbursements

How you prove it worked​

  1. The headcount on the run equals the client's list of people to be paid. Not approximately.
  2. Your five hand-worked men agree to the rupee with the payslips.
  3. The top fifty agree with the old system's register, or every difference is written down and signed off.
  4. 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.
  5. No man's net is negative, and no man's net is zero unless somebody intended it.
  6. 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.