Understanding Accruals, Carryover, and Balance Resets

Purpose

This is the concept guide behind PTO balances: how time accrues, when it posts, what the two caps do, what happens at reset, where carried-over and forfeited time goes, and why a balance sometimes is not what an employee expects. Read it before designing policies, and again when someone asks "why is my balance X?".

Who needs this: Anyone who designs time off policies or investigates balances. Typically the Employer Administrator and HR admins; Reporting Managers who field balance questions from their team will also find the "Common problems" section useful.

How accrual works

• Each policy has one or more accrual schedules (see Adding and Managing Time Off Policies). On each schedule date the system adds the accrual amount to the employee's balance and records an Accrual entry in their Time Off History. Monthly, Semi-Monthly, Quarterly and Yearly schedules post on the day of the month you chose. Weekly and Bi-Weekly schedules post on the weekday you chose. Work Anniversary posts on the employee's hire-date anniversary.
• Accruals post once a day, not at midnight. A daily job runs for each policy (by default at 8:00 AM, server time) and credits every accrual date that has fallen due since its last run. An employee who checks at 7:00 AM on their accrual day will not see the entry yet. If a run is missed, the next run catches up all the dates in between; nothing is lost.
• Only active assignments accrue. A policy that is Incomplete (no employees yet) or Expired never accrues. An employee whose assignment was de-activated, or who has been terminated, stops accruing on that policy.
• Hours-worked accrual (Flat Amount on Hours Worked, UZIO Payroll required) does not use the daily job. It accrues when a payroll is approved: paid hours ÷ the schedule's "hours worked" figure × the Accrual Amount. Example: 1 hour for every 30 hours worked; a paycheck with 80 paid hours accrues 80 ÷ 30 × 1 = 2.67 hours. Regular Wage, Overtime, Double Overtime and Holiday Premium hours count as worked by default.
• New-hire waiting periods delay when accrual starts (for example N days from hire, or the first accrual date after hire). A separate usage waiting period can delay when accrued time may be used. An employee requesting too early sees "Time off request dates should be on or after MM/DD/YYYY as per the policy setup."
• Which "hire date" counts. If an employee has an Adjusted Service Date (employee profile, Job tab; used for rehires and status changes that should credit prior service), all time-off calculations use it in place of the Date of Hire: accrual start, waiting periods, work anniversaries, and tenure tiers.
• Proration. With proration on, an employee who becomes eligible part-way through an accrual period receives a first accrual scaled to the part of the period they were eligible for. With proration off, accrual starts at the next full period. Proration applies only to the calendar-cadence methods (Weekly through Yearly). Work Anniversary, At the end of Waiting Period and Flat Amount on Hours Worked are never prorated.
• Tenure tiers. When an employee crosses into a higher accrual level (for example after 2 years), future accruals use the new tier. Past accruals are not recalculated.

The two caps, and why they differ

A manual adjustment counts toward the maximum accrual only when it is saved with Include in Accrual Balance: Yes (Adjusting Employee PTO Balances).

[Diagram: accrual → balance → reset → carryover vs forfeiture flow, showing where "loss on reset" occurs]

How a request is deducted

• On a Days policy, each day of time off deducts 1 day.
• On an Hours policy, each full day deducts the employee's daily hours: the Standard Daily Working Hours on the policy (default 8), or the hours on the employee's work schedule if one is assigned. Employees on an Hours policy can request part of a day.
• Days that are not work days deduct nothing. The policy's Days of the work week define this, and an assigned work schedule overrides it for that employee.
• Company holidays the employee is eligible for deduct nothing, even when they fall inside the request. A request from Monday to Friday over a Thursday holiday deducts four days, not five.
• Approved time off is reserved immediately as Scheduled (see below). It is paid through payroll only when the policy is linked to a Vacation, Sick or Unpaid Time Off earning (details).

What happens at reset

Each policy resets balances on one of:

• the calendar year (January 1),
• the employee's work anniversary,
• a specific day of the year you choose, or
• the First Usage Anniversary, a per-employee rolling cycle (details below) rather than a fixed date.

At reset, the carryover rule is applied:

Example: an employee ends the year with 12 days on a policy that carries over up to 10. On reset, 10 days carry forward and 2 are forfeited. Their Time Off History shows one Carry Over Loss row with the balance before (12) and after (10). With no carryover the row would read 12 before, 0 after.

Three details about the reset that explain most "the numbers look odd" questions:

• When the reset job runs. Calendar-year resets are processed late in the evening of December 31, so January 1 opens on the new balance. Specific-day resets are processed shortly after midnight on that day. Work-anniversary resets are checked daily late in the evening and are applied on the eve of each employee's anniversary. All of these are server time.
• The reset is computed as of the reset date. If an accrual or an approved request is recorded after the reset date but before the job processes that employee, UZIO applies the carryover rule to the balance as it stood on the reset date and then re-applies those later transactions on top. The Carry Over Loss row therefore reflects the reset date, not the processing time.
• One row, not two. For the three fixed-date strategies, the reset is a single Carry Over Loss entry showing the net effect of the carryover rule. There is no separate "carried forward" line.

