> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ontime.hosai.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Running a payroll cycle

> The month-end runbook: freeze, inputs, calculate, review, approve, disburse — and what to check between each.

export const PermissionNote = ({perm}) => <Info>
    Requires the <code>{perm}</code> permission. Ask your administrator if an
    action described here is missing from your screen — see
    [Roles & permissions](/help/concepts/roles-and-permissions).
  </Info>;

<PermissionNote perm="payroll:write" />

This is the whole run, in order. Each stage refuses to start until the one before it is done, so the sequence below is not a suggestion.

**Payroll → Cycles.**

## Before you start

<Steps>
  <Step title="Clear the approval queues">
    Regularizations and overtime for the month. After the freeze, approving one of these is refused and the approver gets a wall rather than an explanation.
  </Step>

  <Step title="Check the holiday calendar">
    A missing holiday reads as `Absent`, and `Absent` is loss of pay. This is the single most expensive configuration mistake.
  </Step>

  <Step title="Check compensation is set on everyone">
    An employee with no salary structure calculates to nothing.
  </Step>
</Steps>

## The run

<Steps>
  <Step title="Start the cycle">
    Create the cycle for the period. It opens `InProgress` with a lock-by date at the end of the month.
  </Step>

  <Step title="Freeze attendance">
    Marks every day record in the month frozen. From here, punches, day overrides and attendance-affecting approvals for those dates are refused.

    <Tip>
      This is the moment to stop chasing corrections. Anything not settled now needs a deliberate, audited override to change.
    </Tip>
  </Step>

  <Step title="Add any input overrides, then mark inputs complete">
    The window for line-level corrections — a one-off bonus, a deduction agreed outside the component model. See [Overrides](/help/payroll/overrides).

    Marking inputs complete closes the window and unlocks Calculate.
  </Step>

  <Step title="Calculate">
    The engine runs over every employee: earnings by component, deductions, overtime priced from each day's shift multipliers, loss of pay from absent days, and net.

    It produces the **run lines** — one per employee — and stamps the cycle's totals: headcount, gross, deductions, net, loss-of-pay cases and impact, overtime hours and payout, and the anomaly count.
  </Step>

  <Step title="Review">
    Read the review screen properly. This is the only stage where a wrong number is cheap to fix. See the next section.
  </Step>

  <Step title="Approve">
    Sign-off on the calculated numbers.

    <Warning>
      Approval is bound to the exact calculation it approved. If anybody recalculates afterwards, the approval is cleared and has to be given again — deliberately, so that nobody can pay out numbers that were never approved.
    </Warning>
  </Step>

  <Step title="Disburse">
    Materializes a `Payslip` for every run line and closes the cycle. Employees see their payslip in the Pay tab immediately, and are notified — if payslip notifications are enabled in your organization's notification preferences.

    There is no separate publish step, and there is no un-disburse.
  </Step>
</Steps>

## Reading the review screen

The review lists every employee with paid days, loss-of-pay days, overtime, gross, deductions, net — and **flags**.

| Flag            | Raised when                                                 |
| --------------- | ----------------------------------------------------------- |
| `HighLOP`       | 2 or more loss-of-pay days.                                 |
| `LOPExceeded`   | More than 3 loss-of-pay days.                               |
| `HighOT`        | More than 15 overtime hours.                                |
| `GrossVariance` | Gross differs from last month by more than 20%, either way. |
| `Probation`     | The employee is on probation.                               |

<Note>
  These are **fixed heuristic thresholds**, not a configurable rules engine. They exist to direct your attention, not to make decisions.
</Note>

### What flags usually mean

* **`HighLOP` across a whole location** is almost never absenteeism. Check the geofence and the terminals for that site before you dock anyone.
* **`HighOT` clustered on a few people** is worth checking against the roster — it often means a shift template's eligibility threshold is set too low.
* **`GrossVariance`** on a new joiner or leaver is expected. On a long-standing employee it means a compensation revision or a component change you should be able to name.

## If something is wrong

Fix the cause and **recalculate**. Recalculating rebuilds every line from current data and clears the approval.

* A wrong day → lift the freeze on that day with an override, correct it, re-freeze, recalculate.
* A wrong component definition → fix the component, recalculate.
* A one-off adjustment → add a line override, then recalculate.

<Warning>
  Adding an override does not recalculate by itself. The review screen warns you when overrides exist on an already-calculated cycle. Re-run Calculate.
</Warning>

## After disbursement

Compliance filings for the month are generated from the disbursed cycle. See the Compliance section.