Calculation Modes

When configuring your LSL policy’s general settings in the General tab, you can choose one of two calculation modes in the Mode drop-down list that Dayforce uses to evaluate LSL. By choosing one calculation mode over the other, you can control how the LSL engine in Dayforce interprets some of your policy settings and how the system applies the data to your employees. The calculation mode that you choose has a direct impact on how Dayforce calculates key LSL dates (such as the continuous employment start date or LSL eligibility date) for some employees.

The Mode drop-down list contains two calculation options:

Legacy: This option represents the default processing logic that’s been available in Dayforce since LSL functionality was added. If you configured an LSL policy before 2025, this option is selected by default so that Dayforce processes LSL changes using the existing logic.
For a summary of the LSL settings and behaviours that this mode affects, see Legacy Mode.
Enhanced Validation: This option applies additional processing logic and validation to improve the accuracy of the LSL entitlement dates that Dayforce calculates. This option useful in cases where a complicated policy configuration or ambiguous data results in no clear set of rules to apply.
When you enable this calculation mode:
- Some additional UI validations and restrictions will occur. With enhanced validation, Dayforce prevents you from configuring combinations of settings that might cause calculation issues. When you attempt to save changes to your LSL policy, the system will only validate settings that are supported in enhanced validation mode.
- Dayforce interprets some LSL fields and settings differently during processing. This evaluation change ensures that the LSL processing engine can determine priority when conflicting conditions exist.
For a summary of the LSL settings and behaviours that this mode affects, see Enhanced Validation Mode.

In Dayforce, an LSL policy and the Calculate Long Service Leave Entitlement background job serve to calculate an employee’s periods of service and nonservice. From this calculation, the system determines an employee’s Continuous Employment Start Date for LSL in People, and their entitlement dates.

When an employee has periods of service that span multiple LSL policy settings, Dayforce might split their service and subject their service to different sets of rules. This split can occur in scenarios where an employee transfers to employment in a different state, or when configuration changes with different effective dates impact their continuous service. When a split in continuous service occurs, the LSL calculation engine needs clear guidance on what takes precedence to produce a single, consistent set of entitlement dates.

To address these ambiguous scenarios, the processing engine needs to correctly interpret the results to ensure that the entitlement dates produced are consistent with the intended goals of Australian LSL:

When determining entitlement dates, all service should be evaluated based on the legislation of the state that the employee is currently working in. For example, an employee who worked in State A and then moved to State B should have all of their service evaluated based on State B’s LSL requirements when determining entitlement dates.
When an event occurs that would alter an employee’s entitlement date as defined in People in Employment > Employment Settings, changes should be applied based on the employment status and effective-dated record that’s applicable at the time of the event. An example of this is an employee experiencing a status change due to a leave without pay (LWOP) period that they’re taking.

Changing the processing logic of your LSL policy is optional because it could impact how Dayforce determines an employee’s entitlement dates and it might require changes to settings in your policy configuration. It’s recommended that you switch to enhanced validation mode in a test environment to review its impact. If the new processing logic isn’t satisfactory, you can switch back to the legacy calculation mode.

Legacy Mode

When you choose Legacy in the Mode drop-down list, the following settings and behaviours are affected.

