Guide

Retro-auth: the narrow windows and the magic words

Summary

Retroactive authorization is possible only in narrow circumstances: emergencies, coverage that wasn't confirmed until after the visit, or a documented payer or system error — and only within the window that payer's own policy sets, often a matter of days. Submitting after that window, or without the specific reason the request wasn't timely, gets an automatic denial. There is no universal retro-auth right; each payer's contract and published policy controls whether, and how long, the door stays open.

By Gale Editorial · Updated 2026-07-26. Every figure cited to a dated source. How we write.

What retroactive authorization actually means

retroactive authorization is a payer's after-the-fact review of a service that normally needed approval before it happened — not a second, slower path to the same approval. Every major commercial payer treats it as a narrow exception granted case by case, never a routine option. Anthem, Aetna, UnitedHealthcare, and Cigna each publish their own retro-review policy on their provider portals 1Ref 1Anthem (2026).Anthem Provider Policies.Anthem's own published retroactive-review policy on its provider portal, cited as one named payer example, not as universal payer practice.2Ref 2Aetna (2026).Aetna Clinical Policy Bulletins.Aetna's own published clinical policy bulletins covering its retroactive-review process, cited as a second named payer example.3Ref 3UnitedHealthcare (2026).UnitedHealthcare Policies and Protocols.UnitedHealthcare's own published policies and protocols covering retroactive authorization review, cited as a third named payer example.4Ref 4Cigna (2026).Cigna Coverage and Claims Policies.Cigna's own published coverage and claims policies covering retroactive review, cited as a fourth named payer example., and none guarantees a yes.

Prior authorization is a condition of payment, not a courtesy step: skip it with no exception in play, and the claim denies for that reason alone, whatever the medical record shows. That is a different problem from mixing up auth vs referral — a missing referral has its own cure and its own clock, and confusing the two wastes the narrow window a genuine retro-auth exception gives you.

The resistance is structural, not personal: retro review breaks the sequencing a payer relies on to manage utilization before the cost is incurred, so most policies evaluate a retro request against the same medical-necessity standard as an advance request, plus proof of why it couldn't have been submitted on time.

The three windows that actually open

Retro-auth reviews cluster around three situations, and a request outside all three is close to a guaranteed denial. The first is a true emergency or urgent service, where care happened before there was time to call. The second is coverage the practice could not have known about at the time — retroactive eligibility, a plan enrollment that processed late. The third is a documented payer error.

Emergency or urgent care: an unplanned admission or a same-day procedure ordered with no time to request authorization first. Most payer policies set a short post-service submission window — commonly measured in hours to a few days — and it's payer- and plan-specific; your contract controls the exact number.
Late-discovered eligibility: retroactive Medicaid eligibility, a coverage effective date that posts after the visit, or coordination-of-benefits that resolves after the claim was already filed.
Payer or system error: a portal outage at submission time, a representative's documented confirmation that authorization wasn't required, or an authorization number that was issued but never attached to the claim.

Situation	What proves it	Where the window lives
Emergency/urgent care	Time-stamped admission or triage note	The payer's own retro-review policy, not a fixed industry number
Late-discovered eligibility	Eligibility system printout showing the posting date	Same — check before assuming a standard window
Payer/system error	Portal outage log, or the rep's name, date, and reference number	Same

The documentation that gets a request reviewed, not auto-denied

A retro-auth submission that gets reviewed names the exact exception, not a general apology for missing the deadline. It states the date and time of service, the specific triggering event — the admission time, the eligibility posting date, the representative's name and the date they gave incorrect information — and attaches the chart note establishing medical necessity. A submission that only says the deadline was missed reads as a late request, not an exception, and gets denied on sight.

name the specific exception, not the missed deadline. Check the payer's own retro-review policy before submitting rather than guessing at the window — Anthem, Aetna, UnitedHealthcare, and Cigna each post theirs on their provider portal 1Ref 1Anthem (2026).Anthem Provider Policies.Anthem's own published retroactive-review policy on its provider portal, cited as one named payer example, not as universal payer practice.2Ref 2Aetna (2026).Aetna Clinical Policy Bulletins.Aetna's own published clinical policy bulletins covering its retroactive-review process, cited as a second named payer example.3Ref 3UnitedHealthcare (2026).UnitedHealthcare Policies and Protocols.UnitedHealthcare's own published policies and protocols covering retroactive authorization review, cited as a third named payer example.4Ref 4Cigna (2026).Cigna Coverage and Claims Policies.Cigna's own published coverage and claims policies covering retroactive review, cited as a fourth named payer example., and the window and required form differ by payer and by plan. Keep a copy of what the portal actually said on the day you checked it; policies get updated, and "the portal used to say" doesn't survive a peer-to-peer review.

Original Medicare, Medicare Advantage, and the ABN alternative

Does original Medicare require prior authorization at all? Mostly no — most physician services never needed it, and the short list that does is published, not assumed. When original Medicare might not cover a service, the tool is the Advance Beneficiary Notice, not a retro-auth request: it shifts financial responsibility to the patient in advance, and its rules live in CMS's Beneficiary Notices Initiative 5Ref 5Centers for Medicare & Medicaid Services (2026).Beneficiary Notices Initiative (BNI).That the Advance Beneficiary Notice, not a retro-auth request, is the mechanism for shifting financial responsibility when original Medicare may not cover a service..

