Calculate the retro, lock the run, transmit it to your 3rd-party payroll, and prove what payroll collected — one governed pipeline for late benefit changes.
BR ReVerge is the retroactive benefits correction module of Benefits Reimagined, built for benefits and payroll administrators. A run reads current health and insurance enrollments, compares them with what was already calculated for each pay period, and writes the retro lines — the retro payroll deductions and employer contributions for every period affected. Payroll locks and reviews the run, transmits it to the 3rd-party payroll, and the reconciliation engine compares what was expected with what payroll actually collected — with every mismatch resolved or followed up by a named person.
"Traditional retroactive benefits processes rely on spreadsheets, manual overrides, and last-minute payroll fixes. This creates inconsistency, employee dissatisfaction, and compliance risk when late enrollments or backdated life events occur. Without governed controls, retro deductions become unpredictable and hard to explain. Benefits Reimagined changes this by embedding retroactive benefits management directly into a structured system. BR ReVerge introduces standardized logic, approval controls, and payroll-aligned calculations to keep retro corrections accurate and defensible."
Follow one payroll period through the module exactly as an administrator clicks it — from the Execute Schema stepper to the reconciliation grid. Each stage has a gate the previous stage must pass.
Execute Schema is one guided form. The administrator picks a run type and payroll window, chooses who is in scope, switches on the plan categories, records notification and audit preferences, and reviews readiness before pressing Run. Preflight checks — a production run that already exists for the period, a prior simulation, a missing prior period or prior year — open in a modal with blocking issues and warnings separated, so nothing runs on a period that is not ready.
The run cannot start until every required step is valid, and the administrator sees the forecast before the engine writes a line.
A prior run's settings can be applied with one click, so a monthly production run is never re-keyed — and a bad run is fixed as a linked Correction run, never by editing lines.
Every run lands in Executed Schemas with metric tiles, quick views and a filterable table. While a run is still in progress the row is guarded: lock, transmit, pay-distribution approval and delete stay disabled until it completes. From the row the benefits administrator opens execution details, filters the employee results, and drills into one person to see the retroactive impact by wage type, the for-period and in-period of each amount, how a spread was applied, and the ACA and Section 125 checks. Only when that review is accepted does payroll lock the run.
A run that has not been opened and accepted by benefits never reaches payroll's review list.
Run history keeps every execution of the schema, so a re-run is compared with its predecessor, not with memory.
The Review list shows locked runs and nothing else. Payroll confirms a run and presses Transmit on the row; BR sends the lines whose in-period is this run's payroll period, with the change and retro flags, to the 3rd-party payroll over the configured integration service. Transmission details show every employee's status, the request and response, the cumulative and benefit-table panels, and a per-employee transmit for the one person whose record failed. A failed transmission leaves the run on Review with a clear message — the administrator never has to assume payroll received data.
Payroll sends what benefits has accepted and payroll has locked — nothing else can reach payroll from this module.
Employee IDs are mapped to the payroll system's personnel numbers before transmit, so the line lands on the right person — and a transmit is only possible once the run is completed.
After payroll runs, the 3rd-party payroll or the middleware posts the results back into BR — payroll cumulatives and the benefit table, including claims cumulatives — through an inbound receive service. The benefits payroll reconciliation engine compares the amounts BR expected for each employee, plan and period with the amounts payroll actually collected, employee and employer side, within the tolerance set in payroll system configuration. Matched lines close themselves. A variance is resolved with a method and notes, or opened as a follow-up for the reconciliation coordinator, with a clarification package when payroll needs the evidence bundled.
The retro is not finished when it is sent; it is finished when payroll's own figures agree with BR's.
Filters can arrive from the platform-wide reconciliation workspace, so a carrier-side finding opens the matching payroll-side line; a resolution can also link to a direct-billing case, a credit memo or an adjustment.
The engine reads enrollments from Benefits Reimagined and pay areas and periods from the payroll system, and its output is a set of dated, in-period lines by wage type — the same shape whether the receiving payroll is ADP, Workday, UKG, Dayforce, Paycom, SAP Employee Central Payroll or another 3rd-party system. Each payroll is registered once in the payroll system configuration with its endpoint, credentials, employee identifier mapping, proration, rounding and tolerance; the HRIS Sync control plane carries the locked run's lines out and the collected amounts back in, with IntelliMap shortening the mapping. The run, the lock, the review and the reconciliation grid are the same screens for every payroll in the tenant.
An acquisition on a different payroll should not mean a second retro process and a second spreadsheet.
Enrollment data itself can come from any HRIS through HRIS Sync, so the payroll side and the HRIS side are chosen independently — a Workday HRIS with ADP payroll runs the same retro as any other pairing.
Six capability areas, each mapped to a screen an administrator actually works in — and all of them reading the same enrollments, payroll areas and periods as the rest of Benefits Reimagined.
Reads current health and insurance enrollments, compares them with the prior calculated rows for each pay period, and writes retro lines with the for-period the money belongs to and the in-period it posts in — employee and employer amounts by wage type, with proration, rounding and the retro back-period from configuration, and a prior-year row required unless hire dates exempt the employee.
Simulation to rehearse a period without commit, Production for the real run, Correction linked to an earlier run, and Delta for the employees a cutoff missed with a cutoff date each — plus clone-and-apply so a monthly run keeps its settings.
AI Cohorts with live counts — mid-year plan rate change, back-dated life events, recent life events — or the shared Employee Selection with organisational and named-employee filters; when the population is large the run is scheduled as a batch with visible progress.
Completed runs are locked by payroll, listed on Review, and transmitted to the 3rd-party payroll over the configured integration service — with transmission details, a per-employee transmit, retry for failed items and a full request-and-response log for every attempt.
Rules decide whether a retro is spread across periods, taken once, or billed directly; spreads over the configured amount go to the BR WorkFlow inbox for approval, and every applied spread is written to a distribution log.
An inbound receive service stores payroll cumulatives and the benefit table; the reconciliation engine compares expected with collected within tolerance, and each variance is resolved with notes or opened as a follow-up with a clarification package.
Most retroactive deductions are still worked out in a spreadsheet and keyed into payroll, or left to the payroll system's own retro accounting with no benefits-side check. Here is what changes when the retro is a governed run.
| Moment | Spreadsheet or payroll-only retro | BR ReVerge |
|---|---|---|
| Finding who needs a retro | Someone remembers the late life events, or payroll notices a difference after the fact. | AI cohorts with live counts — mid-year rate change, back-dated and recent life events — or a governed employee selection. |
| Working out the amount | A formula in a workbook, re-typed per person, with no record of the prior deduction it was compared to. | The engine compares current enrollment with the prior calculated row for each period and writes for-period and in-period lines by wage type. |
| Trying it first | There is no dry run; the first time you see the numbers is on the payroll register. | A Simulation run with the same targeting, no commit, and a preflight modal that separates blocking issues from warnings. |
| Getting it into payroll | Manual entry or a file someone builds, with no way to know what payroll accepted. | Locked runs transmitted to the 3rd-party payroll line by line, with a per-employee status, retry, and the request and response on file. |
| A large catch-up | Whatever the analyst decides that day; the employee finds out on payday. | Distribution rules — spread, one-time or direct bill — with WorkFlow approval above a configured amount and a distribution log. |
| A mistake in the run | Edit the cells, re-send, and hope the first version is not still in someone's inbox. | A Correction run linked to the original, or a Delta run for the people a cutoff missed — the first run stays in history. |
| Knowing it worked | Assumed, until an employee or an auditor says otherwise. | Expected versus collected from payroll's own cumulatives, within tolerance, with every variance resolved or assigned. |
| A second payroll after an acquisition | A second spreadsheet and a second person who knows how it works. | The same run, lock, review and grid — ADP, Workday, UKG, Dayforce, Paycom or any other payroll. |
The Athena assistant sits at the bottom of every BR ReVerge screen. Administrators ask why an employee shows No Retro, which locked runs are still waiting on payroll, or what the variance on a reconciliation line means — and get answers drawn from the run, its lines and the transmission log. Athena is a question-and-answer and query assistant: it explains, it does not execute. Runs start only from Review & Execute, transmits only from the Review list.
Late enrollments, back-dated life events and mid-year rate changes are found by the same run against the same prior rows — not by three spreadsheets and a memory.
A simulation run shows the retro population, amounts and preflight issues for a period with no commit, so the production run is a decision rather than a surprise.
Benefits runs and reviews; payroll locks and transmits; integration retries; reconciliation resolves — each on its own screen with its own module permissions.
Only lines posting in the run's payroll period are transmitted, with retro flags; for-periods stay on the record, so payroll never receives a line it cannot place.
A correction is a new run linked to the old one and a delta adds the people a cutoff missed — the original run is never edited and every version is in run history.
The period closes when payroll's own cumulatives agree with the expected amounts within tolerance — and every variance has a resolution note or an owner.
BR ReVerge is designed for organizations managing retroactive benefits at scale. Standardized rules ensure consistency across HR and payroll teams, while controlled workflows reduce operational risk. As organizations grow, retro benefits management remains predictable and compliant without adding manual overhead. This governance-first approach supports enterprise expansion while protecting payroll integrity.
Bring one payroll period with its late enrollments, back-dated life events and a mid-year rate change to a demo. We will run a simulation, lock and transmit a production run to a payroll sandbox of your choice, and reconcile what comes back — on the same screens your administrators would use.
Turn backdated changes from a payroll scramble into a governed run — targeted, simulated, locked, transmitted to your 3rd-party payroll and reconciled against what payroll actually collected.