beqom PaySuite 26.1 - Feature release notes

This article details the latest improvements introduced in version 26.1 of the beqom PaySuite application, their benefits for our end-users, and their principles of use.

Compensation Management

Inline column search in group configuration

With this release, managing column groups in Workbench > Compensation Management > Compensation Rounds > Team planner view has become faster and more intuitive. The new Manage column groups modal offers an inline autocomplete search. This lets Global Compensation Admins and Compensation Admins add and remove columns without switching views. The search lists all ungrouped columns alongside those assigned to the selected group, with checkboxes indicating their current state: checked columns are already included and can be removed, while unchecked ones can be added. The dropdown remains open after each selection so that administrators can make multiple changes in a single sequence, and typed search text is preserved to allow continued filtering while choosing columns. Column counts update immediately in both the group list and the column section header after each change, giving an at-a-glance view of group size without opening each group individually.

New modal for managing column groups

Statement generation enhancements

We have expanded the statement generation payload with a range of new fields, giving template authors more data to work with when creating compensation statements and enabling more comprehensive, transparent output for workers.

Payout curve name and date formatting

Each goal now exposes the name of its assigned payout curve as PayoutCurveName on each PayoutCurveResults item. This way, templates display which curve drove a given result. The field can be referenced within an existing {{loop PayoutCurveResults}} block, with no template restructuring required. Also, for clarity and readability, all date fields in the payload are emitted without the time component, for example, 2026-01-01 rather than 2026-01-01T00:00:00.

Per-goal and per-situation bonus amounts

The monetary bonus attributable to each individual goal, matching the value shown in the "Bonus payout" column within Planner > Compensation, is now available as BonusPayoutAmount inside {{loop PayoutCurveResults}}. It carries local currency and converted value, accessible as .Value, .Currency, and .ConvertedValue. For workers with multiple situations, such as mid-year country, role, or salary changes, three per-situation bonus fields expressed in a common currency are also available inside {{loop SituationDetails}}: the raw target bonus (SituationTargetBonusInLastSituationCurrency), the target bonus after Time in Role and Leave of Absence adjustments (SituationTargetBonusAdjustedInLastSituationCurrency), and the actual calculated bonus (SituationBonusInLastSituationCurrencyValue). This facilitates accurate aggregation of bonus totals across situations. No recalculation is required; all values are read directly from existing calculation data and remain consistent with what appears in the Planner.

Payout curve ranges and goal description

The threshold, target, and cap payout curve percentages for each goal can now be used inside {{loop PayoutCurveResults}} as MinPayoutCurveResultPercentage, TargetPayoutCurveResultPercentage, and MaxPayoutCurveResultPercentage, with corresponding bonus amounts MinBonusAmount, TargetBonusAmount, and MaxBonusAmount, each following the same monetary shape as BonusPayoutAmount. Together, these give statements the full payout curve shape per goal. The goal description defined in Data Foundation can also be used as GoalDescription within the same loop. It always returns a string (empty if no description has been set) and never causes a generation error.

Data model calculated fields

Calculated fields from the data model, such as anniversary dates, risk-taker flags, or custom formulas, can now be referenced in statement templates together with standard data model fields. They are accessible under ModelData, for instance, ModelData.CalculatedFieldTenureYears, with values read from the snapshot at generation time. For workers with multiple situations, the value from the last situation is used. Only fields referenced in the template appear in the payload.

Importantly, in strict mode, statement generation will fail for any worker where a referenced calculated field has no value. Template authors must ensure that all referenced calculated fields are populated for the full worker population before generating statements in this mode.

Data model extension alerts for calculated fields

In version 26.1 of the PaySuite application, when a Data Foundation Admin adds new calculated fields to a data model, the system notifies Compensation Admins through the same alerting mechanism used for entity-field extensions. Changes are logged in the Last updates section, accessible from Workbench > Compensation Management > Compensation Rounds > Round Management, with a dedicated notification that distinguishes calculated-field additions from entity-field additions. A dismissible banner in the Team planner view provides a direct link to preview the newly added fields, which appear under their own section of the Model details drawer.

New calculated fields are automatically included in the Team planner view of affected Draft rounds with visibility disabled, ensuring no changes are silently exposed to managers without deliberate administrator review.

Advanced calculation engine for Guidelines

