> ## 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. # Frequently asked questions > The questions OnTime's actual behaviour raises most often, and the real answers. ## Attendance You punched **outside your work location's geofence**. OnTime records the punch and marks it pending, because an out-of-zone punch needs a human to confirm it was legitimate. It goes to your direct manager along with the reason you picked. The punch is not lost and you do not need to punch again. See [Punching](/help/attendance/punching). Most likely the day has not been **closed** yet. A day is finalized after it is over, not at the moment of the last punch — so yesterday's final status lands the following morning. `Absent` in particular is never written to a day still in progress: someone who has not punched *yet* is not a no-show. See [The attendance day lifecycle](/help/concepts/attendance-day-lifecycle). Almost certainly your terminal user ID has not been **mapped** to your OnTime employee record. Punches from an unmapped terminal user are **parked**, never dropped — they sit waiting. When an administrator creates the mapping, the parked punches are replayed automatically and your days fill in. Ask them to check the unmapped queue. You pressed the same direction twice within a minute. It is a double-tap guard. Check whether your first press registered — it almost certainly did. The live board shows **today**, which is provisional. The day report shows closed days, which are final. They are measuring different things and both are right. ## Approvals Because the second pair of eyes is the point. The same-actor rule applies at every stage and to every request type, regardless of how senior you are. Rejection is different — anyone in scope can reject at any stage. A denial does not need the protection a grant does. Permission and **scope** are two separate checks. `leave:approve` lets you approve leave; it does not say whose. You must also be the requester's **direct manager**, or hold `hr:approve` for organization-wide reach. Somebody two levels below you is not in your scope. See [Roles & permissions](/help/concepts/roles-and-permissions). If someone else decided it a moment before you, you are told it is no longer pending. If the request would rewrite a day inside a **frozen payroll month**, the whole decision is refused and rolled back — the request stays pending. That is deliberate: payroll has locked that month. For **leave**, because that leave type is configured to require it. For a **regularization**, because it is a whole-day manual entry — the one correction with no underlying punch to check against. The HR step needs the `hr:approve` permission and cannot be performed by whoever approved at the manager step. ## Leave and pay Monthly **accrual**. Leave types set to accrue monthly credit their rate on each run, and OnTime checks for due accruals once a day automatically. At the financial-year boundary you may also see **carry-forward** — up to the type's cap — and anything above the cap lapsing. Because it counts **working days**. Weekly offs and dates on the organization's holiday calendar are excluded. The quote shown before you submit breaks this down explicitly. A payslip is created when the payroll cycle is **disbursed**. Until then the numbers exist only inside the cycle and are not visible to employees. Ask whoever runs payroll where the cycle is. Read the **attendance** section of the payslip first — paid days, loss-of-pay days, overtime. Pay is derived from attendance, so a surprising net almost always traces to a day that reconciled differently from what you expected. A missing holiday on the organization calendar is the classic cause: it makes a holiday read as `Absent`, and `Absent` is loss of pay. ## Configuration Because it is in use. * A **leave type** with any balance or request against it cannot be deleted. * A **role** with employees assigned cannot be deleted. * A **location or department** with employees assigned cannot be deleted. * The **four role presets** can never be deleted or edited. Reassign first. To retire a leave type that is in use, set its quota to zero instead. It is still a **draft**. Publish it — a draft template is invisible to the roster. Check you published rather than just assigning. Cells are drafts until the **week** is published, and publishing is a separate permission (`roster:publish`) from editing. Expected. The brand colour is stored but **not yet applied** to the interface — nothing reads the value. The panel says so. Also expected. Integrations today are a **configuration registry**: connecting stores what you typed and marks the provider connected. It performs no authentication and moves no data. See [Integrations](/help/admin/integrations). For real data movement, use the public API or webhooks. ## Notifications and access Because OnTime does not send any. **Every notification is in-app only** — no email, SMS, WhatsApp or push, for any event including payslip publication and Form 16 availability. The bell is where you find out. For machine delivery to your own systems, use webhooks. Role changes take effect immediately for permission checks, but **the person stays signed in**. If the change is urgent, revoke their sessions too — see [Sessions and devices](/help/admin/sessions-and-devices). If they were created through **CSV import**, they have a randomly generated password that was never displayed. Set a real password on their record and share it. OnTime sends no welcome or invite email to employees. The status flips to `Failing` on the first failed attempt; the notification only fires once an event has exhausted all eight retries, roughly 22 hours later. Watch the badge rather than waiting for the alarm. See [API keys and webhooks](/help/admin/api-settings).