Skip to main content
rcm.today

Operated by AdvancedCare USA Inc., which sells revenue cycle software and services. Our formulas and sources are published so you can check them.

Prior authorization: where auths actually fail

Most auth-related denials are not clinical disagreements — they are calendar, counter, and claim-field failures that were visible before the visit. This page walks the eligibility-to-claim flow, the failure modes that turn into CO-197-class denials, and the checklist that prevents them.

Last reviewed against published HFMA, CMS, MGMA, Premier, and related primary sources linked on this page on .

Direct answer

Prior authorization is a payer’s advance approval, before a service is rendered, that the service meets its coverage criteria. It is a condition of payment, not a guarantee of payment. The failure modes that cost practices money are overwhelmingly operational: no auth obtained for a service that required one (surfaces as reason code 197 — precertification/authorization absent), an authorization number missing or invalid on the claim (reason code 15, often riding with CO-16), an expired auth or a date of service outside the validity window, and units or visits beyond what was authorized (reason code 198). Prevention is a front-end discipline: verify before the visit, track validity windows, attach the auth number to the claim, and document medical necessity for the authorized service.

What prior authorization is (and is not)

Prior authorization — also called precertification or pre-approval depending on the payer — is a requirement that the provider obtain the payer’s agreement before certain services are rendered that the service will be covered. It sits on top of eligibility: a patient can be fully eligible, with active coverage, and the claim can still deny in full because the specific service needed an auth that was never obtained.

Three things it is not:

  • Not a referral. A referral routes the patient from one clinician to another (common in HMO designs). An auth is the payer’s coverage review. Some plans require both; confusing them produces unpaid claims even when the clinical routing was perfect.
  • Not a guarantee of payment. An approved auth establishes that the service met coverage criteria as presented. The claim can still deny for coding errors, duplicate submission, eligibility retro-termination, or timely filing. Treat an approval letter as one requirement cleared, not as money in the bank.
  • Not universal. Original (fee-for-service) Medicare requires prior authorization for only a short, published list of items and services — CMS maintains those programmes publicly (CMS prior authorization initiatives (opens in a new tab)). Medicare Advantage, Medicaid managed care, and commercial plans use auth far more aggressively, each on its own list.

Where it sits in the eligibility-to-claim flow

Auth work is a chain, and the failure modes map one-to-one onto the links:

  1. Scheduling / pre-registration. The appointment type and planned service are known. This is the cheapest point to catch an auth requirement.
  2. Eligibility verification. Coverage and benefit status are confirmed — over the HIPAA-adopted 270/271 eligibility transaction in most shops. The eligibility response plus the payer’s policy together answer “does this plan require auth for this service?”
  3. Auth request. Clinical and administrative documentation goes to the payer. The HIPAA-adopted standard transaction for this exchange is the X12 278 (health care services review — request and response), one of the adopted standards CMS maintains in its administrative-simplification materials (CMS adopted standards (opens in a new tab)). In practice, much of the industry still submits via payer portals and fax alongside the 278.
  4. Decision. Approval, denial, or pend for more information — with an authorization number, a validity window (start and end dates), and an authorized unit or visit count.
  5. Care delivery against the auth. Dates of service must fall inside the window; units consumed must stay inside the count; the rendering provider, place of service, and procedure must match what was authorized.
  6. Claim submission. The auth number travels on the claim — box 23 on the paper CMS-1500 per the NUCC instruction manual (opens in a new tab), the prior-authorization REF segment on the 837.
  7. Adjudication and remittance. When any link above failed, this is where you find out — as a denial with a reason code, weeks after the fixable moment passed.

The point of drawing the chain: links 1–4 are prevention; links 5–6 are hygiene; link 7 is the autopsy. Staffing the autopsy instead of the prevention is the most common structural mistake in auth management.

