Best Practices: Retro & Forecasts

Retro Corrections

Delta wage types run in the current period only — never in retro recalculations

Retro scenarios require two distinct wage type groups: base wage types that are re-executed for each historical period, and delta wage types that collect the accumulated correction and run exactly once in the current payrun period.

In practice: assign base wage types to both Legal and Retro clusters. Assign delta wage types to Legal only. If a delta wage type were placed in the Retro cluster, the engine would re-execute it inside each historical period and produce partial intermediate totals instead of the final accumulated correction. Number delta wage types adjacent to their source (102 for 100, 202 for 200) so the relationship is visible in payslips and reports.

For the retro correction expression, prefer the RetroSum wage type accessor over a direct method call. In valueActions (No-Code), reference the source wage type by name: ^$BaseSalary.RetroSum. In valueExpression (scripting), call GetRetroWageTypeValueSum(100M) by number.

Store baseline results on every payrun that may be followed by a retro correction

Retro corrections are computed as the difference between the newly recalculated historical result and the value previously stored for that period. If no result was stored, the engine treats the prior value as zero and the correction equals the full recalculated amount.

In practice: set storeEmptyResults: true on all payrun jobs in a regulation that uses retro recalculation. This applies to baseline periods even when no correction is expected yet — a retro trigger can arrive for any past period.

Forecasts

Forecast payruns isolate what-if scenarios from production data

Forecast payruns share the regulation with production but operate on forecast-tagged case data. Multiple named scenarios can run in parallel over the same periods without affecting statutory results.

In practice: tag case changes with forecast: "ScenarioName" at the case change level (the outer object, not inside case:). The ^^ operator automatically resolves the forecast-scoped value as an override inside the forecast payrun — no regulation change or script required. Use storeEmptyResults: true to produce complete result sets across all employees for comparison. Name scenarios clearly (SalaryIncrease2026, BonusScenario2026) so results remain unambiguous when queried across multiple scenarios.