How leave works in SquadBear

Types, policies, accrual and how a request's day count actually gets calculated

This is the model behind every leave request — what a "type" and a "policy" are, how days get accrued, and how a request turns into a number of days off a balance.

Why

Leave has to be exactly right, or people stop trusting the number on their dashboard. SquadBear keeps configuration (types, policies, accrual rules) separate from the transaction (a request), so changing next year's carryover cap doesn't rewrite anyone's history. Day counts come from each person's own work schedule and holiday calendar, not a single company-wide assumption — a four-day-week employee and a five-day-week employee booking the "same week" off get charged different numbers of days, correctly.

How the pieces fit together

Leave types are what you're requesting — Vacation, Sick leave, Unpaid leave by default — and define whether it's paid.
Policies attach the rules to a type: days per year, notice period, the booking increment (the smallest slice you can book: full day, half day, 2 hours, or 1 hour), whether a replacement is required, who approves it.
Accrual rules decide how those days land: annual (one grant on 1 January) or monthly (1/12 on the 1st), set per policy at Admin → Policies → [policy] → Accrual schedule.
Balances track accrued, used, reserved and carried-over time, per person, per leave type, per year. They're shown in days with the exact hours in parentheses, so "2.5 days (20h)" reads the same for a full-timer and a part-timer.
Requests draw down the matching balance once approved — or immediately, for auto-approved types like sick leave.

How a request's days are counted

A request isn't just "end date minus start date." Each day in the range is checked against the employee's own work schedule, so a non-working day is excluded the same way a weekend would be, and against their holiday calendar, if the policy excludes holidays. A full day off costs exactly that date's scheduled hours, so a short Friday costs less than a full Monday. On a single-day request you can book a smaller slice (a half day, 2 hours, or 1 hour) when the policy's booking increment allows it; multi-day requests are always whole days. Unused time carries into the next year up to the policy's cap (5 days by default); anything above the cap doesn't carry forward. Part-time employees accrue proportionally to their weekly hours.

Unlimited leave

Some leave types aren't balance-tracked at all. The signal is a policy with an accrual of 0 days a year: no ledger entries, no running balance, nothing to run out of. Sick leave defaults to exactly this — auto-approved, no cap — and the dashboard shows "no limit" instead of a day count. Unpaid leave uses the same 0-accrual mechanism but keeps a per-request cap (1–30 days), so it's unlimited in the sense of "no annual balance," not "book as much as you want in one go."

Worked example: joining mid-year

Aleksandra joins Northlake as a developer on 1 March. Under the default Vacation policy — annual accrual, 26 days a year, prorated by start month — she gets one lump grant the moment she's added to the workspace: 26 × 10/12 = 21.67 days, held to the minute (10,400 minutes) so nothing is lost to rounding, all at once. (A nightly run keeps every balance topped up after that; nobody waits for it to start.)

If Northlake instead set Vacation to monthly accrual, she'd get it in instalments: each month grants 26 / 12 = 2.17 days (1,040 minutes). By the run that includes July (5 months, March–July), she'd have 10.83 days; by December (10 months), 21.67 days. On the minutes substrate the two methods land on the same total, because each month's 1,040-minute grant divides evenly to whole minutes, so there's no per-month rounding drift to accumulate.

A request goes pending → approved (or rejected). Pending and approved requests can be cancelled — a cancellation after approval returns the days to the balance; a rejected request is final.