Why auths fail — the failure modes that become denials

  • No auth obtained at all

    How it happens
    Payer’s auth-required list not checked for this plan + service at scheduling
    How it surfaces on the remit
    Reason code 197 (precertification/authorization absent) on a zero-pay line
    Prevention owner
    Scheduling + clinical ops

  • Auth number missing or invalid on the claim

    How it happens
    Auth exists; charge entry never attached the number, or it landed in the wrong field
    How it surfaces on the remit
    Reason code 15 (authorization number missing/invalid/not applicable), often with CO-16
    Prevention owner
    Billing / charge entry

  • Expired auth or DOS outside the validity window

    How it happens
    Long episodes of care; the clinical calendar drifts past the auth’s end date
    How it surfaces on the remit
    Code 197-class denial with remarks on dates, or a policy denial letter
    Prevention owner
    Clinical ops (auth calendar)

  • Units or visits exceed the authorized count

    How it happens
    No live counter against the authorized block; re-auth triggered too late
    How it surfaces on the remit
    Reason code 198 (precertification/authorization exceeded) or 151 (info does not support this many services)
    Prevention owner
    Clinical ops (session counters)

  • Wrong procedure, provider, or place of service vs. the auth

    How it happens
    Authorized for one CPT/setting; rendered and billed differently (e.g. telehealth instead of office)
    How it surfaces on the remit
    Auth-mismatch remarks with 197-class or diagnosis/procedure (11) edits
    Prevention owner
    Coding + scheduling

  • Retroactive denial after payment

    How it happens
    Payer re-reviews medical necessity or eligibility post-payment and recoups
    How it surfaces on the remit
    Takeback / recoupment on a later remittance
    Prevention owner
    UM + billing (appeal capacity)

Reason code descriptions are paraphrased from the X12 Claim Adjustment Reason Code list (source below) as of this page’s review date. Group codes on your remit (CO vs PR vs OA) still decide who can be billed next — see the /denials library.

The prevention checklist

  • Verify before the visitAt scheduling and again before the appointment: is this plan + service on the payer’s auth-required list? Check the payer’s current list for the date of service — auth lists change, and memory is not a control.
  • Track auth validity windows in one shared registerAuth number, start/end dates, authorized units/visits, authorized procedure and place of service, rendering provider. The schedule and the claim system should both read from it — not from a letter in a chart tab.
  • Count units against the authorized blockEvery rendered visit decrements the counter. Trigger re-auth before the block runs out — the trigger point is your policy (a few visits before exhaustion), not the denial.
  • Attach the auth number to the claim in the field the payer expectsBox 23 on the CMS-1500 per the NUCC manual; the prior-authorization REF segment on the 837. “We had an auth” is not the same as “the auth was on the claim” — see /denials/co-16 and reason code 15.
  • Document medical necessity for the authorized serviceAn auth approves coverage as presented; the note must still support the service billed. For ongoing care, notes that show goals, progress, and continued need are what survive a retroactive review.
  • Reconcile remittances back to the auth register weeklyA zero-pay line with a 15/197/198 code is a signal about a specific link in the chain. Weekly reconciliation catches drift while corrected-claim windows are still open.
  • Escalate repeated payer behaviour with dataA payer whose auth requirements, decision times, or denial patterns look inconsistent with its own published policy is an escalation case — with the auth letters and remits as evidence, not a vibe.

Print this for the auth desk. Every item maps to a failure mode in the table above — none of them require new software to start.

The regulatory direction, as of this page’s review date

Prior auth is an active regulatory target, and the direction of travel is shorter decision times and more transparency — for the payers the rules reach.

CMS’s Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires impacted payers — Medicare Advantage organisations, state Medicaid and CHIP fee-for-service programmes, Medicaid and CHIP managed care entities, and qualified health plan issuers on the federally facilitated exchanges — to send prior-authorization decisions within 72 hours for urgent requests and seven calendar days for standard requests beginning in 2026, to give a specific reason when a request is denied, and to stand up patient-, provider-, and payer-facing APIs on published timelines (prior-authorization APIs by 2027 under the rule’s schedule). The rule’s scope and dates are in the CMS fact sheet (opens in a new tab) — note that the prior-authorization provisions do not apply to drugs, and the rule does not reach every commercial plan on its own.

Industry pressure has been building for longer. The AMA’s recurring physician surveys document prior auth as a top administrative burden — their research hub publishes each wave (AMA prior authorization research (opens in a new tab)). HFMA maintains a prior-authorization topic hub for revenue-cycle operators (HFMA (opens in a new tab)).

