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

# Approving leave

> The leave queue, deciding with context, and what changes the moment you approve.

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="leave:approve" />

## Where the queue is

<CardGroup cols={2}>
  <Card title="Manager app → Approvals" icon="smartphone">
    Your direct reports' requests, filtered by the Leave pill, alongside regularizations and overtime.
  </Card>

  <Card title="Admin console → Leave requests" icon="monitor">
    The organization-wide queue, with filters by status and an export.
  </Card>
</CardGroup>

Both are scoped the same way. A manager sees their direct reports. A holder of `hr:approve` sees the whole organization. Every row you can see is one you can open and act on.

## Deciding with context

The detail view is built so you can decide without going anywhere else.

<AccordionGroup>
  <Accordion title="The request" icon="file-text">
    Leave type, dates, duration, how many working days it consumes, and the employee's reason.
  </Accordion>

  <Accordion title="Balance after" icon="wallet">
    What the employee would be left with. A request that exceeds the balance is flagged — approving it anyway is a decision to let the excess fall to Loss of Pay.
  </Accordion>

  <Accordion title="Team load" icon="users">
    How many other people are already on approved leave for each day in the range, at team, department and organization level, with a peak label. This is the coverage question.
  </Accordion>

  <Accordion title="Backup" icon="user-check">
    The colleague the employee nominated, and suggested alternatives who are not themselves on leave.
  </Accordion>

  <Accordion title="Prior pattern" icon="history">
    How much of this leave type the employee has taken this quarter.
  </Accordion>

  <Accordion title="The approval chain" icon="git-branch">
    Which stage the request is at, and whether an HR step follows yours.
  </Accordion>
</AccordionGroup>

## Approving or rejecting

Both take an optional note, which the employee sees with their notification. A rejection without a note is a rejection the employee will ask you about anyway — write one.

<Note>
  If the leave type requires HR approval, your approval moves the request to the HR stage rather than finishing it. The employee's leave is not confirmed until HR decides, and the request says so.
</Note>

### Restrictions

* **You cannot approve your own request.** Refused, however senior you are.
* **The HR step needs `hr:approve`.** A manager without it is told they lack the permission, not that something went wrong.
* **The HR step cannot be the manager who already approved.** Someone holding both roles has to hand the second step to a colleague.
* **Rejection has no same-actor restriction.** Anyone in scope with the right key can reject at any stage — a denial does not need a second pair of eyes the way a grant does.

See [How approvals work](/help/concepts/approvals) for the full model.

## What approval changes

The moment the final approval lands, in one transaction:

1. The request becomes `Approved`.
2. The employee's **balance is debited** for the working days consumed.
3. The **day records** for the covered dates are set to `Leave` — or `Half` for a half-day.

Then the employee is notified and an audit entry is written.

<Warning>
  If two approvers act at the same moment, exactly one wins. The other is told the request is no longer pending. This is what makes it impossible to debit a balance twice for one request.
</Warning>

## Where approved leave shows up

* The employee's **history calendar**, as `Leave` or `Half` on each covered date.
* The organization **month calendar** and day reports.
* The **payroll cycle**, in that employee's paid-days count — a paid leave type does not reduce pay, an unpaid one does.
* **Team load** on every subsequent approval decision for those dates.

## Rejecting after approval

There is no un-approve. A leave request that has been approved and needs reversing is handled by an administrator correcting the affected days directly — see [Manual punches and day overrides](/help/attendance/manual-punches-and-overrides) — and adjusting the balance. Both actions are audited.