PTO Accrual Explained: Grants, Proration & Carryover

"How many days do I have left?" is the most-asked question in any HR system, and trust in the whole tool rides on the answer. Leave balances have a property most HR data doesn't: everyone checks their own, and everyone can count. If the dashboard is ever wrong, even by half a day, people go back to asking a human. So it's worth knowing exactly where that number comes from, because the mechanics are less obvious than they look.

Four words that do all the work

• Entitlement is what the policy promises: "26 days of vacation a year."
• Accrual is the schedule on which that promise turns into usable days.
• Balance is what you can actually book right now: accrued, minus used, minus anything reserved by pending requests.
• Carryover is the unused days that survive into next year, usually up to a cap.

Most PTO confusion is two of these getting mixed up, usually entitlement and balance: "I get 26 days" and "I have 26 days available today" are different claims.

Annual or monthly?

There are two honest ways to turn an entitlement into days, and both are defensible.

Annual accrual grants the whole year's entitlement at once, on 1 January. It's simple to explain and generous in spirit: you can book a summer holiday in February without saving up for it. The trade-off is exposure. Someone can use all 26 days by June and resign in July, having taken leave they never earned in elapsed-time terms.

Monthly accrual grants 1/12 of the entitlement on the 1st of each month, so everyone's balance matches the fraction of the year they've worked. It's the natural choice where local practice or payroll expects earned-to-date numbers. The trade-off is friction: new hires start near zero and build up slowly.

In SquadBear you pick this per leave type, under Admin → Policies.

Rounding, or why 21.5 and 20.0 are both right

Meet Aleksandra. Her policy grants 26 days a year, and she joins on 1 March, with ten months of the year left.

• Annual method: one prorated grant of 26 × 10/12 = 21.67, rounded to the nearest half-day. She gets 21.5 days, available immediately.
• Monthly method: each month grants 26 / 12 = 2.17, rounded to the nearest half-day, so 2.0 days per month. After December's grant (her tenth), she has 20.0 days.

Same policy, same person, same year: 21.5 versus 20.0, and neither is a bug. The annual method rounds once for the whole year; the monthly method rounds every month, and twelve small roundings drift from one big one. Any system that rounds to half-days behaves this way (balances should be numbers people can actually book). What matters is that the method is consistent, and that whoever fields the "why is my balance 20 and not 21.5?" ticket can walk through the arithmetic above.

Proration for joiners and part-timers

Mid-year joiners prorate by remaining months, exactly as Aleksandra's numbers show. Leavers are the same logic run backwards, plus whatever local law says about paying out untaken days (jurisdiction-specific; ask your advisor).

Part-timers prorate by FTE, and the definition matters more than it seems: FTE should be a fraction of standard working days, not hours. Three full days a week is 0.6 FTE and accrues 60% of the entitlement. Five short days is still 1.0, because that person works every weekday, so a day off costs them exactly one day and they need the full count. When accrual and spending use the same unit, the balance feels fair.

The mid-year schedule change

Now the genuinely hard case: someone drops from full-time to a four-day week in September, and their balance was granted under the old FTE. The right fix is to recompute the year month by month against the schedule actually in force (full FTE January through August, 0.8 after) and post the difference as a visible correction in the ledger. Never a silent rewrite, and never clawing back days already taken or approved. In SquadBear the correction posts automatically the moment the new schedule is saved, and you can watch it happen:

"Set Aleksandra's work schedule to Monday-Thursday, FTE 0.8, effective 1 September, and tell me what correction it posts to her Vacation balance."

Carryover, where December gets political

Unused days usually carry into the next year up to a cap (5 days is SquadBear's default), and anything above it expires. The cap exists because accrued-but-untaken leave is a real liability: it's time the company owes. A gentle use-it-or-lose-it rule also nudges people to actually rest.

Two cautions. Several jurisdictions restrict how and when statutory leave can expire, so check yours before setting an aggressive cap. And if half the company is scrambling to burn days in Q4, the cap isn't your problem; the booking culture is.

Sick leave doesn't need a balance

When staying home ill spends a scarce balance, people ration it and come to work sick, and your absence data ends up recording who could afford to be ill. The cleaner model is sick leave with no balance at all: unlimited, auto-approved, tracked for patterns rather than budgeted. That's SquadBear's default. A policy with an accrual of 0 days a year is the "unlimited" signal: no ledger, nothing to run out of, and the dashboard shows "no limit" instead of a number. Unpaid leave uses the same mechanism but keeps a per-request cap of 1–30 days.

Worried about abuse? Read patterns instead of rationing. That's what the Bradford factor is for.

What a week off actually costs

A request isn't end date minus start date. Each day in the range is checked against that person's own work schedule, so a four-day-week employee booking Monday to Friday is charged 4 days (Friday was never a working day for them), and against their holiday calendar, so a public holiday inside the range isn't billed. SquadBear checks each date against the schedule in force on that date, which keeps the charge right even across a mid-request schedule change.

Try the arithmetic yourself

Everything above is how SquadBear's leave engine behaves out of the box: accrual chosen per leave type at Admin → Policies, half-day rounding exactly as in Aleksandra's numbers, FTE corrections posted as visible ledger entries, a 5-day carryover cap, unlimited sick leave. Configuration lives apart from history, so changing next year's cap never rewrites anyone's past. And balances are self-serve on the dashboard, or one question away:

"Show me my leave balances and explain how many of my unused days will carry into next year."

Start free with sane default policies, or ask the demo to walk a mid-year joiner through their accrual on sample data.

Related: the Bradford factor, on reading absence patterns once you stop rationing sick days.