Retrospective review

What retrospective review is

Retrospective review is a post-service evaluation by a payer or utilization management vendor that happens after care is delivered, and often after a claim has been submitted or even paid. The reviewer compares the documented services against the member's benefits, medical-necessity criteria, and prior-authorization rules.

In behavioral health, retrospective review is usually triggered by high-cost episodes, long lengths of stay, out-of-network treatment, or random audit programs. Reviewers often request full clinical records, treatment plans, notes, and any prior-authorization or concurrent-review documentation.

Why retrospective review matters operationally

Retrospective review affects both cash timing and audit risk. A claim that looks clean on the 835 can be pulled months later, then partially or fully recouped if the payer decides services were not medically necessary, not at the documented level of care, or beyond the approved authorization span.

For revenue cycle, this shows up as:

• New denials or takebacks, often with CO-50 or CO-197
• Payment holds on current claims until records are supplied
• Recoupments taken from unrelated future payments
• Staff time diverted to compile records and write appeals

A single large residential or PHP case that fails retrospective review can wipe out tens of thousands of dollars in revenue and distort your days in AR, denial-rate, and net collection reporting. Good process treats retrospective review as an ongoing utilization management and documentation discipline, not a one-off fire drill when a records request hits the fax.

How retrospective review is used and what to look for

Payers use retrospective review to validate:

• Medical necessity against internal criteria, ASAM, or other level-of-care criteria
• Correct level of care across dates of service, for example, PHP vs IOP vs outpatient
• Consistency between billed units and documented time or services
• Compliance with prior-authorization, concurrent-review, and authorization-span rules

Operationally, watch for:

• Source: Who is requesting the review (payer, carve-out vendor, state UM contractor)
• Scope: Specific dates of service, levels of care, or CPT/HCPCS codes in question
• Timeframes: Deadlines to submit records and respond to adverse findings
• Outcomes: Payment upheld, reduced, fully denied, or recouped

Patterns in retrospective review outcomes should feed back into your front-end processes. If reviewers repeatedly downgrade days 21+ of residential to IOP or outpatient, that is a signal to tighten concurrent-review workflows, clinical documentation, and medical-necessity narratives before the claim ever goes out.

• Treating retrospective review as a pure clinical issue and not looping in RCM, so the team does not understand that a 30-day residential stay is at risk for CO-50 takebacks on days 16-30 if medical necessity is weak.
• Submitting records piecemeal in response to a payer request, which leads reviewers to conclude services were not supported for certain days or units, even though the documentation existed in another part of the chart.
• Assuming a prior authorization guarantees payment for the entire stay, instead of tracking that the payer can still deny or downgrade late days during retrospective review for failing level-of-care criteria.
• Ignoring early warning signs in 835s, such as recurring CO-197 or N130 remark codes on a subset of claims, which often foreshadow broader retrospective audits of similar cases.
• Letting clinicians copy-forward treatment plans and notes in long residential or IOP episodes, which gives reviewers an easy argument that care was custodial or not actively treating a mental health or SUD diagnosis.

Behavioral health is heavily exposed to retrospective review because episodes are long, per-diem rates are high, and medical necessity is subjective. Residential, PHP, IOP, and withdrawal management stays are prime targets, especially when billed out-of-network or at a higher ASAM level than the payer expects.

Carve-out behavioral health vendors and Medicaid managed care plans often run aggressive post-payment reviews on SUD and residential claims. They may apply their own level-of-care criteria, not just ASAM, and retroactively decide that parts of a stay should have been a lower level or non-covered, which drives CO-50 denials and recoupments months after payment.

Concurrent authorization does not fully protect longer behavioral health episodes. Many state Medicaid and MCO contracts allow the plan to re-review days that were initially approved, then retroactively deny days past a certain clinical milestone. Facilities that do not align documentation and treatment-plan updates to those milestones can see large blocks of per-diem days reversed in a single audit.

For treatment centers, tight coordination between utilization review, clinical leadership, and billing is non-negotiable. Proactive use of level-of-care criteria, clear documentation of risk and functional impairment, and timely updates in notes and treatment plans are often the difference between getting paid for day 45 of residential and eating a full recoupment in the next remittance cycle.

AI can help with retrospective review by tracking patterns across claims, records requests, and 835 remittances to flag where you are at risk. An agent can watch for clusters of CO-50 and CO-197 codes tied to specific levels of care, payers, or lengths of stay, then surface cases that are likely audit targets so UR and clinical teams can tighten documentation before a records request lands.

Supabill's denials agent reads every 835, classifies CARC and RARC patterns, and can tag episodes where payers are starting to downgrade or partially deny days in a way that often precedes broader retrospective reviews. A benefits and authorization-focused agent can also hold payer-specific rules about when retrospective or retroactive authorization is possible and what documentation is required. Humans still have to interpret detailed clinical narratives, decide what records to send, negotiate during peer-to-peer or reconsiderations, and set risk tolerance when a payer demands large recoupments.

Is retrospective review the same as concurrent review?

No. Concurrent review happens during an active stay and focuses on approving the next block of days or units, while retrospective review happens after services are rendered and often after claims are paid. Both look at medical necessity, but retrospective review can lead to recoupments on historical claims.

Can a payer take back money after paying claims if a retrospective review fails?

Yes. Most payer contracts and plan documents allow recoupment when post-payment review finds lack of medical necessity, incorrect level of care, or non-compliance with authorization rules. The recoupment often appears as a negative adjustment on future remittances rather than a refund request.

Does having a prior authorization prevent denials from retrospective review?

Prior authorization lowers the risk but does not guarantee payment. Payers can still argue that certain days or services did not meet continued-stay criteria, were not documented adequately, or differed from what was authorized. Strong ongoing documentation and timely concurrent reviews are still required.

How much time does a payer have to conduct retrospective review?

Time limits are usually set in payer contracts, provider manuals, or state regulations, and can range from months to several years. Behavioral health providers should review each major payer agreement and applicable state law so they know how far back retrospective reviews and recoupments can reach.

What should a behavioral health facility send for a retrospective review request?

Send exactly what is requested plus any additional pieces that clearly support medical necessity and level of care, such as admission assessments, progress notes, treatment plans, medication records, discharge summaries, and prior-authorization or concurrent-review decisions. Keep the packet organized, indexed, and complete to avoid partial denials due to missing documentation.

• CMS: Internet-Only Manuals (IOMs)