The RRE (Reverse & Recovery Engine) finds eligible paid claims, copies them, reprices the copy under current contract logic, and releases it to Accounts Payable โ reversing the original only when the financial outcome actually changes.
Full traceability is preserved at every step โ nothing about the original paid claim is ever altered directly.
Before anything is copied, the engine checks each paid claim against eight independent safeguards. A single failed rule excludes the claim from the run entirely.
Claim has not already been reversed.
Claim isn't currently sitting in another workflow.
Provider on the claim is fully validated, not pending.
Claim belongs to a vendor configured for this process.
Claim has reached Paid status โ nothing earlier is touched.
Same-day claims are skipped to avoid processing incomplete records.
No claim or detail-line processing flag is currently present.
Claim and detail lines aren't already marked duplicate-in-process.
Each stage runs on its own, leaves its own audit note, and hands off cleanly to the next.
Once a claim clears every eligibility rule, the engine creates an exact duplicate โ held in a pending status โ and links it permanently back to the original, so nothing about the source claim is ever modified directly.
The repricing stage finds every claim copy waiting to be processed, then prices every detail line fresh โ clearing out old manual adjustments first so the repricing starts from a clean baseline, while the original contract assignment stays untouched.
Once pricing finishes successfully on the copied claim, it's released straight into the payment pipeline for processing โ with an audit note recorded documenting that the reprice stage is complete.
A final comparison checks the repriced copy against the original. If the financial outcome is different, the original paid claim is reversed using a standardized adjustment reason โ preserving the original for audit purposes while the corrected payment moves forward.
Every claim that enters the RRE engine follows the same traceable path. What happens at the end depends entirely on whether repricing actually changed the financial outcome.
Eligible ยท untouched ยท fully paid
Duplicates the claim, links it back to the original, and reprices every detail line under current contract logic.
Held separately, fully traceable to the original
Old adjustments cleared, lines repriced
Queued and sent into payment processing
Original claim stays exactly as it was. Repriced copy is simply on file, released for payment, audit note logged.
Original claim is formally reversed, so the corrected, repriced payment is the one that stands.
The result: current pricing logic gets applied retroactively, the original paid claim is never edited in place, and every step โ copy, reprice, release, reverse โ leaves its own dated note in the audit history.
The RRE engine turns a manual, claim-by-claim repricing chore into a background process that runs itself โ and leaves a clean audit trail behind it.
Nothing is ever edited on the paid claim directly โ the original is preserved for audit, every time.
Every repriced claim is linked straight back to its source, with no ambiguity.
Paid claims get the benefit of updated contract pricing without a single manual touch.
Copy, reprice, and reverse each log their own dated note automatically.
Don't reprocess paid claims by hand, one at a time, hoping nothing slips through. Let the engine find them, copy them, reprice them, and reverse only what actually changed โ with the audit trail built in from the first step.
Let's look at how paid claims move through your system today and show you what the RRE engine could automate โ without ever touching your original claim history.
Empowering healthcare and technology-driven organizations to achieve operational excellence through intelligent automation, advanced technology platforms, and strategic communications.
PO Box 1052