We have upgraded the Guidelines step in Workbench > Compensation Management > Compensation Rounds, enabling more flexible and precise compensation boundaries than the previous rule builder allowed. Currently, Guidelines rely on the same advanced calculation engine as calculated columns, Eligibility, and Budget. Administrators define separate formula-based Minimum and Maximum boundaries with the help of the formula editor, with access to the calculation workspace and numerous field types, including data model fields, compensation element inputs, calculated fields, and the outputs of other round calculations such as Eligibility and Budget. Per-worker filtering is expressed directly within the formulas using conditional logic, removing the need for a separate criteria step. Each boundary can be independently configured to warn managers when a value falls outside it, or to block saving entirely, using the relevant toggle.

When a manager edits a value in Planner > Compensation, the system immediately re-evaluates any guideline whose formula references the changed field, keeping the displayed boundaries and enforcement outcome up to date.

Any field referenced in an active guideline formula is protected as a dependency; it cannot be deleted or disabled while in use. Disabling a rule removes it from dependency tracking.

Existing guideline rules are migrated automatically, with each legacy configuration converted into equivalent conditional formulas to preserve the original behavior across all round statuses.

Conditional formula configuration for a guideline rule minimum boundary

Custom entity lookups in compensation rounds

From now on, formulas across compensation round calculations, such as guidelines, eligibility, budget, and calculated columns within Workbench > Compensation Management > Compensation Rounds, can look up values from custom entities defined in Data Management, including merit matrices, country tables, or payout grids. This keeps formulas accurate as reference data evolves, without duplicating or hardcoding values. Administrators can access all custom entities in the formula editor under ReferenceData.CustomEntities with no need for per-round configuration, and changes made in Data Management are reflected automatically. A lookup returns either the entire matched row or a specific field from it, using .ColumnName to retrieve a single value. The guided LOOKUP helper is also available to build and validate lookup expressions visually, and have them evaluated reliably at calculation time.

Pay Transparency

Annual limits for worker-initiated pay information requests

In version 26.1, Pay Transparency allows administrators to limit the number of pay information requests that workers can submit through the digital reward statement in a single calendar year. The aim is to help organizations comply with the EU Pay Transparency Directive (EUPTD), prevent excessive requests, and reduce unnecessary administrative workload. Limits are managed under Workbench > Pay Transparency > Pay Information > Pay Information Requests. They can be configured globally or overridden at country level to accommodate local legislation or specific business requirements. Once a limit has been reached, the Request pay information action in the Pay information widget within Passport > Compensation is hidden and workers see the count of submitted and remaining requests directly in their digital reward statement. Counters reset automatically on January 1 each year.

The limit applies only to worker-initiated requests. Requests created by HRBPs or imported through APIs are not counted or restricted. Existing requests remain visible after reaching the limit.

Global configuration of the annual request limit per worker

Submitted and remaining request count in the digital reward statement

Demo

Configurable document file naming

With this release, administrators can define custom filename patterns for documents generated for pay information requests, configured in the Generated file name section under Workbench > Pay Transparency > Pay Information > Pay Information Requests. Instead of relying on a fixed naming convention, patterns combine static text with supported variables, including the worker identifier and full name, request identifier, snapshot effective date, file generation date (year, month, and day), and worker category. The configured pattern is applied automatically and consistently across all generated documents, eliminating the need for manual renaming, simplifying file identification, and improving compatibility with internal and external document management systems.

Custom file naming configuration using variables

Demo

Pay Information improvements in the Planner

We have introduced two improvements to Planner > Pay Information for a cleaner, more efficient user experience.

There, the Bulk actions tab includes a new Show my executions only toggle, enabled by default. The toggle filters the execution history to show only bulk actions initiated by the logged-in HRBP, based on the Executed by column. This shortens the time spent searching through bulk actions when multiple HRBPs are engaged. Disabling the toggle reveals the complete history of actions executed by all authorized HRBPs.

Show my executions only toggle for bulk actions

Demo

In addition, reminder notifications sent to HRBPs for incoming, approaching, or overdue pay information requests now contain a direct link to Planner > Pay Information, allowing immediate access to the queue without manual navigation. This also lets HRBPs be more responsive to time-sensitive requests.

Notably, the link opens the Pay Information page without applying filters based on the notification context. Contextual filtering is planned for a future release.

