> ## 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.

# Line-level overrides

> Correct a single component amount for one employee in one cycle, without changing the component definition.

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" />

An **override** replaces the computed amount of one component, for one employee, in one cycle. It is the escape hatch for the one-off: a signing bonus, an agreed deduction, a correction that does not justify changing anything structural.

Overrides live on the run review screen, in the **Inputs & overrides** card.

## What an override is keyed on

Three things together: the **cycle**, the **employee**, and the **component code**. Setting an override for the same three replaces the previous one rather than adding a second.

| Field              | Notes                                                                                    |
| ------------------ | ---------------------------------------------------------------------------------------- |
| **Employee**       | Must be in your organization.                                                            |
| **Component code** | Must be an existing salary component.                                                    |
| **Amount**         | A whole-rupee integer. This is the final amount for that line — not an adjustment to it. |
| **Note**           | Up to 120 characters. Write one; you will want it at audit time.                         |

## Adding one

<Steps>
  <Step title="Open the cycle's review">
    Payroll → Cycles → the cycle → Review.
  </Step>

  <Step title="Add override">
    Pick the employee and the component, enter the amount, and write the note.
  </Step>

  <Step title="Recalculate">
    <Warning>
      **Overrides do not trigger a recalculation.** If the cycle has already calculated, the review screen shows a warning that overrides are pending. Re-run **Calculate** for them to appear in the numbers.
    </Warning>
  </Step>
</Steps>

## When they are allowed

Overrides can be added, changed and removed at any point while the cycle is **in progress** — that is, up to and including approval.

Once the cycle is **disbursed**, the cycle is locked and every override operation is refused.

<Note>
  The natural place for overrides is the **Inputs** stage, before you mark inputs complete. That is what the stage exists for. Adding one after calculating is permitted, but it means recalculating and re-approving.
</Note>

## How overrides survive a recalculation

Overrides are stored **separately** from the run lines. Calculating deletes and rebuilds every run line; the overrides are untouched and are re-applied on the way through.

This is what makes it safe to recalculate repeatedly during a difficult close — you are not re-entering the same corrections each time.

## Overrides win

An override applies **even where the ordinary computation would have skipped the line**. Two cases where that matters:

* **Zero paid days.** A fixed component is normally skipped for an employee with no paid days in the month. An override on that component still pays.
* **Wage ceiling.** A component with a wage ceiling is normally skipped for employees above it. An override still applies.

<Warning>
  That is the point of an override, and it is also the risk. An override is an assertion that bypasses the model's own reasons for not paying something. Use the note field.
</Warning>

## Removing one

Delete it from the same card, then recalculate. Removal is refused once the cycle is disbursed.

Every add, change and removal is written to the audit log under the Payroll category.