CO-197 denials signal a payment adjustment tied to missing advance approval steps. A payer assigns CARC 197 when precertification, authorization, notification, or a pre-treatment requirement is absent on the claim record or in the payer’s system. The denial often lands after the service date, which creates a tough financial outcome: revenue stops, appeals consume labor, and patient billing is frequently restricted under contract terms tied to the CO (contractual obligation) group code. CMS explains that group codes assign financial responsibility, with CO assigning provider liability and PR assigning patient liability.
This guide covers CO-197 from multiple angles—standards, payer operations, front-end workflow, and appeal mechanics—so a revenue cycle team can prevent repeat write-offs while staying aligned with payer rules.
What CO-197 means in medical billing
CARC 197 is standardized as: “Precertification/authorization/notification/pre-treatment absent.” The code communicates an administrative failure, not a clinical judgment about whether care matched medical necessity.
CO-197 appears when the remittance advice uses the CO group code with CARC 197. Group code matters because it communicates liability. CMS describes CO as a contractual obligation that assigns responsibility to the provider, while PR assigns responsibility to the patient.
A CO-197 denial typically means one of these events happened:
- An authorization request was never created.
- A notification window was missed.
- An authorization existed, but the claim data did not match the approved scope (dates, CPT/HCPCS, site, units).
- The payer issued an approval identifier (example: UTN), and the claim omitted it for services tied to a prior authorization program.
CO-197 vs PR-197 vs OA-197: Liability and Billing outcomes
A payer can pair CARC 197 with different group codes. The group code changes the balance path.
| Remit code pattern | Core meaning | Liability signal | Patient billing outcome |
| CO-197 | Advance approval stepis absent | Provider liability (contractual) | Patient billing is often restricted by contract terms tied to CO |
| PR-197 | The advance approval step is absent | Patient liability | Patient statement workflow applies |
| OA-197 | The advance approval step is absent | “Other adjustment” category | Review payer processing rules and contract language |
CMS notes that Medicare beneficiaries can be billed only when adjustments are used PR. That principle maps well to commercial logic: CO often blocks patient billing, PR allows it.
Prior Authorization vs Notification: Two Confusing Requirements
Authorization and notification differ in the payer’s control mechanism.
Authorization requires the payer to issue an approval decision before services occur. Decision outputs include authorization numbers, decision letters, approved CPT/HCPCS sets, unit ceilings, and date spans.
Notification requires the provider to inform the payer within a defined window before or after the service. Notification still fails under CARC 197 when the payer requires proof of timely notice, and the file shows none.
CO-197 often reflects confusion between these requirements. Scheduling staff treats “coverage verified” as “approval obtained.” Coverage verification confirms active eligibility; it does not confirm prior authorization completion.
Claim-level causes that produce CO-197.
CARC 197 is a single label, but the root cause varies. These are common cause patterns that show up in denial logs:
- No authorization on file
The payer requires authorization for the CPT/HCPCS, site of service, or place of service. The request never existed. - Authorization expired
The service date falls outside the approved start/end dates. - Authorization scope mismatch
The authorization covers CPT A, but the claim billed CPT B. Scope mismatch includes units, modifiers, place of service, rendering NPI, facility NPI, or diagnosis restrictions. - Notification missed
The payer required notice within X hours/days. The notice was late or absent. - Emergency exception not documented.. Emergency pathways often require specific documentation artifacts that justify bypassing pre-service approval.
- Payer identifier missing (UTN or equivalent)
Medicare prior authorization workflows can require a Unique Tracking Number (UTN) be reported in specific claim fields for certain services. Guidance from Medicare contractors shows UTN reporting locations in the claim loop/segment for electronic claims.
System-level root causes behind repeated CO-197
CO-197 volume rarely drops through “stronger appeals.” Volume drops through ownership, data capture, and audit loops.
Front-end breakdowns
- Intake does not run a procedure-level auth check against payer rules.
- Scheduling books the service before aauthorizationth decision is returned.
- Staff cannot see the auth status inside the PM/EHR because the data is stored in email, portals, or scanned PDFs.
- Authorization expiration dates are not tracked, so reschedules fall outside approved spans.
Mid-cycle breakdowns
- Coding changes after auth approval (diagnosis updates, CPT changes) without triggering an auth re-check.
- Site of service changes (ASC vs HOPD) without a new approval path.
Back-end breakdowns
- Claim submission omits the auth number, UTN, or payer-required reference segment.
- Claim edits fail to validate “auth on file + claim matches scope” before submission.
Services that attract CO-197 denials
Payers frequently tie authorization to cost concentration, utilization controls, or site-of-service rules. Denial logs often show CARC 197 clustering around:
- Advanced imaging (MRI, CT, PET; high-dollar codes)
- DME (wheels, braces, oxygen, supplies; documentation-heavy)
- Therapy plans (visit caps, episode limits, recertification)
- Outpatient surgeries (ASC/HOPD procedures with policy lists)
- Specialty drugs and infusions (J-codes, buy-and-bill pathways)
Service mix differs by payer, state, and plan type. A procedure-level rules matrix beats generalized assumptions.
Financial impact: where CO-197 creates a silent revenue loss
CO-197 triggers costs in 4 places:
- Non-payment on a completed service
The work is done, supplies consumed, staff paid. - Write-off pressure under CO liability
CO frequently blocks patient billing, pushing the balance into contractual adjustment pathways. - Labor cost in rework
Staff time gets diverted to portal checks, phone calls, and appeals. - Compliance and audit exposure
Payers treat repeated administrative failures as process risk. Denial spikes often lead to deeper documentation scrutiny on later claims.
A denial management dashboard should track CARC 197 as its own bucket because prevention levers differ from clinical denials.
CO-197 resolution workflow: a step-by-step operational play
Resolution works best as a decision tree, not a general checklist.
Step 1: Confirm the denial based on the remittance
- Pull the EOB/ERA line details.
- Capture the CARC (197) and any RARC attached.
- Confirm the group code (CO vs PR vs OA).
Some Medicare contractor guidance pairs Reason Code 197 with Remark Code N210 (“You may appeal this decision”) in certain scenarios. The remark changes the next step because it signals that an appeal path exists under that program.
Step 2: Locate the approval artifact set
Build a standardized artifact pack for every authorization-controlled service:
- Authorization number or UTN
- Decision letter (PDF) showing approval status
- Approved CPT/HCPCS list
- Approved units/visits
- Approved date span
- Site of service and rendering/facility identifiers
- Portal screenshot or confirmation page (date-stamped)
- Clinical notes submitted with the request
Medicare prior authorization programs can require UTN placement in specific electronic claim segments (loop 2300 REF segment with qualifier guidance shown by contractors).
Step 3: run a “scope match” check before resubmission
A scope match check prevents re-denial:
- Match the service date to the approved date span
- Match CPT/HCPCS to the approved code list.
- Match units to the approved ceiling
- Match the place of service to the approval conditions
- Match rendering NPI/facility NPI when the payer restricts the billing entity.
Step 4: Choose the correct action path
- Corrected claim works when approval exists, and the claim data was missing or mis-keyed.
- Reconsideration/appeal applies when approval exists, but the payer did not link it to the claim.
- Retro-authorization request applies only when the payer policy allows post-service approvals.
- Contractual write-off applies when approval never existed, and the payer classifies the failure as provider liability.
Appealable vs non-appealable: how to decide without guessing
Payer policy sets appeal rights. The cleanest internal rule uses evidence categories:
Appeal-ready evidence
- Prior authorization approval existed before the service date.
- Notification confirmation existed inside the required window.
- Emergency exception documentation exists and matches payer policy language.
Weak evidence
- No authorization request record.
- Authorization requested after the service date in a plan that disallows retro approvals.
- Approval exists but covers different codes, dates, or entities.
Some payer guidance explicitly signals appeal status through remark codes. Noridian’s Medicare DME guidance for Reason Code 197 shows the remark “N210 Alert: You may appeal this decision” and lists missing UTN or missing modifier as common triggers. That type of payer statement supports an appeal attempt when the provider can supply the missing identifier or modifier evidence.
CO-197 appeal pack: what to send and how to format it
An appeal wins on traceability. The payer reviewer needs a simple linkage between the approval and the billed line.
A complete CO-197 appeal pack includes:
- Cover letter with 3 identifiers: patient member ID, claim number, authorization number/UTN
- Copy of the decision letter showing approval
- Portal confirmation page with date stamp
- Claim form copy with corrected auth/UTN placement
- Clinical notes that match the submitted request packet
- A short scope match grid (date, CPT, units, site)
Medicare contractor pages describing UTN reporting fields provide a concrete reference for “where the identifier belongs” in electronic claims.
Retro-authorization: rules, time limits, and documentation controls
Retro-authorization exists as a payer policy choice, not an industry guarantee. Commercial plans sometimes allow post-service reviews under defined conditions, such as urgent care pathways, network disruptions, or late eligibility updates.
A retro-authorization request succeeds only when the file includes:
- Service date and time
- Clinical urgency documentation
- Provider notes supporting medical rationale.
- Proof of member eligibility on the service date
- Explanation for why pre-service approval did not occur
Medicare programs that use UTNs show how strict identifiers can be in prior authorization workflows, which signals a general truth: post-service fixes face tight acceptance criteria.
Payer-specific requirements: the UTN example in Medicare prior authorization
Certain Medicare prior authorization models issue a Unique Tracking Number (UTN) and require that the UTN be reported on the claim in specific locations. CGS explains UTN reporting for electronic claims using the 2300 loop reference segment, and Noridian provides UTN field requirements and validation rules.
Operational takeaway: payer identifiers must be treated as claim-critical data elements, not as notes stored in chart attachments.
A clean control set for UTN-managed services includes:
- UTN is stored in a discrete field in the PM system
- UTN mapped to EDI output (837 loop/segment rules)
- Claim edits that block submission when the UTN is missing for UTN-required HCPCS/CPT
- Denial workqueue rule that routes CARC 197 to an “auth linking” specialist first.
Tools and system controls that reduce CO-197 volume
Technology reduces CO-197 only when paired with ownership rules.
Core system controls
- Eligibility + benefit verification that includes a procedure-level auth requirement check
- Authorization tracking table with: payer, code set, approved units, start/end dates, site of service
- Expiration alerts at 7 days and 1 day before the end date
- Claim edit rule: block submission when the required auth/UTN field is blank
Denial analytics controls
- CARC 197 trend chart by payer, location, provider, CPT cluster
- Top 20 CPT list tied to CARC 197 over 90 days
- Rework time per denial (minutes) tracked as labor cost proxy.
Prevention: a 3-owner model that closes the gap
CO-197 prevention works best with 3 owners and 1 shared checklist.
Owner 1: Intake (coverage + rule discovery)
- Confirm active eligibility
- Capture plan type (HMO, PPO, Medicare Advantage)
- Flag authorization-required service categories tied to the visit reason
Owner 2: Scheduling (approval gating)
- Hold scheduling until the auth status shows “approved” or “not required.”
- Use a reschedule rule: any moved date triggers an auth re-check
Owner 3: Billing (scope validation + claim completeness)
- Validate the auth number/UTN populated in the correct claim field
- Run scope match check against CPT, dates, units, site, and NPI.
Pre-service authorization checklist (minimum fields)
- CPT/HCPCS list
- ICD-10 list
- Units/visits
- Start date and end date
- Rendering NPI and facility NPI
- Authorization number or UTN
- Decision status and date
Example scenario: how CO-197 happens in a specialty clinic
A specialty clinic schedules an outpatient procedure. Eligibility confirms an active plan. The plan requires prior authorization for the outpatient code set. The authorization request never gets submitted because the schedule is tight, and the team assumes eligibility equals approval.
The service is rendered. The claim transmits without an authorization number. The payer processes the claim and returns CO-197 because the pre-treatment approval requirement is absent. The remittance assigns CO liability, so the balance routes to contractual adjustment instead of patient billing. CMS describes CO as the provider’s responsibility on the remittance structure.
Prevention point: A scheduling gate tied to an “approved/not required” status would have stopped the service from moving forward without the required approval artifact.
CO-197 and similar denial codes: how to separate the fixes
Teams lose time when they treat every authorization-related denial as the same event.
| Code pattern | Primary failure | Primary fix |
| CO-197 | Precertification/authorization/notification/pre-treatment absent | Prove approval existed and link it to the claim, or write off under the contract |
| CO-16 | Missing/invalid information | Correct claim fields and resubmit |
| CO-50 / CO-96 | Non-covered service/charge | Coverage review and ABN/waiver rules, where applicable |
CARC 197 is distinct because it ties to advance approval mechanics, not general claim completeness.
What to do after a non-reversible CO-197
A non-reversible CO-197 still has value as process data.
- Record the denial in a reason taxonomy that distinguishes: “no auth,” “auth expired,” “scope mismatch,” “identifier missing,” “late notification.”
- Post the write-off to the correct contractual adjustment bucket.
- Trigger a root-cause review on the intake-to-scheduling handoff.
- Add a claim edit or scheduling gate tied to the specific payer + CPT cluster that caused the denial.
Conclusion
CARC 197 is standardized and clear that precertification and authorization are absent. The business damage comes from timing. The denial often arrives after the service date, and CO liability frequently blocks patient billing pathways under remittance rules that assign provider responsibility.
CO-197 reduction comes from operational controls: procedure-level rule discovery, authorization gating at scheduling, discrete storage of auth numbers and UTNs, and claim edits that enforce scope match before submission. Medicare contractor guidance on UTN placement shows how strict payer identifiers can be and why “missing one field” causes total non-payment.
A CO-197 prevention program is measurable. Denial volume drops after teams standardize ownership, track expiration dates, and validate scope before claims leave the system.
FAQs
What does the CO-197 denial code mean?
CO-197 indicates CARC 197
(“Precertification/authorization/notification/pre-treatment absent”) paired with the CO group code, which assigns provider financial responsibility on the remittance.
How do you fix CO-197?
Fix CO-197 by locating the approval artifact (auth number/UTN + decision letter), matching scope (dates, CPT/HCPCS, units, site), and submitting a corrected claim or appeal that links the approval to the billed line. Medicare contractors describe UTN claim placement for prior authorization programs.
What does status/reason code 197 mean on an EOB/ERA?
Reason code 197 means the payer adjudicated the claim with the standardized message “Precertification/authorization/notification/pre-treatment absent.”
What is a CO-197 adjustment?
A CO-197 adjustment is a payment reduction/denial tied to missing advance approval requirements, with the remittance indicating provider liability through the CO group code.
What is diagnosis code 197?
Diagnosis code 197 does not exist in the ICD-10 context. Code 197 here refers to a Claim Adjustment Reason Code used on remittance advice.
