How a payroll run moves from inputs to a locked result

Teams often talk about "running payroll" as though it were a single action. In practice it is a sequence of decisions made by different people, each depending on the one before. When something goes wrong, the useful question is not only "what is the number?" but "at which stage did this number become what it is?"

This article walks through the stages a payroll run moves through in HRMS, and what a reviewer should be able to inspect at each one.

Before the run: the salary structure

Every run starts from what each employee is meant to be paid. In HRMS that is the salary structure, which can be defined and then revised over time. The review recorded salary revisions, resizing and voiding as implemented, so a structure that changes mid-year can be represented as a change rather than overwritten.

For a reviewer, the important thing is that the structure in force for this period is visible, along with the date any revision took effect.

Stage 1: input review

Inputs are everything specific to this month: approved leave, attendance for the period, one-time adjustments such as arrears or reimbursements, and opening balances where a run continues from an earlier system or period.

Input review is where most avoidable errors are caught. A missing attendance correction or a duplicated adjustment is far easier to fix here than after salaries have been calculated and approved. HRMS lets a payroll maker capture run inputs and adjustments as distinct items, so a reviewer can see what was added to this run rather than only its effect on the total.

A hypothetical example

Imagine a 40-person services firm in Coimbatore. In one month, two employees have approved unpaid leave, one has an arrear from a late revision and one joined on the 12th. At input review, the payroll maker confirms each of these four items before anything is calculated. If the arrear was entered twice, it shows up as two adjustments, not as an unexplained higher figure.

Stage 2: calculation

Calculation applies the salary structure and the applicable rules to the confirmed inputs. Payroll in HRMS uses deterministic calculation and rule paths: the same inputs and the same rule versions should produce the same result. AI features in the product are separate from this step and do not decide salaries.

The rules themselves are versioned and effective-dated, which matters when a rule changes partway through a year. You can inspect which rule version applied to the run. The article on effective-dated payroll rules explains why that matters.

Stage 3: approval

Approval is where a second person, often from finance, reviews the calculated run before it is accepted. A useful approval is not just a signature. The approver should be able to see the inputs, the adjustments and the rule versions behind any figure that looks unusual, and compare it with the previous run.

Keeping approval as a distinct stage also makes the review trail clearer later: it records who accepted the run and when, separately from who prepared it.

Stage 4: locking

Locking fixes the approved run as the reference for that period. Once locked, the run is the version that later questions, including an employee's "why has my salary changed?", should be answered against.

Corrections still happen. The payroll review capability includes inspecting effective rule versions and corrections. In a walkthrough, ask specifically how a correction after locking is recorded and how it appears next to the original run.

What locking does not mean

Locking a run in HRMS does not pay anyone. No verified bank-disbursement or statutory-filing connection was established in the review. Salary transfers and returns remain separate processes, and approving or locking a run should not be assumed to trigger them.

Why stages matter more than speed

It is tempting to judge payroll software by how quickly it produces a number. Stages trade a little speed for something more valuable: each decision happens at a known point, by a known person, with the evidence available at that point. When a figure is questioned later, you can work back through the stages instead of starting from the final total.

That is the difference worth evaluating. A run that moves through input review, calculation, approval and locking, with the rules and adjustments visible at each step, gives your team a trail to follow. A run that only produces an output gives you a number to defend.

What to ask to see

• One run moving through all four stages, using sample employees.
• An adjustment added at input review and its effect after calculation.
• The rule version applied to the run, and where its effective date is shown.
• What the approver sees before approving.
• How a correction after locking is recorded.

The how it works page shows where payroll sits in the wider journey, and the FAQs answer common questions about live payroll readiness.

The takeaway

A payroll run is a chain of reviewable decisions. If you can see each link, from structure to inputs to rules to approval to lock, you can explain the result. Bring one month's process, described with anonymised details, to a walkthrough and follow it through the stages.