Skip to content
Timesheet Systems

All notes  /  06 · Operations

When It Goes Wrong Near Payroll

The failures that matter here all have a deadline attached. What to decide in advance so the decision is not made under pressure.

Procedure

An incident in this category is measured against the payroll calendar. Everything about the response follows from how many days remain.

The failures worth planning for

The export fails or produces wrong figures.

A rule was misconfigured and a period was calculated wrongly — discovered before or after payment.

An integration dropped records silently and the gap is found at close.

The system is unavailable during the close window.

A bad import corrupted a period.

Someone was paid wrongly, which is the outcome the others lead to.

Decide in advance

Who declares an incident, and who can authorise an off-cycle payment.

The cut-off after which you stop trying to fix and switch to a correction in the next period.

The manual fallback: how payroll runs if the system cannot produce the file. Every organisation has one and most have not written it down.

Who contacts the vendor, and what counts as severity one in your definitions rather than theirs.

Who tells the affected people, and when. Deciding this in the moment produces silence, which is the worst option.

If people were paid wrongly

Underpayment is urgent and usually has a statutory deadline.

Overpayment recovery has its own rules and is frequently disputed. Do not net it off silently against the next payslip without checking what is permitted.

Tell the people affected before they notice, with what happened, what the correct figure is, and when it will be fixed.

Record it, because a pattern of the same error is a configuration problem rather than a series of accidents.

The correction itself

Correct in the system, not only in payroll, or the record and the payment diverge permanently.

Preserve the original and record the correction with a reason.

Re-run the reconciliation after correcting, because a fix applied to one system and not the other is the most common second failure.

Check whether the same misconfiguration affected other periods, which it usually did.

Afterwards

Why was it not detected sooner? Usually the more valuable question than what broke.

Which check would have caught it, and add it to the close checklist.

Whether the vendor's release notes mentioned anything, if the timing suggests an upgrade.

Write it up briefly and keep it. The same failure recurs, and the second investigation should take an hour rather than a day.

Write down the manual fallback

Every organisation has one; most have not written it down.

How payroll runs if the system cannot produce the file.

Who authorises it, what data source is used, and how the records are reconciled afterwards.

Tested once, during implementation, so it is not being invented at midnight before a deadline.

Including how the fallback entries are marked in the system afterwards, so the audit trail shows what happened rather than appearing normal.

Include the service workflow

An operational incident often crosses ticket and time systems. Review this connected workflow, then define which system owns status and recovery evidence.