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

# Regularization

> The attendance correction workflow: what it is, how to file one, and how the Manager to HR chain decides it.

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>;

A **regularization** is a request to correct an attendance record. It exists so that employees can fix a wrong day without being able to *edit* a wrong day — the change is claimed by one person and approved by another, and both are recorded.

## The five kinds

| Type                  | Filed when                                          | Needs HR? |
| --------------------- | --------------------------------------------------- | --------- |
| **Missing punch in**  | You worked but the clock-in never registered.       | No        |
| **Missing punch out** | You forgot to punch out, or the terminal missed it. | No        |
| **Off zone**          | You punched outside the geofence legitimately.      | No        |
| **Wrong location**    | The punch registered against the wrong site.        | No        |
| **Manual entry**      | A whole day with no punches at all needs entering.  | **Yes**   |

<Note>
  **Only a whole-day manual entry needs HR.** The other four finish at the manager. This is deliberate: claiming an entire day from nothing is the one correction with no underlying punch to check against, so it gets a second pair of eyes.
</Note>

## Filing one

### As an employee

<Steps>
  <Step title="Find the day">
    Open **History** in the employee app and go to the date. If the day looks wrong, the **Request regularization** action is there.
  </Step>

  <Step title="Say what should have happened">
    Choose the type, state the correction you are asking for — the time you actually arrived, the punch that is missing — and explain why.
  </Step>

  <Step title="Submit">
    It goes to your direct manager. You can follow its status and talk to the approver in the request's discussion thread.
  </Step>
</Steps>

### On someone's behalf

<PermissionNote perm="regularization:approve" />

Administrators and managers can file for an employee from the regularizations inbox (**Mark on behalf**). Pick the employee, the type, the date, the change and the reason. You can only do this for employees in your scope.

## The approval chain

```mermaid theme={null}
stateDiagram-v2
  direction LR
  [*] --> AwaitingManager
  AwaitingManager --> Approved: manager approves<br/>(most types)
  AwaitingManager --> AwaitingHR: manager approves<br/>(manual entry)
  AwaitingHR --> Approved: HR approves
  AwaitingManager --> Rejected
  AwaitingHR --> Rejected
```

<PermissionNote perm="regularization:approve" />

The HR step needs the `hr:approve` permission, and it cannot be the same person who approved at the manager step. Nobody can approve their own request. See [How approvals work](/help/concepts/approvals) for the shared rules.

## Deciding one

The detail page is built for deciding without leaving it.

<AccordionGroup>
  <Accordion title="The punch trail" icon="list-ordered">
    Every real punch on the day, in order, with the proposed change shown alongside — so you can see what is being claimed against what actually registered.
  </Accordion>

  <Accordion title="Evidence" icon="image">
    The selfie from any punch that carried one, rendered inline. Coordinates and accuracy from any punch with GPS. Documents the employee uploaded on that date.

    <Note>
      The location tile shows coordinates and accuracy, not a rendered map.
    </Note>
  </Accordion>

  <Accordion title="Pattern check" icon="repeat">
    How many regularizations this employee has filed in the last 90 days, and the hours actually logged on the day in question. Occasional corrections are normal; a pattern is worth a conversation.
  </Accordion>

  <Accordion title="Discussion" icon="message-square">
    A thread between the employee, the manager and HR. Ask before rejecting — most regularizations are a genuine misunderstanding about what the record shows.
  </Accordion>
</AccordionGroup>

Approving or rejecting takes an optional note, which the employee sees along with the notification.

## What approval does

Approving **rewrites the day**, inside the same transaction as the approval itself. There is no window where the request reads approved but the day still shows the old value.

<Warning>
  If the day belongs to a frozen payroll month, approval is **refused** and the whole decision rolls back. Clear the queue before freezing a cycle.
</Warning>

## The inbox

<PermissionNote perm="regularization:approve" />

**Attendance → Regularizations** is the organization-wide queue. It carries:

* **Status filters** — pending at manager, pending at HR, approved, rejected.
* **KPIs** — how many are pending, the average time to resolve, and how many have aged past 48 hours.
* **Bulk approve** — select several pending rows and advance them one step each. The result reports which were approved and which were skipped, and why.
* **Export** — CSV of the current view, honouring the status filter.

<Note>
  The queue is scoped like every other approval surface: a manager sees their direct reports' requests, an `hr:approve` holder sees the organization. Every row you can see is one you can open.
</Note>

## Aged requests

A regularization sitting for more than 48 hours is surfaced both in the inbox KPIs and on the admin dashboard's alert feed. There is no automatic escalation or auto-approval — the alert exists so a person notices.