We’re experiencing a consistent issue where bonus calculations in our compensation module are off by exactly one pay period. After our cloud migration to UP 2023.2, employee bonuses are being calculated based on the previous pay period’s data instead of the current one.
The problem appears related to pay calendar alignment and possibly time zone configuration. When we run test calculations, the accrual logic seems to reference t-1 period instead of t0. Here’s what we’re seeing in the calculation log:
CalcPeriod: 2025-03-01 to 2025-03-15
DataPeriod: 2025-02-15 to 2025-02-28
Offset: -1 period detected
This affects approximately 200 employees in our quarterly bonus program. Has anyone encountered similar period misalignment issues post-migration? Need guidance on validating the calculation engine configuration.
After changing Period Reference Mode, you absolutely need to invalidate the calculation cache and trigger a full recalculation. The cloud system caches calculation metadata for performance, so your config change won’t take effect until you clear it. Go to System Admin > Calculation Engine > Cache Management and click ‘Invalidate Compensation Cache’. Then run a test calculation on a single employee first to validate before doing the full batch. Also, verify your effective dating - if your bonus plan has an effective date that started before the config change, you might need to create a new effective-dated row for the corrected configuration.
One more thing to check: the data source mapping for your bonus calculations. In UP 2023.2 cloud, the compensation module uses a different data pipeline than on-prem versions. Your calculation might be pointing to a staging table that has a built-in lag. Check the bonus plan’s data source configuration and ensure it’s mapped to the real-time compensation data view rather than the batch-updated staging tables.
Let me provide a comprehensive solution addressing all the elements causing your period mismatch:
Pay Calendar Alignment: First, verify your pay calendar configuration is correctly mapped post-migration. Navigate to Compensation > Configuration > Pay Calendars and confirm each period’s start/end dates match your business calendar exactly. In UP 2023.2 cloud, pay calendars must have explicit time zone associations - check that each calendar entry includes the correct TZ identifier (e.g., ‘America/New_York’ not just ‘EST’).
Accrual Logic Review: Your bonus plan’s Period Reference Mode was set incorrectly to ‘Previous’ instead of ‘Current’. After correcting this:
// Verify the configuration change:
BonusPlan plan = BonusPlan.getById("QUARTERLY_BONUS_2025");
plan.setPeriodReferenceMode(PeriodReferenceMode.CURRENT);
plan.setEffectiveDate(new Date("2025-03-20"));
PersistenceHelper.manager.save(plan);
Time Zone Configuration: Cloud deployments require explicit UTC offset handling. Go to System Configuration > Regional Settings > Organization Time Zones and verify your primary location has the correct offset. The calculation engine uses this for all period boundary determinations. If your organization spans multiple time zones, ensure each location has accurate settings.
Test Calculation Validation: After making changes, follow this validation sequence:
Run a single-employee test calculation with detailed logging enabled
Review the calculation trace to confirm DataPeriod now matches CalcPeriod
Verify the offset shows ‘0 period’ instead of ‘-1 period’
Compare calculated bonus amounts against manual calculations for 2-3 employees
Only after validation, trigger the full batch recalculation for all 200 affected employees
Additional Considerations: Check your data source mapping in the bonus plan configuration. UP 2023.2 introduced new real-time data views that should be used instead of legacy staging tables. If your plan still references ‘COMP_STAGING_VW’, update it to ‘COMP_REALTIME_VW’ to eliminate any inherent data lag.
The effective-dating is critical - your configuration change needs a new effective-dated row starting from the correction date forward. Historical calculations may remain incorrect unless you choose to reprocess them retroactively. For the current quarter, this approach should resolve your period alignment issue completely.
Look at your accrual logic configuration. The calculation engine might be using a default lookback parameter that wasn’t adjusted during migration. In the cloud version, there’s a specific setting called ‘Period Reference Mode’ in the bonus plan definition that controls whether it uses current period (0), previous period (-1), or next period (+1). Your log output showing ‘Offset: -1 period detected’ confirms the engine is in lookback mode. Navigate to the bonus plan configuration and check the Period Reference Mode dropdown - it’s probably set to ‘Previous’ when it should be ‘Current’.
Thanks for the suggestions. I checked the Period Reference Mode and it was indeed set to ‘Previous’ - not sure how that changed during migration. However, even after switching it to ‘Current’, our test calculations are still pulling data from the wrong period. The time zone configuration looks correct (EST properly mapped), and the pay calendar dates are accurate. Could there be a caching issue or do I need to trigger a full recalculation of the affected bonus plans?