Medicare Advantage plans are a different animal: they run their own authorization programs on top of Medicare's coverage rules, and when a documentation question needs an answer, the underlying coverage rule usually lives in a Local Coverage Determination searchable in CMS's Medicare Coverage Database 6Ref 6Centers for Medicare & Medicaid Services (2026).Medicare Coverage Database (MCD) Search.The lookup method — CMS's Medicare Coverage Database — for the Local Coverage Determination that defines a service's Medicare documentation requirements., not in the plan's guidelines alone. If the ABN was never obtained and the service is later found non-covered, that liability can shift back onto the practice — a separate problem from retro-auth entirely, and one worth tracking on its own checklist.

Reading the denial when retro-auth is refused

A retro-auth denial usually lands as CARC 197 — X12's standard code for an absent precertification, authorization, or notification on the remittance advice 7Ref 7X12 (2026).Claim Adjustment Reason Codes.That CARC 197 is the standard code identifying an absent precertification, authorization, or notification on a remittance advice.. That code alone doesn't tell you whether the payer never received a request or received one and rejected it on the merits; the remittance's remark code and the portal's case notes do. A CARC never travels alone — the remittance also carries a remark code with the specific reason, and that pairing is what a peer-to-peer call or a written appeal actually responds to, not the three-digit CARC by itself.

Route the claim into your denials and appeals workflow rather than resubmitting the same request unchanged. If an authorization number was on file and the claim still denied, that's a narrower problem — see authorized but denied for the specific codes and fixes.

Building prior auth as a solo so retro requests become rare

The cheapest fix for retro-auth is not needing it. Confirming eligibility and the authorization requirement before the visit is scheduled — not the morning of — closes the window that turns a routine visit into a retro-auth scramble. Running prior auth as a solo means the check happens at booking, gets logged with a name, date, and reference number, and the visit doesn't go on the calendar until the answer comes back.

Build the check into the same call or portal query that confirms benefits, and log which authorization was required, the number issued, and the name of the rep who gave it. That log is what turns a denied claim into a two-minute reversal instead of a resubmission — and it's the same record a retro-auth request would need anyway if the window ever closes on you.

Common questions

No. Retro-review is a discretionary exception in most payer policies, not a guaranteed second path — some contracts allow it only for emergencies, others add coverage-timing errors, and a few offer none at all outside a documented payer mistake. The only reliable way to know is checking that specific payer's published policy before assuming the request will be considered.

There's no single number — the window is set by each payer's own policy and can run from a day or two to a few weeks depending on the plan and the exception claimed. Confirm the current window on the payer's provider portal before submitting, since policies change and a stale number is treated the same as no window at all.

Document the call immediately — date, time, representative's name or ID, and exactly what was said — and attach that record to the retro-auth request as the specific reason it wasn't submitted in advance. A verbal confirmation with no record behind it is much harder for a payer to honor once the claim is already denied.

Original Medicare requires prior authorization for a short, published list of services; outside that list there's nothing to authorize before or after. When a covered-but-uncertain service is at issue, the operative tool is the Advance Beneficiary Notice, signed before the service, not a retroactive request. Medicare Advantage plans run separate authorization rules set by the plan.

The claim denies with a code identifying the absent authorization, and the practice's options are the same as any other denial: appeal within the payer's stated window with the documentation the retro request should have included, or write the balance off if the exception genuinely doesn't apply. A denied retro request isn't the end of the appeal path — it's the start of it.

Run your practice on Gale

The software is free. Gale earns one flat 3.5% all-in per paid transaction — only on transactions that actually pay. No subscription, no setup fee, no network cut.

Start or manage a practice →

References

1.Anthem (2026). Anthem Provider Policies. Anthem provider portal. link ✓Anthem's own published retroactive-review policy on its provider portal, cited as one named payer example, not as universal payer practice.
2.Aetna (2026). Aetna Clinical Policy Bulletins. Aetna provider portal. link ✓Aetna's own published clinical policy bulletins covering its retroactive-review process, cited as a second named payer example.
3.UnitedHealthcare (2026). UnitedHealthcare Policies and Protocols. UnitedHealthcare provider portal. link ✓UnitedHealthcare's own published policies and protocols covering retroactive authorization review, cited as a third named payer example.
4.Cigna (2026). Cigna Coverage and Claims Policies. Cigna provider portal. link ✓Cigna's own published coverage and claims policies covering retroactive review, cited as a fourth named payer example.
5.Centers for Medicare & Medicaid Services (2026). Beneficiary Notices Initiative (BNI). Centers for Medicare & Medicaid Services (CMS). link ✓That the Advance Beneficiary Notice, not a retro-auth request, is the mechanism for shifting financial responsibility when original Medicare may not cover a service.
6.Centers for Medicare & Medicaid Services (2026). Medicare Coverage Database (MCD) Search. Centers for Medicare & Medicaid Services (CMS). link ✓The lookup method — CMS's Medicare Coverage Database — for the Local Coverage Determination that defines a service's Medicare documentation requirements.
7.X12 (2026). Claim Adjustment Reason Codes. X12. link ✓That CARC 197 is the standard code identifying an absent precertification, authorization, or notification on a remittance advice.

https://www.gale.care/for-providers/va-retro-authorization · 7 sources. Competitor details are cited to dated public sources and maintained as they change; figures are estimates, not commitments. Synthetic demonstration.

← Back to for providers