How Legacy mode affects LSL settings and calculations
Setting	Location and Description
Country	This setting is located in the State/Territory Details tab in the General section. This setting serves to restrict the options that are available in the State drop-down list.
State	This setting is located in the State/Territory Details tab in the General section. The system processes service periods based on the state where the employee was located and working in at the time. If an employee moves to another state, this behaviour might create conflicts when the LSL processing engine attempts to determine entitlement dates. If the system detects a conflict, Dayforce shows the following error message in the Calculate Long Service Leave Entitlement background job log: “Long Service Leave Entitlement Date is potentially ambiguous because the employee has Employment Periods in more than one Country and State/Territory/Province.” When this issue occurs, Dayforce won’t calculate an LSL eligibility date unless the job was configured with the Feature Preview Mode setting enabled.
Effective From Effective To	These settings are located in the State/Territory Details tab in the Configuration section. Dayforce applies the LSL policy’s effective dates to employee service periods as true start and end dates, with any new configuration only coming into effect on the specified date.
Pay Classes	This setting is located in the State/Territory Details tab in the Employment Categories subsection. Similar to the effective dates, the LSL processing engine determines an employee’s service periods based on their assigned pay class at the time. This behaviour might create conflicts when the processing engine tries to determine which conditions to apply. If a conflict is detected, Dayforce shows the following error message in the Calculate Long Service Leave Entitlement background job log: “Long Service Leave Entitlement Date is potentially ambiguous because the employee has Employment Periods with more than one Pay Class.” When this issue occurs, Dayforce won’t calculate an LSL eligibility date unless the job was configured with the Feature Preview Mode setting enabled.
Extend Long Service Leave Eligibility Date After	This setting is located in the State/Territory Details tab in the Employment Categories subsection, in the Leave Categories subtab. This setting, combined with the TAFW Pay Codes and Employment Status Reason settings, extends service after: Employees are granted TAFW with a specific pay code, or are assigned a specific reason based on an employment status change, depending on your configuration. A customized threshold of time has been met. If multiple TAFW requests exist within a single employee service period, the application might aggregate the requests, but only apply the threshold one time. This behaviour can result in the LSL processing engine calculating an incorrect entitlement date for the employee. In the Extend Long Service Leave Eligibility Date After drop-down list, the Days in a Year and Weeks in a Year options are available. These options can impact LSL calculation when paired with other settings or when calculation spans leap years.
End Continuous Service After (leave category)	This setting is located in the State/Territory Details tab in the Employment Categories subsection, in the Leave Categories subtab. This setting, combined with the TAFW Pay Codes and Employment Status Reason settings, resets the Continuous Employment Start Date in People after: Employees are granted TAFW with a specific pay code, or are assigned a specific reason based on an employment status change, depending on your configuration. A customized threshold of time has been met. Note the following behaviours: Service resets on the day that the request reaches the threshold, but service doesn’t break. Because of this behaviour, all of the days that are included in the TAFW request or status change that triggered the reset are still treated as service. This setting supports an input of zero days. This configuration can create negative date calculations in the database when determining the LSL service period, specifically when performing one-day calculations and when determining the service period start and end dates. This setting works in conjunction with the Extend Long Service Leave Eligibility Date After threshold. Because of this behaviour, your configuration might create a single request that can loop through multiple extend and end events to calculate an unexpected entitlement date. In the End Continuous Service After drop-down list, the Days in a Year and Weeks in a Year options are available. These options can be ambiguous and can impact LSL calculation when paired with other settings or when calculation spans leap years. It’s recommended that you configure this setting as follows in legacy mode: None for Australian users. Days: 0 for New Zealand users to trigger the closedown period to adhere to the New Zealand Holidays Act.
End Continuous Service After (employment status)	This setting is located in the State/Territory Details tab in the Employment Categories subsection, in the Employment Statuses subtab. This setting resets the Continuous Employment Start Date field in People based on the status or reason code (or both) that’s derived from the employee’s profile in People in the Employment > Employment Settings screen. The start date is reset after the employee reaches the nominated threshold. Note the following behaviours: Service resets on the day that the request reaches the threshold, but service doesn’t break. Because of this behaviour, all of the days that are included in the TAFW request or status change that triggered the reset are still treated as service. This setting supports an input of zero days. This configuration can create negative date calculations in the database when determining the LSL service period, specifically when performing one-day calculations and when determining the service period start and end dates. In the End Continuous Service After drop-down list, the Months option is available. This option can be ambiguous and can impact LSL calculation when paired with other settings. You can use this setting to: Allow terminations or rehires to be treated as continuous service and not be interrupted, if they’re within a specified period. Exclude specific status types from producing an entitlement date.

Enhanced Validation Mode

When you choose Enhanced Validation in the Mode drop-down list, the following settings and behaviours are affected.

