CO-197 is the denial code that says the payer required precertification, prior authorization, or notification for the service and none was in place. It reads on the ERA as "Precertification / authorization / notification / pre-treatment absent." Where CO-15 flags an auth number that was on the claim but wrong, CO-197 flags a service that needed approval and never got it. The distinction changes both the recovery odds and the correct workflow.
What CO-197 means
- CO stands for Contractual Obligation. The adjusted amount is governed by your payer contract and cannot be billed to the patient.
- 197 is the reason code. The payer required a precertification, prior authorization, or notification step before the service was rendered, and its adjudication system found no matching approval on file for the patient, service, and date.
- Read the RARC on the ERA. Payers often attach a remark such as N54 ("Claim information is inconsistent with pre-certified/authorized services") or a payer-specific code that tells you whether the approval was truly absent, expired before the service, or lapsed for a different provider or facility.
CO-197 compared to CO-15
Both are authorization denials, but they are not the same problem and cannot be worked the same way. On a CO-15 denial, the payer typically has an authorization on file that does not line up with the claim: wrong number, wrong provider NPI, service outside the date range, or a procedure code the auth did not cover. That is often fixable with a corrected claim.
On CO-197 the payer sees no authorization at all. There is nothing to reconcile the claim against, because the precertification step was skipped or never completed. A corrected claim with better data will not change the answer. The path forward is either a retroactive approval request, an exception process, or a write-off.
The three CO-197 subtypes
Different subtypes have different recovery odds, so classify the denial before working it.
- No request was ever submitted. The service was scheduled and delivered without anyone opening a precert. This is the most common cause and the hardest to recover. Retroactive approval is possible for a subset of payers and services, but it is an exception process, not a workflow.
- Request was submitted but the approval never came back in time. Some CO-197 denials happen when a practice opened the request and delivered the service before the payer decisioned it. When you can document the request timestamp, some payers will reconsider on the basis that the request was in process at the time of service.
- Approval was granted but for a different provider, facility, or date. The auth exists in the payer's system but does not reference the rendering provider or site of service that appears on the claim. This class straddles CO-197 and CO-15; some payers issue one code, some issue the other. A corrected claim that reconciles the identifiers is worth trying.
Recovery paths and when to use each
- Retroactive authorization request. Most commercial payers publish a retroactive auth policy that names the acceptable reasons (typically emergent care, patient presented with incorrect coverage information, or documented submission delay caused by the payer). The request goes through the payer's utilization management department, not the standard claim reconsideration channel. Approval rates vary widely by carrier and clinical scenario.
- Peer-to-peer review. When the underlying service is clinically defensible, ask for a peer-to-peer between the treating physician and the payer's medical director. This works best on orthopedic, cardiology, and imaging denials where necessity is strong and the failure was administrative.
- Good-faith exception. If the practice relied on eligibility information that turned out to be wrong (the patient presented a card that did not reflect their current plan requirements), some payers have a documented good-faith process. Bring the eligibility screenshot or 271 response you relied on at scheduling.
- Write-off with a root-cause note. When none of the above applies, close the claim and log the specific scheduling or verification step that failed. The value of a CO-197 write-off is almost entirely in preventing the next 30 copies of it.
Which services are most exposed
The prior-auth requirement list is set by the payer, and it changes. For a young or renegotiated contract the safest posture is to verify requirements per service, per plan, at scheduling. The specialties that see the most CO-197 volume include orthopedic surgery, outpatient imaging (MRI, CT, PET), pain management injections, sleep studies, infusion therapy, and extended physical therapy episodes where auth must be renewed per visit block.
Prevention is the only reliable strategy
- Verify precert requirements at booking. Eligibility verification should capture not just active coverage but whether the planned CPT requires prior authorization for that plan. Systems that confirm eligibility without capturing auth requirements leave the exposure open.
- Submit early enough to survive a request for more documentation. Standard commercial auth windows commonly run 3 to 5 business days for non-urgent decisions, but the clock only starts when the request is complete. A request submitted the day before the procedure with a missing clinical attachment does not finalize in time.
- Reconfirm auth before the service is delivered. The approval status can change between the scheduling call and the appointment: eligibility updates, plan changes at month-end, or policy revisions can invalidate a previously granted auth. A pre-service verification catches this.
- Track auth expiration for episode-based care. PT, chiropractic, home health, and infusion series often authorize a visit block. Flag the expiration two weeks before the last visit so the renewal is in process before the next block starts.
A note on patient billing
CO-197 is a CO code, so the adjustment is a contractual write-off and cannot be balance-billed to the patient. For Medicare, an Advance Beneficiary Notice signed before the service is the only path to transferring liability, and ABNs on authorization-required services must clearly explain the specific reason coverage may be denied. A generic ABN is not sufficient.
The bottom line
CO-197 is worth reading as a signal, not a work queue. Individual recovery is possible in a minority of cases through retroactive approval or peer-to-peer review, but the return on time invested is low. The value sits upstream: a scheduling and verification workflow that catches auth requirements at booking, submits requests early, and reconfirms before service delivery. For the broader pattern of authorization-related revenue loss and how it compounds across the book, the revenue leakage guide covers the underlying economics.