PTO Carry-Over Best Practices: A Year-End Playbook

What are the best practices for PTO carry-over?

A well-run carry-over policy rests on five practices. First, a written rule that states exactly how many days roll and when carried days expire; the most common healthy pattern is a cap of around five days with a use-by date at the end of the first quarter. Second, a compliant fallback where forfeiture is banned: in states that treat accrued PTO as earned wages, an accrual cap replaces use-it-or-lose-it. Third, proactive communication: each employee learns their remaining balance and the exact expiry date in early Q4, while there is still calendar room to use the days. Fourth, system-enforced mechanics, meaning the rollover, the cap, and the expiry run automatically instead of through a January spreadsheet. Fifth, measurement: track how many days expire unused and how requests cluster in December; both numbers tell you whether the cap and the deadline are set correctly. The rest of this playbook walks through each practice with the timeline to run it.

Pick a rule people can say out loud

The strongest predictor of a quiet year-end is a carry-over rule an employee can repeat from memory. "Up to five days roll over and must be used by March 31" survives retelling; a rule with three exceptions and a pro-rata formula does not, and every retelling error becomes a support ticket or a dispute.

The four structural options (full carry-over, capped carry-over, use-it-or-lose-it, accrual cap) and where each is legal are covered in the mechanics explainer linked below. As a playbook matter, capped carry-over with a Q1 use-by date is the pattern to start from: it bounds the balance-sheet liability, gives people a real window to use carried days, and concentrates leave early in the year when coverage is usually easiest.

Set the cap and the deadline deliberately

A cap of about one working week is the sweet spot for most teams. Meaningfully smaller caps make the carry-over symbolic, so employees treat it as use-it-or-lose-it and squeeze days into December anyway. Much larger caps let balances stack two allowances high, which recreates the liability problem carry-over caps exist to solve.

For the deadline, the end of Q1 (March 31) has become the de facto standard, and for a reason found in statutory systems too: Germany's leave law uses the same date for carried statutory leave. A deadline earlier than March tends to collide with year-start workloads; a deadline in summer merges two leave years into one long blur and defeats the purpose of the cap.

The year-end timeline that prevents the December pileup

Year-end problems are made in October. Teams that communicate balances early spread usage across three months; teams that stay silent get a December in which half the company requests the same two weeks. The working cadence looks like this:

• Early October: send every employee their current balance, the carry-over cap, and the expiry date. Managers get a team view so they can plan coverage instead of reacting to it.
• November: nudge only the people whose balance still exceeds the cap. A targeted reminder outperforms a company-wide broadcast that everyone else ignores.
• December: approve with coverage rules rather than blanket blackouts. If minimum-staffing rules are enforced automatically, managers stop being the bad guy and the calendar stays workable.
• January 1 (or your reset date): the rollover runs automatically, capped days carry, the rest expires exactly as announced.
• Late February: one reminder to everyone still holding carried days, naming the March 31 use-by date.
• April 1: expiry executes. Because every step above happened, this is a non-event.

What companies with healthy policies do differently

Across the policies we see configured in practice, the common denominators of the low-friction ones are behavioral, not structural. They put the remaining balance where people already look, in the leave tool and on the request screen, instead of in a quarterly email. They make the expiry date per-person and concrete ("your 3 carried days expire March 31") rather than quoting policy text. And they never let days expire silently: forfeiture that arrives as a surprise destroys more goodwill than a stricter rule communicated well.

The other habit worth copying is separating the question "how much rolls over" from "what happens at termination". Carry-over is a year-end rule; payout at departure is governed by state law and the written policy, and in payout states accrued days must be paid out regardless of the carry-over model. Conflating the two in policy text is a reliable source of disputes.

Compliance guardrails before you publish the rule

Two legal checks belong in every carry-over review. In the US, states that treat accrued PTO as earned wages (California is the best-known) prohibit use-it-or-lose-it forfeiture; the compliant alternative is an accrual cap, which stops new days from being earned at a ceiling instead of taking earned days away. If you employ across states, the policy needs either the strictest common denominator or per-state variants.

In statutory systems the defaults flip. German statutory leave, for example, must generally be used in the calendar year, carried days expire March 31, and case law adds that leave only expires if the employer explicitly warned the employee in time. If you run a multi-country policy, keep the statutory layer per country and apply your company rule only to the additional days on top.

The two numbers that tell you if the policy works

Expired-days rate: how many carried days lapsed unused on the use-by date. A rate near zero means the reminders and the window work. A climbing rate means people cannot realistically use what they carry, which points at the cap, the deadline, or chronic understaffing rather than at the employees.

December request concentration: the share of the year's leave requested in the last six weeks. If it keeps rising, balances are being communicated too late. Both numbers come free out of a leave system's reporting; both are miserable to assemble from a spreadsheet, which is itself an argument for automating the mechanics.