Payroll Is the One Module That Has to Be Exactly Right, on a Fixed Date

Not out of the box, and no honest consultant will tell you otherwise. A global ERP ships a payroll engine that can calculate almost anything, but it does not arrive knowing your income tax slabs, your social insurance rates, your gratuity rule or your filing formats. Those come from a localisation pack, a partner-built module, or configuration we write for you. Before you commit, ask three questions: does a maintained localisation exist for your country, who updates it when the rules change, and is that update included in what you are paying. If the answers are vague, plan for a local payroll engine alongside the ERP instead.

Often yes, and we say so even though it is the smaller piece of work for us. Keep the specialist system or the bureau when your country has heavy statutory complexity, when the ERP has no maintained localisation for you, or when a single compliance mistake carries real penalties. In that case the ERP owns the employee master and the general ledger, and payroll sends back a salary journal and payment file each month. Move payroll into the ERP when your rules are simple or well covered by a localisation, when headcount is modest, and when you want one employee record driving pay, project costing and access rights without a sync in the middle.

Through a cut-off date and a set of rules, not through a spreadsheet emailed on the last day. Shift patterns define expected hours, the attendance record captures actual hours from a biometric device, an app or a supervisor entry, and rules turn the difference into paid overtime at the correct multiplier, unpaid absence, or a leave deduction from an accrued balance. Everything approved before the cut-off goes into this run and everything after it goes into the next one, as arrears. This matters more than people expect, because most payroll errors originate upstream in attendance data, not in the payroll calculation itself.

As a single salary journal generated by the committed run, split the way finance needs to read it. Gross pay is debited to salary cost by department and cost centre, employer contributions are debited to their own expense lines, employee deductions and employer contributions are credited to statutory liability accounts until they are paid over, and net pay is credited to a salaries payable account that clears when the bank file settles. Add a monthly accrual for unpaid leave liability and for any bonus provision. The test of a good setup is simple: the total of the bank payment file reconciles to the net pay credit in the journal, to the cent, every month.

Salary visibility is restricted by role, and this is the one area of the ERP where we recommend being stricter than feels comfortable. A line manager sees attendance, leave and performance for their team but not pay. HR operations sees pay for the population they administer. Finance sees the posted journal totals rather than individual payslips. Directors' pay is often ring-fenced to a named list of two or three people. On top of that, the audit trail records who viewed or changed pay data and when, which is a genuine requirement rather than a compliance decoration, because the first sign of a problem is usually an access log entry nobody can explain.

By parallel running, and we will not go live without it. Run the old and the new payroll on the same month's data for at least two cycles, three if you have complex shift or overtime rules, and reconcile every difference down to the individual employee rather than accepting a total that looks close. Year-to-date figures for tax and statutory contributions must be loaded and verified, because a mid-year switch that loses them produces wrong deductions for the rest of the year. Payroll is the one cutover where a rollback does not undo the damage, because people have already seen their payslip and the trust is already spent.