The First Usage Anniversary cycle

The fourth reset option works per employee, not per date. Nothing happens until the employee's first approved request. Its leave date anchors a 52-week cycle. When the anchor plus 52 weeks passes, the remaining balance is forfeited and the balance is set fresh to the policy's Accrual Amount. The next cycle waits for the next approved request. This is checked daily, shortly after midnight. Two things make its audit trail look different:

• The cycle close writes two history rows, not one net entry: a Carry Over Loss row (balance to 0, the forfeiture) and an Accrual row (0 to the fresh grant).
• If the anchoring request is later cancelled or denied, the cycle re-anchors on the earliest remaining approved request (or fully un-anchors if none remain), so the "year" can legitimately move.

Carryover is always No on these policies (the system rejects anything else at save). They are designed for rolling-year statutory leaves; the auto-created NY State Prenatal Leave DSP policy runs on this cycle. See Adding and Managing Time Off Policies for the save-time constraints.

Other balance mechanics worth knowing

• Three numbers, not one. Each policy card on the employee's profile shows Current Balance (the balance accrued to date), Scheduled (hours committed to approved requests not yet taken, plus requests still awaiting approval), and Available Balance (Current minus Scheduled). "Why is my balance lower than my accruals?" is usually the Scheduled amount at work.
• Negative balances. Whether a balance may go negative is a per-policy setting, Is there a negative PTO balance allowed? (Yes/No). Set to No, employees requesting past their available balance are blocked with "You cannot request leaves more than your available balance." Set to Yes, watch for persistent negatives; they usually signal a policy misfit.
• Termination. When an employee is terminated, UZIO cancels their outstanding requests, sets all of their policy assignments to inactive so accrual stops, and, for policies with Balance Payout on Termination? = Yes, pays the remaining balance through the PTO Balance Payout earning on the final paycheck. The balance is written to zero with a Final Payout adjustment when that payroll is approved. Details: Automatic PTO Balance Payout on Employee Termination.
• Rehire. Rehiring reactivates the employee's policy assignments and cancels any leave still dated after the rehire date. Whether the pre-termination balance is kept or restarted at zero depends on your company's configuration; check the employee's Time Off History after the rehire before their first new accrual.
• Voided payrolls. PTO accrued through a voided payroll is automatically reversed. See Automatic PTO Accrual Reversal on Voided Payrolls.
• Pay stubs. For policies with Display balance on employee paystubs? = Yes, the pay stub carries a Paid Time Off Details section listing the policy, the amount accrued in that pay period, and the balance. Policies set to No are omitted.
• Every change is audited. Accruals, requests, approvals, cancellations, carryovers, adjustments, and payouts each create a Time Off History entry (columns Time Off Type / Status / Approved By / Change / Submitted). Automatic accruals appear with Approved By: Administrator; approved requests show the approver's name and a negative Change; the reset entry is labelled Carry Over Loss.

Common problems

Why is an employee's balance "wrong"?

Read their Time Off History top to bottom before touching anything. Every accrual, request, carryover, adjustment, and payout is a row there. The usual explanations, in order of likelihood:

1. Scheduled time is reserved immediately. Approved requests move hours into Scheduled, dropping Available even though nothing has been taken yet.
2. The accrual has not processed yet. Accruals post during the daily run, not at midnight. Check again later in the day.
3. A cap applied. The maximum balance stopped the credit, or the maximum accrual for the cycle was already reached (see the two caps above).
4. A reset happened. Look for a Carry Over Loss row; the carryover cap forfeits the excess.
5. A manual adjustment or import. Adjustment rows (and opening-balance imports, which override balances) show exactly who changed what and when.

Why did an employee's balance drop on January 1 (or their anniversary)?

That is the policy reset applying the carryover rule. The Carry Over Loss history row shows the before and after. If the forfeiture surprises people every year, schedule the Balance Report before reset dates as an early warning.

Why hasn't a new hire accrued anything yet?

Check, in order: the accrual waiting period (accrual has not started), proration = No (they wait for the next full period), the accrual method's cadence (a Yearly policy accrues once a year), and whether the daily run has happened yet today. If they can see a balance but cannot request against it, that is the separate usage waiting period. The request error names the first allowed date.

Why can't an employee take the time they can see?

Two different gates produce this complaint. "You cannot request leaves more than your available balance." means Scheduled requests have consumed the Available balance (or the amount requested simply exceeds it) on a no-negative-balance policy. "Time off request dates should be on or after MM/DD/YYYY as per the policy setup." means the usage waiting period or policy effective date has not been reached.

Why was less deducted than the days requested?

Non-work days and eligible company holidays inside the range deduct nothing. Check the policy's Days of the work week, the employee's work schedule, and the holiday calendar for the dates in question.

Related articles

• Adding and Managing Time Off Policies
• Adjusting Employee PTO Balances
• Accessing Time Off Reports
• Automatic PTO Balance Payout on Employee Termination
• Employee-facing version of this guide: Understanding Your PTO Balance and Accruals