Year-end and carry-forward

Leave → Settings → Year-end is where a leave year ends and the next one begins. It’s a stack of cards, not a wizard, and you’ll typically use one card a year.

Before you start

Closing a calendar or financial year is blocked by any pending leave request in the organization — regardless of which year it falls in:

3 pending leave request(s) must be approved, rejected, or withdrawn before closing the year

Clear the backlog from Leave → Approvals first. Requests in cancellation pending block it too.

Close a calendar or financial year

The page shows one card per leave-year basis your organization actually uses — a Calendar year card, and/or a Financial year (Apr → Mar) card. You don’t pick the basis or the fiscal month; they come from your enabled leave types.

Roll forward unused entitlement from the selected window into the next one for every active employee with a leave type on this calendar/fiscal basis. All pending leave requests must be settled before closing. Re-runnable if prior-period balances change.

1. Pick the Window to close. It defaults to last year and offers the current year and two back.

2. Read any warning under the picker:

   • Previously closed on {date} — re-closing refreshes the carry-forward.
   • No balance data exists for {window} — carry-forward will be 0 for everyone.

3. Optionally add a Description, e.g. Calendar year 2025 close-out.

4. Select Close {window} and confirm.

The confirmation surfaces up to three callouts before you commit:

• Already closed — re-closing doesn’t duplicate anything, it refreshes carry from current balances.
• No balance data — carry-forward will be 0 for everyone; import balances first if you’re onboarding a historical year.
• Heads up — the window hasn’t ended yet, so leave approved between now and the window end won’t be reflected. You can re-run afterwards.

What actually happens

For every non-terminated employee and every enabled leave type on the matching basis:

1. The next window’s balance row is created or refreshed, with carry-forward computed and capped at the policy’s Carry-fwd value.
2. A snapshot row is written recording entitled and carried before and after — but only for types that actually carry, so types with a zero cap don’t clutter the receipt.

Terminated employees are skipped — their balances are frozen and don’t carry forward. Anniversary-basis types are never handled here.

How carry is calculated

For each employee and type, from the closing window:

• Days taken are charged against carried days first, so the maximum amount of fresh entitlement stays carry-eligible.
• What carries is the unused portion of that window’s own entitlement plus any adjustment, capped at Carry-fwd.
• Carried days don’t stack. Days that were carried into the closing window can’t carry again — they had to be used in that window.

A negative adjustment reduces what carries; a positive one can carry.

Tip

Re-running a closing is the supported way to refresh carry after a prior-year edit. Each run writes a fresh entry in the history rather than overwriting — the old receipts are preserved. Prior-year edits stay legal after a close.

Anniversary closings

Anniversary-basis leave types roll per employee, on their work anniversary, so they close monthly rather than annually.

Anniversary leave windows roll per employee. Each month closes the windows that ended in that month — run shortly after the month ends. Per employee, pending leave requests in the just-ended window block that employee (others still close); settle and re-run to include them.

The Anniversary closings section lists months awaiting a close, each with the count of employees with anniversaries that month and a Close button. Below a divider, Close a specific month lets you pick any year and month — For re-runs after edits, closing a future month early, or a past month that isn’t in the list above.

Two behaviours differ from the annual close:

• The pending-request gate is per employee. One blocked employee doesn’t stop the rest; the toast tells you how many were skipped so you can settle and re-run.
• A month with no anniversary employees writes no closing at all, so it stays in the awaiting list in case someone is backfilled into it later.

The section is hidden entirely if your organization has no anniversary-basis types.

Carry-forward expiry

Separate from closing the year: forfeiting carried days that were never used before their deadline.

Forfeit carried-forward leave whose carry-forward window has closed, across every employee and leave type in this organization. Only carry left unused past its expiry deadline is removed — consumption draws down carry first. Safe to run any time: nothing is forfeited before a balance reaches its own deadline. This runs automatically each day; use it to apply the forfeiture immediately.

Run carry-forward expiry applies it now. The result is either No carry-forward is past its expiry — nothing forfeited. or Forfeited {n} day(s) of expired carry-forward across {n} balance(s).

The sweep is safe by design:

• It only ever forfeits on or after a balance’s own deadline, so running it late is still correct.
• It’s idempotent — re-running changes nothing further.
• It self-heals: if a cancelled request frees up carry after the deadline, those freed days are forfeited on the next run rather than becoming a windfall.
• A later recompute can’t resurrect forfeited days.

Employees get up to three reminders as a deadline approaches — at 30, 14 and 7 days out — with the subject Carry-forward leave is about to expire and the exact number at risk.

Caution

Two things to verify in your own deployment.

The daily sweep only runs if the sweep worker process is running. It is not wired into a cron or a deploy manifest — it’s a standalone long-lived process (worker:sweep) that has to be started. If nobody starts it, carry-forward expiry and its reminder emails never fire, and this button is your only mechanism.

Carry expiry needs a deadline to be configured. Set Carry-forward expires on the leave type. Leave it blank and carried days have no deadline, so this action finds nothing to forfeit — unused carry simply disappears at the next rollover instead, silently and without a reminder.

History

The History card lists previous closings, newest first, with Window, Scope, Closed at, Closed by and Description. Rows are clickable.

The detail page shows the snapshot taken at the moment of close — {n} balance row(s) rolled into the next window — with a per-employee, per-leave-type table: Employee, Leave type, Entitled before, Entitled after, Carried before, Carried after. A dash in a “before” column means the row was freshly seeded.

These snapshots are permanent receipts. They’re never rewritten by a later re-run or by an employee’s tenure edit, which makes them the reliable record for an audit — the Closed-year snapshots source on the balances report reads from them.

Note

One caveat on those snapshots: the department shown is the employee’s current department, not the one they were in when the year closed.

A suggested year-end sequence

1. Clear all pending leave requests and cancellations from Leave → Approvals.

2. Check Leave → Reports → Balances for the closing year and resolve anything that looks wrong — negative balances, missing entitlement, employees with no policy.

3. Run Recompute leave balances for the closing year from the Settings tab if you changed policies during the year.

4. Add next year’s public holidays under Holidays — employees will start booking into the new year as soon as it begins.

5. Close the window from Year-end.

6. Spot-check the closing detail page against a few employees you know.

7. Run Run carry-forward expiry if your policies set an expiry deadline.