The monthly payroll cycle

What this achieves

Payroll is the one journey that repeats on a fixed date whether you are ready or not. This guide sets out the sequence a period follows, what has to be settled before calculation, and what your options are once a run is locked.

The shape of it

Everything that feeds pay has to be final before pay is calculated, and everything that follows pay depends on the run being finalised. The work is therefore front-loaded: by the time you calculate, the answer should already be decided.

Two facts govern the whole cycle. A run is approved by a second administrator unless you have deliberately turned that off, and a finalised run cannot be edited. Plan around both.

1. Inputs settle: leave and attendance

Approved leave and reconciled attendance are what make the calculation right, so they close first. Managers clear their leave approvals, and where people are paid on hours worked, attendance is reviewed and approved for the period.

Set your own cut-off earlier than the pay date and hold it. Setup Considerations: attendance and pay explains what attendance actually feeds into pay, which is the difference between a cut-off that matters and one that is a formality.

2. Period-specific inputs are gathered

Anything unusual about this period goes in before calculation: a one-off award, a new employee loan or a change to a repayment schedule, and any pay or contract change taking effect this period.

Where you run variable pay, this is also the point for approving a commission batch and releasing withheld variable compensation, so approved amounts reach the run rather than the next one.

3. The run is created and inputs are resolved

Run a payroll cycle covers the mechanics. The run is created against one pay group and one period, then inputs are gathered — which resolves who is actually in the run.

Check the headcount at this point rather than later. A number that differs from what you expect is usually a joiner, a leaver, or a pay-group membership that changed, and all three are easier to understand now than in a payslip.

4. The run calculates

Calculation produces draft payslips. Drafts are marked as drafts, and recalculating is cheap — do it as often as you need before the run moves on.

Read the totals for employees, gross, deductions, net, and employer cost as a set. A movement in one without a matching movement in another is the pattern worth chasing. Humavera can narrate the variance against the prior period and flag anomalies; treat that narration as a prompt for where to look, not as a verdict, and check what it points at yourself.

5. The run is approved

Review and approve a payroll run is a separate person’s job by default. Whoever prepared the run cannot approve it, and that is enforced rather than encouraged.

A company with one payroll administrator can change that. Settings → Payroll carries a Payroll approval setting with a Two people must approve switch. Turn it off and the same administrator can run payroll and approve it. Turning it off asks you to confirm, because this is the control that stops one person paying money out alone, and every run then records that the same person started it and approved it. That record is permanent and stays on the run even if you switch back.

Decide before pay day rather than on it. If you keep two approvers, make sure the second administrator has the access they need well in advance — a missing second approver is the most common reason a cycle stalls at the last step. If you turn the requirement off, do it knowing what you have traded.

Where an approval workflow is bound to payroll, the workflow decides who approves and this setting does not change it.

6. The run is finalised

Finalising locks every payslip and closes the period. It cannot be undone.

Everything after this point is downstream of a fixed record: employees see their payslips, the figures feed reporting, loan instalments due in the period are deducted, and approved commission lands according to its plan’s timing.

7. Payment and payslips

The finalised run produces the payment file your bank expects, in the layout defined by your bank export format. Employees read the outcome under their own payslips.

8. Reporting closes the period

Produce payroll reports covers the period’s own reporting. Where you run several entities, consolidated reports roll them up — and they segment by currency rather than blending currencies, which is what makes a multi-entity total meaningful.

When something is wrong after finalisation

There is no edit. There are two routes, and choosing between them is the decision:

Pay it now with an off-cycle run, which produces its own payslips and its own payment file, and its own work.
Correct it in the next regular period, which is usually right for a small difference.

Setup Considerations: corrections sets out how to decide between the two, and it is worth reading before the month you need it rather than during it.

What repeats and what does not

The sequence above repeats every period. What does not repeat is the configuration behind it: pay groups, statutory profiles, pay elements, and eligibility rules are set once and revisited when something changes. If you are correcting the same thing every month, that is a configuration problem wearing a monthly-cycle costume — Setup Considerations: eligibility rules is often where it lives.

What happens next

A closed period feeds everything that reads pay: reporting, compensation planning, and total reward statements. When someone leaves mid-period, their last payment runs through a final settlement rather than the ordinary cycle.