What this means operationally: keep your own auth register regardless of payer-side reform. A 72-hour decision clock helps only if your side submitted a complete request with the right documentation in the first place.

What AdvancedCare does in this space (disclosed)

The operator bar at the top of this page already tells you we sell revenue-cycle software and services, so here is the specific, honest version for auth work.

The cheapest auth failure to fix is the one caught at eligibility — before the visit, when the plan and service are known but nothing has been rendered. AdvancedCare operates [TurboVOB](https://turbovob.com), a batch eligibility-checking product that returns coverage and authorization flags for a full appointment roster — exactly the front-end step where “does this plan require auth for this service?” should be answered. AdvancedCare also sells revenue-cycle services that include auth tracking as part of denial prevention.

If your front end cannot answer that question at scheduling, that is the first fix — with or without us. The checklist above works with a spreadsheet and a shared calendar; tooling makes it faster, not possible.

Common questions

Is prior authorization the same as a referral?
No. A referral routes the patient between clinicians (common in HMO designs); prior authorization is the payer’s advance coverage review of a specific service. Some plans require both. A perfect referral with no auth on an auth-required service still denies.
Does an approved authorization guarantee payment?
No. It establishes that the service met coverage criteria as presented at the time. The claim can still deny for coding errors, untimely filing, eligibility retro-termination, or a mismatch between what was authorized and what was billed. Treat the approval as one requirement cleared.
What denial codes appear when the auth is missing or wrong?
Per the X12 Claim Adjustment Reason Code list (as of this page’s review date): reason 197 when precertification/authorization is absent, reason 15 when the authorization number is missing, invalid, or does not apply to the billed services or provider, and reason 198 when the authorized amount is exceeded. A missing auth number on the claim often arrives as reason 15 riding alongside CO-16 — see /denials/co-16.
Does Medicare require prior authorization?
Original fee-for-service Medicare requires it only for a short, published list of items and services — CMS maintains those programmes publicly (see the CMS prior authorization initiatives page in the sources). Medicare Advantage plans use prior authorization much more broadly, and CMS-0057-F now sets decision-time and denial-reason rules for those plans beginning in 2026.
Can a payer deny payment retroactively after approving an auth?
In some circumstances, yes — payers conduct post-payment medical-necessity reviews and recoup via takebacks, and eligibility retro-termination can unwind coverage entirely. Documentation that supported the auth request (and the notes for the rendered service) is what an appeal stands on. See the working order above for the appeal path.
Where does the authorization number go on the claim?
In the prior authorization number field — box 23 on the paper CMS-1500 per the NUCC instruction manual, and the corresponding REF segment on the electronic 837. An auth that exists but never reaches the claim field is the single most common self-inflicted auth denial.

Sources

  1. CMS Medicare fee-for-service prior authorization and pre-claim review initiatives (opens in a new tab) — Centers for Medicare & Medicaid Services
  2. CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheet (opens in a new tab) — Centers for Medicare & Medicaid Services
  3. CMS HIPAA administrative simplification — adopted standards and operating rules (opens in a new tab) — Centers for Medicare & Medicaid Services
  4. AMA prior authorization physician survey research reports (opens in a new tab) — American Medical Association
  5. HFMA prior authorization topic hub (revenue cycle resources) (opens in a new tab) — HFMA
  6. X12 Claim Adjustment Reason Codes (CARC) (opens in a new tab) — X12
  7. NUCC 1500 Health Insurance Claim Form Reference Instruction Manual (opens in a new tab) — National Uniform Claim Committee
  8. CMS Medicare Claims Processing Manual (Pub. 100-04) (opens in a new tab) — Centers for Medicare & Medicaid Services
  9. CMS MLN006562 — Medicare Parts A & B Appeals Process (opens in a new tab) — Centers for Medicare & Medicaid Services

Last reviewed against published HFMA, CMS, MGMA, Premier, and related primary sources linked on this page on .

Every benchmark and formula on this page is sourced and dated above. Where a figure is a range, the range is the honest answer, not a hedge. If you think something here is wrong or out of date, tell us — corrections are logged and dated.

Prior Authorization: Why Auths Fail & How to Prevent It