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

# Manual punches and day overrides

> Record a punch on an employee's behalf, override a reconciled day, or apply a status across a date range — all audited.

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="attendance:write" />

Sometimes the record has to be corrected directly rather than through a request — a terminal was down for a shift, someone was on site but their phone was not, a whole team was at an off-site event.

<Warning>
  **Prefer regularization where you can.** A regularization creates a request the employee filed and a manager approved. An override is you changing the record. Both are audited, but only one carries the employee's account of what happened.
</Warning>

Every action on this page is written to the audit log with your identity, the timestamp, and the reason you gave. The reason is **required** — the field is not optional on any of these three actions.

## Record a manual punch

Adds a single punch to an employee's day at a time you specify.

<Steps>
  <Step title="Open the employee's Attendance tab">
    Find them in the directory, open **Attendance**, and navigate to the month.
  </Step>

  <Step title="Add the punch">
    Choose the direction (in or out) and the exact timestamp. Unlike a real punch, you are stating when it happened rather than punching now.
  </Step>

  <Step title="Give a reason">
    Required. "Terminal BIO-MUM-01 offline 06:00–14:00" is a useful reason; "correction" is not — you or a successor will be reading this in an audit.
  </Step>
</Steps>

A manual punch is recorded as source **Web** and is **always approved** — it skips the geofence check and the duplicate guard, because you are asserting a fact rather than claiming one. The day re-reconciles immediately afterwards.

## Override a day

Sets the reconciled outcome of a single day directly, rather than adding a punch and letting the engine derive it.

You can set:

| Field                | Use when                                                                          |
| -------------------- | --------------------------------------------------------------------------------- |
| **Status**           | The derived status is wrong — the day should read `Present` rather than `Absent`. |
| **Worked minutes**   | Hours need correcting without inventing punch times.                              |
| **Overtime minutes** | Overtime needs adjusting outside the request workflow.                            |
| **Frozen**           | The day should stop re-deriving — see below.                                      |

A reason is required.

<Note>
  **Freezing a day** stops later punches or approvals from re-deriving it. Payroll uses this to lock a month at the freeze stage. Setting it by hand is unusual; unset it and the day becomes derivable again.
</Note>

## Apply a status over a range

For the cases that are not one day: a plant shutdown, a team at a conference, a strike.

<Steps>
  <Step title="Pick the employee and the range">
    From and to dates, inclusive. The range is capped at 366 days.
  </Step>

  <Step title="Choose the status">
    The status to apply to every day in the range.
  </Step>

  <Step title="Give a reason">
    Required, and it is stamped on every day the operation touches.
  </Step>
</Steps>

The result tells you how many days were actually updated. Days inside a frozen payroll period are refused rather than silently skipped.

<Tip>
  A single-day override and a one-day range do the same thing. Use the range form when you are correcting a stretch; use the day override when you are adjusting one day's numbers.
</Tip>

## What gets audited

All three actions write an audit entry against the employee, in the **Attendance** category, recording who acted, when, what changed, and the reason. That trail is visible on the employee's **Audit** tab and exportable. See the audit log documentation under Administration.