Payroll Cycle

Why is the cut-off the date that governs?

Because it is the moment the period stops accepting information. Everything known before it is in the run; everything arriving after it belongs to the next one, however distant the pay date still is. Employees reason from the pay date instead, which is why a change confirmed a few days before payment feels as though it should appear and does not. Naming the cut-off in every communication about pay, and repeating it whenever a change is requested, removes most of that friction at no cost. It is also the only date in the whole sequence the payroll owner genuinely controls, since the pay date is fixed by expectation and the processing window is fixed by the work.

What happens to a change that misses the cut-off?

It carries. A salary revision, a bank change, an approved claim or a corrected attendance record that lands after the close does not disappear; it enters the following run, and the amount owed for the earlier period follows as arrears. That is an acceptable outcome as long as somebody tells the employee it is happening, ideally the person who approved the change rather than payroll after the fact. What turns a deferral into a complaint is silence, because from the employee's side an approved change that produced no visible effect looks as though it was lost rather than scheduled, and the natural next step is to escalate.

Should the pay period match the calendar month?

Aligning the two is simpler to explain and easier to reconcile against the ledger, but it forces the cut-off well before the period ends, so the last stretch of attendance is estimated and corrected afterwards. Offsetting the period so it closes before the pay date removes the estimate, at the price of the month being paid not matching the month on the calendar, which confuses everybody at least once. Neither arrangement is wrong. What matters is choosing deliberately, writing the choice down where new joiners will encounter it, and not revisiting it casually, because a change to the shape of the cycle is felt by the entire workforce simultaneously.

How is somebody who joins mid-cycle paid?

Two questions decide it, and they are separate. First, does the joining date fall before or after the cut-off for the current period? If after, the person's first payment covers two periods at once, which is worth saying at the offer stage rather than leaving them to discover it on the first pay date with rent due. Second, how is a part period calculated - from the number of days in the actual month, or from a fixed divisor applied uniformly? Both methods are defensible and produce different amounts for the same person on the same joining date, so the method has to be documented and applied consistently rather than decided case by case by whoever configures the record that week.

Onboarding sequencing carries the rest of the risk. Bank details, statutory identifiers and declarations all have to exist before the first run, and a new joiner is the one population where none of them are already on file. Where onboarding paperwork is gathered after the person starts, the first run either omits them or pays them on incomplete data, and both outcomes take longer to repair than to prevent. Making the collection of those items a condition inside the [employee onboarding software](/employee-onboarding-software) checklist, rather than an early task in the first week, is the cheapest fix available and it works for every future hire without anybody having to remember it. The alternative is a manual chase that succeeds only while the person doing it is at their desk.

How does a leaver move through the cycle?

A departure creates the mirror-image problem, and a more expensive one, because the leverage disappears the moment the person goes. If the last working day falls before the cut-off, the final period can be paid in the ordinary run. If it falls after, the person is paid normally and a settlement follows separately, which means two events to track instead of one. Either way the payroll owner needs the exit date confirmed by the cut-off rather than on the last day, and needs to know whether anything is to be recovered - a notice shortfall, an asset, an advance - while a payment is still pending and the conversation is still an easy one to have.

Recoveries and dues rarely sit in one place. Leave balances come from the leave system, notice terms from the employment contract, assets from whoever issued them, and any loan or advance from finance, each with its own owner and its own idea of urgency. Assembling those across functions after somebody has left is markedly harder than assembling them a fortnight before, which is the practical argument for triggering the settlement workflow from the resignation rather than from the last working day. Doing it early also gives the employee a figure they can query while they are still contactable and still inclined to reply, which is worth more than any escalation route available afterwards.

Why do arrears accumulate?

Arrears are the normal consequence of a decision taking effect from a date earlier than the run that first pays it: a revision backdated to the start of the year, a promotion approved after the fact, an attendance correction accepted late. Each is individually reasonable and each was approved by somebody entitled to approve it. The difficulty is that arrears calculated for one person across several past periods depend on what the structure and the rules were in each of those periods rather than on what they are now, and a system that recalculates using current rules produces a figure that cannot be explained back to the earlier statements. The employee then has two numbers, no way to reconcile them, and a reasonable question.

Control comes from limiting how far back an effective date may go, and from requiring an approval specifically for the backdating rather than only for the change itself, so that somebody is consciously accepting the downstream work. Showing arrears as their own line, identified by the period they relate to, is the other half; where arrears are folded into a single earnings figure the employee has no way to check them and the query reaches [payroll management](/payroll-management) anyway, having taken longer to arrive. Keeping every previously calculated run frozen is what makes any of this reconstructable months later, when the people who made the decisions have moved on and only the records remain.

What makes a published calendar work?

Publication alone changes little. A calendar works when it is issued far enough ahead for the people supplying inputs to plan around it, when it names an owner and a deadline for each input rather than only the cut-off, and when employees can see it too rather than only the payroll team. Putting it where people already look, alongside their own pay records in an [employee self-service portal](/employee-self-service-portal), does more than circulating it once by email, which is read by whoever happened to be at their desk that morning and forgotten by the rest before the first deadline arrives. A calendar nobody can find when they need it is functionally the same as no calendar.

Holding the calendar is harder than writing it. Every exception granted teaches the organisation that the cut-off is negotiable, and the next request arrives sooner and with less justification behind it. The workable position is a firm cut-off plus a defined route for genuine emergencies that requires a named approver, so an exception costs something and is visible to somebody other than the person granting it. Where attendance is the input that habitually arrives late, the remedy usually belongs upstream in [attendance management](/attendance-management-software) rather than in a further extension of the payroll deadline, because a deadline extended once to accommodate a structural problem will be extended again next period for the same reason.