The admin workbench that puts what the plan expected, what payroll collected, what was sent to the carrier and what the carrier billed side by side — then records the fix as a resolution, a note, a follow-up or a clarification package.
BR Reconcile is the reconciliation workbench of Benefits Reimagined. It does not run the matching itself: Integration Center has already matched the vendor file sent to the carrier against the carrier's invoice, and BR ReVerge has already compared expected enrollment cost against the deductions payroll collected. The workbench merges both results into one seven-section row per member, plan and month, labels it Matched or Variance, and gives the benefits operations administrator the tools to close it — a resolution written on the source record, notes, a tracked follow-up with an SLA, or a PDF, Excel or CSV package for the carrier or payroll contact. Nothing on this screen creates a new match.
"Traditional reconciliation is a two-way spot check done in a spreadsheet — enrollment against the carrier bill, once a quarter, by whoever has time. It misses the deductions that never started, the terminations the carrier never applied, and the changes that were sent but never confirmed. Benefits Reimagined changes the approach: the vendor-file match and the payroll match are run by their own engines, and one workbench lays all four sides on a single row per member and month — so the administrator's job is to decide, record and follow up, never to re-key or re-match."
Follow September's medical plan from the two engines that matched it, through the seven-section grid, to the resolutions, follow-ups and clarification package that close it — exactly as the screens are worked.
Two engines do the comparing before anyone opens this screen. Integration Center matches the vendor file Benefits Reimagined sent to the carrier against the carrier's invoice lines, scenario by scenario — exact match, within tolerance, timing, proration, retro, missing line, extra line, and plan, amount or date mismatch — using an amount tolerance from the reconciliation tolerance configuration that defaults to one cent. BR ReVerge compares the enrollment cost the plan master expected with the deductions payroll actually collected. Each engine writes its own result record with a match status of Matched, Mismatched or Unmatched. The workbench merges the two for a tax year, month and carrier into one grid, so the administrator sees both verdicts on the same member without opening either engine.
A reconciliation screen that also re-matches is a screen nobody can audit — here the match and the decision are two different records.
Loading the vendor file and the invoice, and running the match, are Integration Center operator steps; the payroll comparison is a BR ReVerge operator step. Neither is done from this workbench.
The Reconciliation View opens on a tax year, then narrows by month, carrier, plan, status and a search term. Each row is grouped under seven headers: Enrollment (the plan master's expected amount), Payroll (the deduction collected), the Enrollment and Payroll reconciliation result, the Expected Result the company should send or receive after the payroll side, the Vendor Invoice lines, the Expected Result and Vendor Invoice reconciliation result, and the Invoice versus Payroll difference — the gap between what payroll collected and what the carrier billed. Double-clicking the totals row expands every section. The grid for a filter is built once and kept for about three hours so paging is instant; a search term always reads live rows. The toolbar opens the Overview, the notes drawer, the follow-ups page pre-filtered to the selected rows, and the Resolve modal.
The administrator sees the payroll verdict and the carrier verdict on the same line — a variance that is really a timing difference between the two is obvious at a glance.
The seventh section is the one no two-way check can show: what payroll took from the employee against what the carrier charged the employer.
Resolve opens a modal on the selected row. The administrator does not choose which system the variance belongs to — the row is looked up on both the vendor-side and the payroll-side result records, and the modal offers the methods that fit. A vendor-side variance can be recorded as a vendor correction, our correction, a credit memo, or accepted as is. A payroll-side variance can be recorded as direct billing, a credit memo, a pay distribution, our correction, a payroll correction, or accepted as is. Imputed income is resolved on its own, separately from the premium variance. Choosing direct billing can open a direct-billing case; pay distribution reads the applicable distribution configurations; a payroll-side credit memo writes a payroll credit memo, which is a different object from the carrier's credit note. The method and the outcome are recorded on the source record — the match is never re-run.
"Accepted as is" is a recorded decision with a name on it — not a row that simply stopped being looked at.
Two credit memos exist for good reason: a vendor credit note adjusts the carrier\'s invoice; a payroll credit memo adjusts what the employee is owed.
A variance that needs someone outside the room becomes a follow-up: a tracked case linked to one or more reconciliation rows, with the systems it touches, a note thread, a status history, and a priority that sets the SLA — three days for high, five for medium, seven for anything else. Whether the case is a vendor follow-up or a payroll follow-up is inferred from the row it came from. The Follow-ups page shows three lanes — the module filter (Integration Center, BR ReVerge or all), the active cases, and the mismatches already resolved — so an administrator can select rows from either and generate a clarification package: a PDF, Excel or CSV of the selected mismatches with the request metadata stored beside it. The package is a document for the carrier or the payroll contact; it does not post a correction anywhere.
A carrier query that lives in someone\'s inbox has no SLA; a follow-up has one, an owner and a status history.
The package is evidence, not an instruction — the correction itself is recorded as a resolution once the carrier or payroll has acted.
The workbench never sees a vendor system name. The enrollment side is the plan master inside Benefits Reimagined, fed from whichever HRIS the entity runs through HRIS Sync. The payroll side is whatever payroll BR ReVerge transmits to and receives from — ADP, Workday, UKG, Dayforce, Paycom, SAP Employee Central Payroll or another 3rd-party system — registered once in the payroll system configuration. The sent file and the invoice are whatever Integration Center exchanged with the carrier, in the carrier's format, mapped once with IntelliMap. Because each engine writes its result in the same shape, the seven-section row, the resolution methods, the follow-ups and the packages are identical for every entity in the tenant.
An acquired entity on another HRIS and another payroll reconciles in the same grid on day one — not in a second spreadsheet.
Enrollment, payroll and carrier are chosen independently: a Workday HRIS, an ADP payroll and a BCBS invoice reconcile on the same row as any other combination.
Three screens in one sidebar — Dashboard, Reconciliation View and Follow-ups — plus an Overview reached from the toolbar, each mapped to the records it reads and writes, on the match results the platform's own engines produce.
Reads the vendor-side result from Integration Center (sent file versus invoice, scenarios from exact match to plan, amount and date mismatch, tolerance from configuration) and the payroll-side result from BR ReVerge (expected versus collected), merged per tax year, month and carrier.
Enrollment, Payroll, their reconciliation, the expected result, the vendor invoice, its reconciliation, and the invoice-versus-payroll difference — filtered by year, month, carrier, plan, status and search, labelled Matched or Variance with the absolute amount.
The row's origin is detected, not chosen; vendor-side rows offer vendor correction, our correction, credit memo and accepted as is; payroll-side rows add direct billing, pay distribution and payroll correction; imputed income is resolved separately; the decision is written on the source record.
Tracked cases linked to reconciliation rows, with system impacts, a note thread, a status history and an SLA set by priority — three, five or seven days — shown in module, active and resolved-mismatch lanes.
Selected mismatches — from follow-ups first, then from resolved rows — generated as a PDF, Excel or CSV for the carrier or payroll contact, with the request metadata stored beside the document.
A year picker with summary KPIs computed from the year's rows, carrier distribution, invoice periods, the follow-ups list, a self-insured table and a summary; the Overview route or modal gives carrier and period totals for the current filter.
The workbench is worked in three recognisable sequences — the month-end read, the variance decided on its source, and the carrier query packaged and tracked. Each starts where the engines left off and ends with a record someone can reopen.
Sequences from the workbench's working flow · the dashboard's year KPIs, carrier distribution, invoice periods, follow-ups and self-insured table are live; trend charts on the dashboard are not marketed here.
Most reconciliation compares one pair of sources in a workbook and leaves the decision in an email. Here is what changes when all four sides sit on one row and every decision is a record.
| Moment | Two-way spreadsheet check | BR 4-Way Reconciliation |
|---|---|---|
| What is compared | Enrollment against the carrier bill, or payroll against the bill — one pair at a time. | Four sides on one row — expected, collected, sent and billed — with both engine verdicts and the invoice-versus-payroll gap. |
| Who does the matching | The analyst, with lookups, at month end. | Integration Center and BR ReVerge, scenario by scenario, against configured tolerances — before the workbench opens. |
| A variance is found | A cell is highlighted; what happened next lives in an email. | Resolve on the source record with a method that fits the side — vendor correction, payroll correction, direct billing, credit memo, accepted as is. |
| The carrier has to answer | A forwarded spreadsheet and a reminder in two weeks. | A follow-up with an SLA and a clarification package in PDF, Excel or CSV, with the request recorded. |
| Payroll took the wrong amount | Noticed when the employee asks. | Section 7 shows it — collected against billed — and the payroll-side methods route it to a correction, a spread or a bill. |
| Reopening last quarter | Find the workbook, find the version, find the person. | Pick the year and month — the rows, the resolutions, the notes and the packages are still there. |
| A second carrier, payroll or HRIS | A second workbook with its own logic. | The same grid — the engines write one result shape whatever they read. |
The Athena administrator assistant answers questions from the same records the grid shows — which side a variance came from, which scenario the vendor match fired, what the payroll side collected, which follow-ups are past their SLA. Athena explains and points to the row or the case; it does not resolve, create follow-ups or generate packages. Those remain administrator actions on their own screens.
Expected, collected, sent and billed for one member and month — the timing difference between payroll and carrier stops looking like an error.
The engines match; the workbench decides. An auditor can read the verdict and the decision as two records with two authors.
Vendor-side and payroll-side variances get the methods that fit them, and a direct-billing or pay-distribution outcome hands off to the module that executes it.
A follow-up has a priority, an SLA, an owner and a status history — the carrier query cannot quietly age in an inbox.
A clarification package is the selected mismatches as PDF, Excel or CSV, with the request on file — the same rows the administrator resolved.
Every month's rows, resolutions, notes, follow-ups and packages stay under the tax year they belong to.
4-Way Reconciliation is built for organizations with many carriers, several payrolls and more than one HRIS. The engines run under their own operators, the workbench is read-and-decide, and every decision, note, case and package is a record under the tax year it belongs to — so the same controls hold at any scale.
Bring one month of one carrier — the file you sent, the invoice that came back, and the payroll register — to a demo. We will show the two engines' verdicts on the same row, resolve a vendor-side and a payroll-side variance, open a follow-up and generate the clarification package — on the screens your team would use.
Checking the four amounts that should agree for every member and month — what enrollment expected, what payroll collected, what was sent to the carrier, and what the carrier billed — on one row. In Benefits Reimagined two engines do the comparing: Integration Center matches the sent file against the invoice and BR ReVerge matches expected against collected. The 4-Way Reconciliation workbench reads both results, shows them in seven sections, and records the decision.
No. Loading the vendor file and the invoice and running the match are Integration Center operator steps, with scenarios from exact match and tolerance through timing, proration, retro, missing and extra lines to plan, amount and date mismatches; comparing expected enrollment cost with the payroll deductions collected is a BR ReVerge step. The workbench merges the two results for a tax year, month and carrier. Resolving a row never re-runs a match.
Enrollment (the plan master's expected amount); Payroll (the deduction collected); the Enrollment and Payroll reconciliation result; the Expected Result the company should send or receive after the payroll side; the Vendor Invoice lines; the Expected Result and Vendor Invoice reconciliation result; and the Invoice versus Payroll difference. Each row carries a workbench status of Matched or Variance, the engine's Matched, Mismatched or Unmatched status, and the absolute variance amount.
From the Resolve modal on the row. The row's source is detected by looking it up on both engines' results, and the modal offers the methods for that side — vendor correction, our correction, credit memo or accepted as is for a vendor-side variance; direct billing, credit memo, pay distribution, our correction, payroll correction or accepted as is for a payroll-side one. Imputed income is resolved separately from the premium. The method, outcome and notes are written on the source record; direct billing can open a case, pay distribution reads the distribution configurations, and a payroll-side credit memo is a payroll credit memo, not the carrier's credit note.
A follow-up is a tracked case linked to one or more rows, with the systems it affects, a note thread, a status history and an SLA set by priority — three days for high, five for medium, seven otherwise. Its statuses run New, Pending, In progress, Waiting external, Review and Closed; resolved, partial and denied cases stay in the active lane until closed. A clarification package takes the mismatches the administrator selects — from follow-ups first, then from resolved rows — and generates a PDF, Excel or CSV with the request recorded. The package is a document; it does not post a correction to the carrier or to payroll.
For a chosen tax year: summary KPIs computed from that year's rows, a carrier distribution, an invoice-periods table, the follow-ups list, a self-insured table and a summary. The Overview — reached from the Reconciliation View's toolbar as a route or a modal, not from the sidebar — gives carrier and period totals for the current filter. Trend charts are not part of the live dashboard today.
Any. The enrollment side comes from the plan master, fed from whichever HRIS the entity runs through HRIS Sync; the payroll side comes from whichever 3rd-party payroll BR ReVerge transmits to and receives from — ADP, Workday, UKG, Dayforce, Paycom, SAP Employee Central Payroll or another system; the sent file and the invoice are whatever Integration Center exchanged with the carrier, mapped once with IntelliMap. Because each engine writes its result in one shape, the grid, the methods, the follow-ups and the packages are the same for every entity in the tenant.
Turn month-end reconciliation from a two-way spreadsheet into a workbench that reads both engines, records every decision on its source, and tracks every carrier question to an SLA.