Reminder notification for overdue pay information requests

Demo

Enhanced pay remediation cost insights

We have enhanced pay remediation to increase visibility of salary recommendations throughout the process. Selected pay analyses in both Workbench and Plannerdisplay the percentage of current total compensation represented by salary adjustment amounts alongside the existing monetary figures. As a result, Compensation Administrators and HRBPs can better evaluate the budget impact of remediation activities and make more informed decisions.

In Workbench > Pay Intelligence > Pay Analysis > Pay Analysis Results, the Total cost of raises insight shows percentages for the model prediction, recommended adjustments after administrator review, and finalized adjustments after HRBP review. In Planner > Pay Analysis, HRBPs see percentages for recommended and final raises only, reflecting the scope relevant to their role. All percentages are calculated against the current total compensation of the selected analysis.

Model, Recommended, and Final raise percentages in Workbench

Recommended and Final raise percentages in the Planner

Demo

Reorganized navigation for Pay Transparency in Workbench

We have reorganized the Workbench > Pay Transparency navigation into four functional categories: Documents, Communication Rounds, Document Templates, and Pay Information. Related configuration pages are now grouped within each category. For example, Pay Information brings together Pay Information Requests, Alerts & Anonymization, Mapping Configuration, and Document Generation in one place. Such an arrangement speeds up finding features and makes onboarding easier for new administrators. No existing functionality or configurations have changed.

New navigation in Workbench > Pay Transparency

Data Foundation

Data exports from the Data Viewer

Version 26.1 of the application allows the Data Foundation Admin, Configuration, or Support role to export data from Workbench > Data Management > Data Viewer to CSV files. This simplifies verifying what data was stored after ingestion, comparing it with the original source file, or preparing it for updates and re-ingestion. Moreover, it reduces the need to rely on manual checks or external tooling. Entities and enums can be exported from both list and detail views, and the export reflects the data visible to the user based on their current access scope and applied filters.

The Support role controls data export at tenant level in the Data foundation export section within Workbench > Data Management > Data Settings; when disabled, export options are not shown. With encryption enabled, users must provide a password to protect the exported file. When the export is ready, the browser starts the download automatically. Export actions are also recorded in an audit log. To request the log, users should contact the beqom support team.

Data export settings in Workbench > Data Management

Selecting entities and enums for export in the Data Viewer

Custom localization lifecycle management

This release enables users with the Configuration or Support role to manage the full lifecycle of custom label changes. In Workbench > Data Management > Localization > Custom Labeling, one or more languages can be selected for a reset, after which all labels in those languages revert to standard PaySuite values, eliminating manual restoration of individual entries. Each reset is saved automatically as a new version. The version history in the Language details drawer shows all versions from newest to oldest with the current version clearly marked, providing full visibility into what was changed, when, and by whom.

To restore a previous state, administrators select a version from the history and confirm the restore action. All labels in the language then take on the same values and type (Standard or Custom) as in the restored version, which makes it easy to recover from an incorrect CSV upload or accidental reset. Following either a reset or restore, the CSV download for that version reflects the applied custom label values.

Language reset in the Custom Labeling page

Version history and CSV download option for a custom label

Authorization

Professional roles CSV export and import improvements

Professional roles CSV files now work more reliably across regional settings and spreadsheet tools. Exported files include a UTF-8 BOM, ensuring non-English characters such as é, ü, ñ, ł, and ç display correctly when opened in Microsoft Excel. Both exports and imports now use the tenant-level CSV separator setting (comma or semicolon), replacing the previous workaround and making files easier to review, update, and re-import without formatting issues. Security group assignments are also consistently included in relevant CSV exports and subject-attribute responses so that they remain available for export and update scenarios.

Improved synchronization conflict diagnostics

We have improved synchronization and ingestion logs to provide clearer, actionable details when uniqueness conflicts prevent user creation or update. When a sync encounters a duplicate email or username, the log entry identifies the incoming ExternalId, the existing conflicting identity where it can be resolved, and the specific field and value that triggered the conflict. Such logs explicitly classify the issue as a unique constraint violation. The synchronization logs interface shows which worker was blocked and what caused the conflict, with information limited to the minimum necessary identifying data. Therefore, integration and support teams can diagnose failed syncs without direct database access, with structured, business-readable context replacing raw error messages.