How Enhanced Validation mode affects LSL settings and calculations
Setting and Its Location	Description
Country	This setting is located in the State/Territory Details tab in the General section. The selected country affects access to the End Continuous Service After setting in the Employment Categories subsection, in the Leave Categories subtab. The End Continuous Service After setting is available only if you select New Zealand in the Country drop-down list. The End Continuous Service After setting isn’t applicable to Australian use cases. Its unavailability will prevent misconfiguration and potential errors from miscalculation. See End Continuous Service After.
State	This setting is located in the State/Territory Details tab in the General section. When calculating entitlement dates, Dayforce processes an employee’s service periods based on the state that they’re currently in, not the state that was applicable previously. For example, consider an employee who moved from State A to State B. After moving, all of the employee’s service, including time worked in State A, is treated as if the service was worked in State B. This processing behaviour removes conflicts when the LSL engine tries to determine the correct entitlement date to apply. In scenarios where multiple states are involved, Dayforce shows the following error message in the Calculate Long Service Leave Entitlement background job log: “Employee has Employment Periods in more than one Country and State/Territory/Province. Service has been calculated using the values of the current Employment Period.” Further, in these scenarios, the system can calculate an LSL eligibility date without the Feature Preview Mode checkbox selected in the background job’s settings.
Effective From Effective To	These settings are located in the State/Territory Details tab in the Configuration section. The effective dates in the LSL policy are applied using the following behaviours: For configuration records (that is, records in the Configuration section), new effective-dated records will supersede the previous records, rather than starting from that point. When a new effective-dated record comes into effect, the number of years that an employee needs to work to reach an LSL qualification or payout is calculated and applied from the employee’s Continuous Employment Start Date, not the start date of this new record. For employment category records (that is, records in the Employment Categories subsection), the effective dates function as start and end dates. Because of this behaviour, Dayforce evaluates periods of employment by the appropriated effective-dated record. This evaluation behaviour ensures that changes in the handling of conditions, such as LWOP and its impact on service, can be preserved when legislation changes. For example, any LWOP that an employee takes will always be processed using the effective-dated record that’s applicable to that period. Dayforce considers the current effective-dated LSL policy record as applicable. If a future-dated record is added to the LSL policy, it won’t take effect until it matches the current server date and time. When an employee has a future start date and no current active service, the LSL processing engine attempts to calculate the service but won’t detect any records. In this scenario, Dayforce shows the following message in the Calculate Long Service Leave Entitlement background job log: “Employee has no current or historical Employment Periods. Dates calculated based on future Employment Periods which may be subject to change.”
Pay Classes	This setting is located in the State/Territory Details tab in the Employment Categories subsection. As per the effective dates, Dayforce processes an employee’s service periods based on their assigned pay class at the time, but using the rules of the current state that the employee is working in. For example, part-time service in State A will be treated as part-time service in State B if an employee is now employed in State B. This behaviour ensures a consistent logic and ensures that Dayforce can calculate a set of entitlement dates. The logic that produces error messages involving pay class changes is different in enhanced validation mode. Dayforce doesn’t require that the Feature Preview Mode checkbox is selected in the Calculate Long Service Leave Entitlement background job’s settings to control this logic.
Extend Long Service Leave Eligibility Date After	This setting is located in the State/Territory Details tab in the Employment Categories subsection, in the Leave Categories subtab. This setting applies a threshold once per instance of the nominated TAFW pay codes or employee status reason (as configured in the TAFW Pay Codes and Employment Status Reason settings in the Leave Categories subtab). For cases where TAFW extends eligibility, each TAFW request will be treated as an instance (that is, a continuous occurrence) unless: A subsequent TAFW is contiguous with another TAFW period and shares the same TAFW pay code that’s listed in the Leave Categories subtab. In this scenario, the requests are combined and considered a single TAFW request. If the TAFW isn’t contiguous or if the TAFW pay code is in a different leave category record, then these will be seen as different instances and the threshold will be applied to each request independently. If a TAFW request spans Monday to Sunday, and the next request is for Monday to Sunday, Dayforce considers these requests contiguous. If a TAFW request spans Monday to Friday, and the next request is for Monday to Friday, Dayforce considers these requests non-contiguous. Any TAFW that you enter as a pay adjustment instead of submitting as a TAFW request will occur only on days where a pay code is present. Any days without pay codes will interrupt the TAFW period. Partial-day pay adjustments and TAFW codes don’t count towards the threshold. When using enhanced validation mode, some options for Extend Long Service Leave Eligibility Date After aren’t available. The Days in a Year and Weeks in a Year options are unavailable to prevent ambiguity in the calculation results. The field defaults to None. This setting can’t be used in conjunction with the End Continuous Service After setting in the same employment category record. In enhanced validation mode, they’re mutually exclusive of each other and will be validated when you save your changes.
End Continuous Service After	This setting is located in the State/Territory Details tab in the Employment Categories subsection, in the Leave Categories subtab. This setting has been restricted for use only in New Zealand to support a New Zealand Holidays Act use case to reset the Continuous Employment Start Date only in cases where a shutdown pay code exists. Note the following behaviours: This setting resets service but doesn’t break it. Because of this behaviour, there’s no interruption of service or creation of nonservice periods. This setting is editable only when the Country field is set to New Zealand. The field defaults to None. This setting and the Extend Long Service Leave Eligibility Date After setting are mutually exclusive and can’t be configured with the same TAFW pay code or employment status reason to avoid date calculation conflicts. The LSL processing engine applies additional validation to adhere to shutdown pay code requirements. A shutdown pay code will reset the Continuous Employment Start Date if it’s assigned within 12 months of the employee’s most recent hire or rehire date. If assigned after this, the reset won’t occur and a message is shown in the background job log. Dayforce determines the End Continuous Service After date based on the first day of the TAFW request. For a New Zealand Holidays Act shutdown, this is entered as a single-day pay code. However, if a user enters a five-day request, the reset is triggered on the first day. Because all days are evaluated as service, the remaining four days will have no impact. When using enhanced validation mode, some options for End Continuous Service After aren’t available. The Days in a Year and Weeks in a Year options are unavailable to prevent ambiguity in the calculation results.