Absence Plan Configuration: Accruals That Actually Reconcile
Absence plans look straightforward until carry-over, proration, and eligibility collide. Here's how to configure plans that give employees numbers they can trust.
Absence Management is one of those modules that demos in ten minutes and takes weeks to configure properly, because real leave policies are full of carry-over caps, proration for part-year workers, and eligibility rules that shift with tenure. The accrual logic has to be right, because employees plan their lives around these balances.
Get the accrual method matched to policy
Front-loaded, incremental, or based on time worked, the accrual method must match your written policy exactly. A common failure is configuring monthly incremental accrual when policy grants the full entitlement up front, leaving new joiners short and confused in January.
Carry-over is where the bodies are buried
Carry-over rules, how much rolls into the next year, when it expires, whether it's paid out, are the most error-prone part of absence config. Model them explicitly, including the expiry processing, and test the year-end roll before it happens for real. A botched year-end roll hits every employee at once.
Proration for joiners and leavers
Someone joining in July shouldn't accrue a full year's leave. Someone leaving mid-year needs their balance settled correctly. Proration rules handle this, and they need testing with real mid-period dates, not just clean January starts.
Real scenario: a client's carry-over was configured to expire in March but the payout logic ran in January, so employees lost days they were entitled to. Nobody noticed until a wave of complaints. We aligned the expiry and payout timing and back-corrected the balances. A small config detail, a big trust problem.