Month: January 2026

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:

1. No authorization on file
   The payer requires authorization for the CPT/HCPCS, site of service, or place of service. The request never existed.
   
2. Authorization expired
   The service date falls outside the approved start/end dates.
   
3. 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.
   
4. Notification missed
   The payer required notice within X hours/days. The notice was late or absent.
   
5. Emergency exception not documented.. Emergency pathways often require specific documentation artifacts that justify bypassing pre-service approval.
   
6. 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:

1. Non-payment on a completed service
   The work is done, supplies consumed, staff paid.
   
2. Write-off pressure under CO liability
   CO frequently blocks patient billing, pushing the balance into contractual adjustment pathways.
   
3. Labor cost in rework
   Staff time gets diverted to portal checks, phone calls, and appeals.
   
4. 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.

Claim Adjustment Reason Code 96 is defined by X12 as: “Non-covered charge(s).” The code description includes a rule: at least 1 remark code must be provided to explain the adjustment, and the Electronic Remittance Advice (ERA) may include a policy reference in the 835 Healthcare Policy Identification segment.

What does CO-96 Mean?

CO-96 is not a statement about speed, pended status, or missing paperwork by default. CO-96 is a statement about coverage as adjudicated by the payer for that service line. The payer processed the line and assigned a coverage outcome that resulted in a reduction or denial.

Two operational conclusions follow from the official definition:

• CO-96 is a line-level classification. One claim can contain payable lines and CO-96 lines at the same time.
  
• The remark code matters. The payer is required to provide additional detail through remark messaging for this CARC.
  

CO-96 Changes Who Works 

Medicare’s remittance guidance explains that an ERA/RA uses 3 code sets for adjustments: Group Code, CARC, and RARC. Group codes assign financial responsibility. CO assigns responsibility to the provider. PR assigns responsibility to the patient. Medicare beneficiaries are billed only when PR is used with an adjustment.

That structure turns CO-96 into a routing decision:

• CO-96 under Group CO routes to contract/coverage validation and internal correction. Patient billing is restricted by the group code logic and payer rules.
  
• 96 under Group PR routes to patient responsibility workflows, financial consent checks, and notice requirements under the payer’s policies.

The code alone is not the decision. The code trio is the decision: Group Code + CARC 96 + RARC.

How to interpret CO-96 on an ERA (835) without wasting time

CMS describes the ERA as an itemized report of adjudication decisions and adjustments at the line, claim, or provider level. That description points to a reliable read sequence for CO-96.

Use this 4-step read sequence on every CO-96 line

Step 1: Start at the service line, not the claim total.

CAS adjustments attach to the service line. The claim can still pay even with one CO-96 line.

Step 2: Capture the group code.

CO vs PR changes liability, downstream billing, and compliance posture.

Step 3: Read the remark code (RARC) as the payer’s explanation.

X12 defines RARCs as codes that provide additional explanation for an adjustment already described by a CARC or convey processing information.

Step 4: Look for a policy reference segment.

X12’s CARC 96 guidance points billers to the 835 Healthcare Policy Identification segment (Loop 2110 REF) “if present.”
A policy ID, medical policy number, LCD/NCD reference, or payer clinical policy link often sits there in payer-specific form.

This sequence prevents 2 common failures: appealing without evidence and writing off without validating coverage logic.

CO-96 vs PR-96: What the Group Code Changes

CMS states the rule plainly: CO indicates a contractual obligation assigned to the provider. PR indicates patient responsibility. Medicare beneficiaries are billed only when PR is used with an adjustment.

That statement creates a posting rule that reduces disputes:

• CO-96 means the payer assigned provider liability for a non-covered charge under that payer’s adjudication. Patient billing is not the default action.
  
• PR-96 means the payer assigned patient liability for the non-covered charge, subject to payer policy, patient notice rules, and contractual requirements.

Posting teams that ignore group code risk 2 outcomes: billing a patient for a provider-liable adjustment or suppressing a patient balance that was correctly assigned.

What Triggers CO-96 in real billing operations?

X12 defines 96 as non-covered. The root cause sits underneath that label. Root causes fall into 5 operational buckets that map to different fixes.

1) Plan exclusion or benefit design exclusion

Coverage terms can exclude categories such as routine supplies, convenience items, non-covered preventive variants, or services outside a benefit schedule. A payer can mark the line non-covered even with correct coding.

Evidence to collect

• Member plan document excerpt or payer portal benefit screen
  
• Contract language for provider liability rules
  
• Policy ID reference from ERA, when present

Best action

• Write-off or patient billing only when the group code and notice rules support the transfer.

2) Coverage exists, but a required condition was not met

A service can be covered only under defined conditions, such as diagnosis restrictions, frequency limits, site-of-service rules, provider specialty rules, or step-therapy logic (common in pharmacy and injections).

Evidence to collect

• Medical policy criteria and the claim’s diagnosis/procedure pairing
  
• Prior utilization history for frequency edits
  
• Place of service, rendering NPI taxonomy, facility type

Best action

• Correct claim elements when the criteria were met but not communicated.
  
• Appeal with policy criteria crosswalk when the criteria were met clinically.

3) Authorization or precertification requirement

Many payers treat missing authorization as non-covered at adjudication, producing CO-96 with a remark that identifies authorization failure. The action depends on payer rules for retro-authorization and timely filing.

Evidence to collect

• Authorization number, approval letter, dates, service units
  
• Proof of submission route used by the payer

Best action

• Correct and resubmit with authorization data when allowed.
  
• Appeal with authorization evidence when the ERA contradicts the approval.

4) Eligibility mismatch on the date of service

Eligibility changes produce denials that present as non-covered. Coverage lapses, wrong subscriber ID, wrong payer sequence, terminated coverage, or dependent status changes show up here.

Evidence to collect

• Eligibility response for date of service
  
• Patient demographics match (name, DOB, member ID)
  
• Coordination of benefits verification

Best action

• Correct payer, member ID, or coordination order, then resubmit.

5) Coding or documentation failed to communicate coverage criteria

A covered service can be adjudicated as non-covered if the submitted code set signals an excluded service, a missing modifier, or an unsupported diagnosis. Documentation failures compound the problem by blocking medical necessity review.

Evidence to collect

• CPT/HCPCS code, modifier set, diagnosis set
  
• Payer coding policy or claim editing rules
  
• Chart note sections that prove indication, duration, and findings

Best action

• Correct code/modifier/diagnosis with documentation support, then resubmit.
  
• Appeal only after the corrected clinical story matches payer policy.

Why is the remark code (RARC) not optional for CO-96 work?

CARC 96 includes a requirement for remark messaging. CMS Medicare guidance explains why: some CARCs are generic and do not communicate the reason clearly without remark codes, so Medicare contractors must report appropriate remark codes, and remark codes are maintained by CMS.

X12 defines RARCs as the “additional explanation” layer for a CARC. That definition creates a practical rule:

CO-96 without the RARC is incomplete. Work based on the CARC alone produces misrouted appeals and incorrect write-offs. A real example appears in Medicare contractor education: Noridian pairs Reason Code 96 with Remark Code N180 to indicate the item/service did not meet criteria for the category billed. That pair changes the fix from “coverage excluded” to “billed under wrong category/criteria mismatch.”

How to address CO-96: A 7-step Resolution Workflow

Denial teams perform better with a repeatable workflow that ends in one of 3 outcomes: correct/resubmit, appeal, or write-off.

Step 1: Pull the ERA line and store the full adjustment context

• Capture group code, CARC 96, RARC(s), allowed amount, and adjustment amount
  
• Capture policy ID reference segment when present.

Step 2: Classify the denial into 1 of 5 buckets

• Exclusion
  
• Coverage condition not me.t
  
• Authorization missing/invalid
  
• Eligibility mismatch
  
• Coding/documentation mismatch

Step 3: Validate eligibility and payer sequence for date of service

• Match subscriber ID, patient demographics, and plan effective dates
  
• Confirm primary vs secondary order. er

Step 4: Validate authorization, referrals, and policy restrictions

• Match auth dates, units, rendering provider, facility, CPT list
  
• Match policy criteria to chart evidence

Step 5: Validate coding and modifiers against payer rules

• Confirm CPT/HCPCS selection
  
• Confirm modifier necessity (bilateral, professional/technical, screening indicators)
  
• Confirm diagnosis supports the policy criteria.

Step 6: Choose the correct action path

• Correct and resubmit for fixable claim element errors
  
• Appeal for payer misapplication of policy or misread documentation
  
• Write-off or transfer only after exclusion confirmation and liability review

Step 7: Record a prevention tag

• Eligibility verification gap
  
• Authorization workflow gap
  
• Coding education gap
  
• Policy mapping gap
  
• Front-end disclosure gap

Prevention tags convert a denial into process control.

Correct and resubmit vs appeal vs write-off: a practical decision rule

CARC 96 means non-covered, not “unpayable forever.” A structured decision rule limits wasted rework.

Correct and resubmit fits these scenarios

• The wrong payer was billed, orthe  coordination order was wrong
  
• Subscriber/dependent data mismatch
  
• Authorization obtained but not transmitted on the claim
  
• Modifier omission that changes coverage classification
  
• Diagnosis mismatch that blocks medical policy match
  
• Documentation exists, but the claim did not carry the right code set.

Appeal fits these scenarios

• Policy criteria met, denial contradicts chart documentation.
  
• Authorization approval exists; denial claims are missing authorization.
  
• Payer applied the wrong benefit rule for plan type
  
• Payer misread screening vs diagnostic classification based on billed indicators

Write-off fits these scenarios

• The member plan excludes the service category.
  
• Contract disallows reimbursement and assigns provider liability under C.O.
  
• Medical policy explicitly excludes the indication with no override p.ath

Group code review stays mandatory because CO and PR change liability.

Prevention: Reduce CO-96 volume using 6 front-end controls

CO-96 prevention is a front-end verification problem more than a back-end appeal problem.

Control 1: Service-specific eligibility verification

• Verify active coverage for the exact date of service
  
• Verify the benefit category for the exact service type.

Control 2: Policy mapping for high-denial CPT groups

• Map payer medical policies to a short internal checklist
  
• Map frequency limits, diagnosis gates, and site-of-service limits

Control 3: Authorization gating tied to scheduling

• Block scheduling release until the authorization status is recorded
  
• Tie the CPT units and facility data to the authorization record.

Control 4: Coding rules built into charge capture

• Require modifiers for common classification shifts
  
• Require screening indicators where payer policy expects them.

Control 5: Documentation prompts that match policy language

• Prompt for indications, prior conservative therapy, imaging findings, impairment measures
  
• Prompt for start/stop times and complexity elements where needed

Control 6: Financial disclosure workflow for non-covered services

• Flag likely non-covered services before visit completion
  
• Document patient notice and estimate rules required by the payer and contract

Why colonoscopy claims show CO-96: screening rules vs diagnostic rules

Federal rules under the Affordable Care Act (ACA) require many plans to cover recommended preventive services without patient cost-sharing, including colorectal cancer screening recommended by the United States Preventive Services Task Force (USPSTF). The operational issue is classification. Screening workflows and diagnostic workflows use different coding signals, payer edits, and patient cost-sharing logic.

CMS-issued ACA FAQs state that a plan must cover a follow-up colonoscopy after a positive non-invasive stool-based screening test without cost-sharing for individuals in the USPSTF recommendation, describing the follow-up colonoscopy as an integral part of preventive screening.

CO-96 shows up on colonoscopy lines under patterns such as:

• Screening billed without the payer-required screening indicators
  
• Diagnostic intent billed under a plan that restricts the diagnosis set
  
• Frequency limits exceeded under plan rules.
  
• Authorization or site-of-service restriction triggered by plan design
  

Coverage confusion is common enough that patient-facing organizations warn that “screening” definitions create billing confusion in practice.

Conclusion

CARC 96 is defined as “Non-covered charge(s)” and requires remark messaging. The operational mistake is treating that label as a single action. Payment posting improves once the team reads CO-96 as a 3-part message: group code assigns liability, CARC states the broad reason, and RARC supplies the payer’s specific explanation.

A CO-96 line becomes manageable through a repeatable method: classify the root cause, collect the right proof, choose the correct action path, and record the prevention tag. That structure protects cash flow, reduces rework, and limits patient billing errors that trigger complaints and reversals.

FAQs

Why would a colonoscopy get a denial code 96?

Denial code 96 appears when the payer adjudicates the colonoscopy line as non-covered under the plan’s coverage rules. Screening vs diagnostic classification, frequency limits, site-of-service rules, authorization rules, and missing screening indicators drive that outcome in many payer edits. ACA guidance emphasizes that preventive colorectal screening should be covered without cost-sharing in many plans, and CMS clarifies coverage for follow-up colonoscopy after a positive stool-based screening test.

What does code 96 mean?

Code 96 is defined by X12 as “Non-covered charge(s)” and requires at least 1 remark code to explain the adjustment.

Is CO-97 a denial code?

CO-97 is a CARC that indicates the benefit for the service is included in the payment/allowance for another adjudicated service (bundled/included). X12 lists this meaning directly after CARC 96 in its code list.

What is the difference between CO-96 and PR-96?

CMS explains the core difference: CO assigns provider liability (contractual obligation), and PR assigns patient liability (patient responsibility). Medicare beneficiaries are billed only when PR is used with an adjustment.

What does a CO-96 denial on the claim mean for next steps?

Next steps depend on the full adjustment context: group code, remark code, and policy reference. CMS describes those code sets as the mechanism that explains adjustments on ERA/RA. Read the RARC, classify the root cause, then choose correct/resubmit, appeal, or write-off.

Is a colonoscopy 100% covered by insurance?

Many private plans cover USPSTF-recommended colorectal cancer screening without cost-sharing under the ACA, and CMS clarifies that a follow-up colonoscopy after a positive stool-based screening test must be covered without cost-sharing for applicable individuals. Patient cost-sharing can still appear based on plan design and classification rules that treat the service as diagnostic rather than preventive, which is a documented source of confusion in practice.

Clean claims still fail. Coding still passes. Documentation still exists. Revenue still disappears. CO-29 sits behind that pattern. The remittance message reads like a paperwork issue, yet the result hits cash the same way as a medical necessity denial. Covered services reach $0 payment because the payer marks the claim “late,” then assigns the balance to provider liability under the contract.

This guide covers the topic from three angles. The first angle explains what CO-29 means on an ERA/EOB and how to spot it fast. The second angle maps the operational causes that push a claim past the filing window. The third angle lays out a workflow that prevents late filing, triages appeals, and builds proof that payers accept.

What CO-29 Means

CO-29 is a shorthand label used by billing teams. The remittance uses two parts:

• Group Code: CO (Contractual Obligation)
  
• Claim Adjustment Reason Code (CARC): 29 (The time limit for filing has expired)
  

CARC 29 states the reason for the adjustment. Group Code CO states financial responsibility. CO places the unpaid amount on the provider side under contract or regulation. Patient billing for CO amounts often violates payer rules and contract terms, so write-off risk rises.

CARC 29 definition

X12 maintains the CARC list used in 835 ERAs. CARC 29 means: “The time limit for filing has expired.”

That single sentence drives the operational reality: claim accuracy stops mattering once the filing deadline passes.

What the CO group code signals

X12 guidance ties CO to adjustments that are not the patient’s responsibility due to contract or regulatory requirements.

That grouping changes behavior. Staff time spent “reworking” a truly late claim rarely returns revenue. Teams need a triage rule that separates appealable CO-29 from contractual write-off.

Where CO-29 Shows Up on ERA/EOB

CO-29 appears in the CAS adjustment segment of an 835 ERA, tied to a service line or the claim level. The EOB often adds plain-language text such as “time limit expired” or “received after filing deadline.”

CO-29 gets missed for one reason: payment posters focus on paid lines and ignore adjustment codes on zero-paid lines. A denial with $0 payment still posts cleanly in some systems, then disappears into “closed claims” unless a denial worklist catches it.

Fast identification checklist

• ERA shows Group CO with Reason 29 on the line or claim.
  
• Payment amount equals $0, or payment posts with full contractual adjustment.
  
• EOB text references late filing or expired submission limit.
  

A denial dashboard that counts CARC 29 weekly prevents “surprise write-offs” at the month-end.

Timely Filing Rules That Trigger CO-29

Timely filing rules vary by payer and claim type. Contract language controls commercial plans. Medicare rules sit in regulations and CMS instructions.

Medicare baseline rule

Medicare claims generally require filing within 1 calendar year after the date of service.

CMS manuals describe how Medicare determines the timely filing period and when exceptions apply.

A payer rule that breaks internal assumptions

Internal teams often assume one “universal” deadline. Payers run multiple clocks:

• Original claim clock
  
• Corrected/replacement claim clock
  
• Appeal/reconsideration clock
  
• Secondary claim clock tied to primary adjudication
  

A claim that meets one clock still fails another.

Why CO-29 Happens on “Clean” Claims

CO-29 is an operations denial. It follows a delay. Delay hides in handoffs.

1) Documentation readiness delays

• Missing physician signatures, incomplete notes, and unsigned orders
  
• Charge entry is waiting for clinical documentation completion.
  
• Late coding due to the chart closure backlog
  

Each day in “missing note” status eats into the filing window.

2) Registration and eligibility defects

• Wrong payer loaded, wrong plan selected, missing subscriber ID
  
• Eligibility not verified for the date of service.
  
• Prior authorization status not captured in the claim package.t
  

A single registration defect leads to rejections, then late resubmission, then CO-29.

3) Clearinghouse rejection loops

Rejections do not pause the filing clock. A claim rejected for formatting or missing data still consumes days.

Common loop pattern:

• Day 0: claim sent
  
• Day 2: rejection hits the scrubber queue
  
• Day 10: staff correction
  
• Day 14: resubmission
  
• Day 30+: payer receives a “clean” claim that is now outside the contract window
  

4) Secondary claim dependency

Secondary billing waits on the primary payer’s EOB/ERA. Primary delays compress the secondary window. Teams that hold secondary submission until posting completion lose days that never return.

5) Ownership gaps inside the billing office

CO-29 spikes in offices with no named owner of the “claim clock.”

• The coding team assumes the billing team submits.
  The billing team assumes the provider completes documentation.
  
• The follow-up team assumes the billing team monitors rejections.
  
• Nobody owns the deadline.
  

A single-owner model solves that gap.

Corrected and Resubmitted Claims: The CO-29 Trap

Teams often treat a corrected claim as a “fresh start.” Many payers still measure timeliness from the original date of service or the original receipt date, not the resubmission date.

Corrected claims need a controlled workflow:

• A correction reason code
  
• A replacement claim indicator
  
• A submission date is tracked against the payer’s correction rule.
  

A corrected claim sent late creates the same CO-29 outcome as an original late claim.

Proof Standards That Win CO-29 Appeals

CO-29 appeals only win with proof of timely filing or a payer-caused barrier supported by documentation.

Proof that payers accept

• Clearinghouse acceptance report with timestamp and claim ID
  
• Payer portal submission confirmation with date/time
  
• 277CA or acknowledgement showing payer receipt
  
• Evidence of payer portal outage tied to the filing period, with ticket numbers and screenshots
  
• Primary EOB date for secondary claims, paired with the secondary payer’s rule language
  

A narrative letter without time-stamped proof rarely moves a CO denial.

Medicare-specific filing authority

Medicare’s timely filing limit is grounded in regulation and CMS instructions. Claims filed after the period are denied unless an exception applies.

Medicare contractors also publish denial resolution guidance that flags timely filing denials as non-appealable in some contexts, so policy checks matter before staff time gets assigned.

A Step-by-Step Workflow to Fix CO-29 Denials

Step 1: Confirm the clock start point

Record these three dates:

• Date of service (or discharge date for institutional spans)
  
• Payer receipt date on the ERA/EOB
  
• First submission date from internal logs
  

Medicare uses a one-year standard tied to date of service, with defined start-date rules and exceptions.

Step 2: Pull the payer’s timely filing rule

Use the contract, provider manual, or payer portal policy page. Store the rule in a shared reference library with:

• Plan name
  
• Filing limit in days
  
• Rule for corrected claims
  
• Rule for secondary claims
  
• Submission channel requirements (EDI vs portal vs paper)
  

Step 3: Classify the CO-29 into one of 3 buckets

Bucket A: Proof exists

• Claim submitted on time, payer processed late, or payer misread the receipt date.
  

Bucket B: Exception exists

• Payer outage, retro eligibility, and a coordination issue with the written policy allowance

Bucket C: No proof, no exception

• Operational late filing with no accepted evidence
  

Bucket C needs write-off governance, not repeated resubmissions.

Step 4: Build the proof packet

Attach in this order:

1. Timely filing rule citation (payer document excerpt or portal screenshot)
   
2. Submission proof (clearinghouse acceptance, portal confirmation, 277CA)
   
3. Claim copy with identifiers (patient, DOS, claim number)
   
4. Any rejection history showing continuous, timely attempts
   
5. Primary EOB for secondary claims
   

Step 5: Submit the appeal through the payer’s required path

Use the payer’s official method. Payers reject appeals sent to the wrong intake.

Track:

• Submission date
  
• Appeal reference number
  
• Contact name and call reference ID
  
• Next follow-up date
  

Step 6: Monitor outcome and stop duplicate work

Close the loop:

• Overturn posted: update denial root cause and prevent recurrence
  
• Upheld: move to contractual write-off workflow with leadership sign-off
  

Prevention: A Timely Filing System That Runs Daily

CO-29 prevention works like infection control. A daily routine beats a monthly cleanup.

People controls

• Assign one role as Timely Filing Owner for each payer group
  
• Cross-train one backup per owner.
  
• Train staff on reading plan cards and identifying payer class rules
  
• Require documentation completion standards tied to charge entry SLAs
  

Process controls

Set hard thresholds:

• 48-hour charge entry target
  
• 7-day unbilled service review
  
• Daily rejection queue zero.g
  
• 14-day documentation escalation to clinic leadership
  
• 30-day secondary claim trigger from primary ERA receipt
  

Put those thresholds into a checklist, then tie the checklist to daily huddles.

Technology controls

• Missing insurance flags at registration
  
• Claim scrubber edits mapped to top rejection causes
  
• Automated worklists for unbilled encounters by payer clock
  
• Clearinghouse dashboard monitoring for 999/277CA failures
  
• Alerts for claims near the filing limit by payer-specific day count
  

A system without alerts relies on memory. Memory fails at scale.

A Timely Filing Tracker That Billing Teams Use

Build a tracker with five fields that drive action:

1. Payer
   
2. Filing limit (days)
   
3. Clock start rule (DOS, discharge, primary EOB date)
   
4. Last acceptable submission date (auto-calculated)
   
5. Owner and current status
   

Link the tracker to two queues:

• Unbilled encounters queue (pre-claim)
  
• Rejected claims queue (post-scrub, pre-payer)
  

Aging buckets based only on “days in A/R” miss the pre-submission risk.

CO-29 vs Related Denial Codes

Code	Meaning	Payer Logic	Operational fix
CO-29	Time limit expired	Claim received after filing deadline	Appeal only with timely proof or a defined exception
CO-18	Duplicate claim/service	Claim already adjudicated	Check claim history, correct payer error, avoid duplicate resubmission
CO-16	Missing/invalid info	Required elements absent	Correct the data, resubmit fast to protect the deadline
CO-45	Contractual reduction	Allowed amount below the charge	Post per contract, prevent balance billing errors
CO-22	Incorrect payer sequence	Another payer primary	Fix COB, submit primary, then secondary within rules
CO-197	Auth missing	Precert required	Obtain auth per policy, tighten auth capture at scheduling

Financial and Operational Impact of CO 29

CO-29 creates three measurable effects:

• Net revenue loss from contractual write-offs tied to timely filing
  
• Labor cost from low-yield appeals and repeated follow-up
  
• Cash volatility fromthe  delayed recognition of uncollectible balances

Track CO-29 as a rate, not a raw count:

• CO-29 dollars / total billed dollars
  
• CO-29 claims / total claims
  
• CO-29 by payer, location, provider, and denial root cause
  

A leadership dashboard that shows trend lines forces accountability.

Real-World Failure Patterns and the Fix to Stop Them

Pattern 1: Documentation backlog drives late charge entry

Fix:

• Chart completion SLA tied to charge entry
  
• Daily “missing note” list sent to clinic managers
  
• Escalation at day 14 with the service-line director copied
  

Pattern 2: System change routes claims into a suspended queue

Fix:

• Post-change audit of claim status by payer within 72 hours
  
• Auto-report for “held” claims with no transmission record
  
• Incident log stored with screenshots for appeal proof.
  

Pattern 3: Secondary claims wait for posting completion

Fix:

• Secondary claim build starts on primary ERA receipt, not on posting completion
  
• Secondary submission deadline calculated from the secondary payer rule and stored in the tracke.r
  
• Worklist that triggers at day 10 after primary ERA if the secondary is not billed
  

Leadership Checklist for Sustainable CO-29 Reduction

• Assign one Timely Filing Owner per payer class.
  
• Approve payer-specific filing rules library and keep it current.t
  
• Require a daily rejection zeroing metric.
  
• Reviewthe  CO-29 trend monthly by payer and root cause.
  
• Approve a write-off governance rule for Bucket C claims
  
• Enforce documentation SLAs tied to charge capture.
  

Governance turns CO-29 into an exception instead of a recurring loss.

Conclusion

CO-29 denial volume signals a deadline system failure, not a coding failure. CARC 29 states the late filing reason. Group CO assigns provider liability under the contract.

Appeals succeed only with time-stamped proof or a defined exception. Medicare’s baseline timely filing rule sits at one calendar year from the date of service, with documented exception pathways.

A prevention workflow stops CO-29 by controlling clocks, queues, and ownership every day. That system protects reimbursement before the deadline closes.

FAQs

What is the denial code CO-29?

CO-29 refers to Group Code CO plus CARC 29 on an ERA/EOB. CARC 29 states that the time limit for filing expired.

What is reason code 29?

Reason code 29 is CARC 29, defined by X12 as “The time limit for filing has expired.”

What does CO-29 stand for?

CO stands for Contractual Obligation (provider liability under contract). 29 is the filing limit reason code. X12 guidance ties CO to non-patient responsibility adjustments due to contract or regulation.

What is a Medicare code 29?

Medicare uses CARC 29 for timely filing denials. Medicare’s baseline timely filing limit is 1 calendar year from the date of service, subject to defined exceptions.

What is the 29 modifier?

CPT modifiers do not use “29” for timely filing. CARC 29 is a remittance adjustment reason code, not a CPT modifier.

What does the denial code CO-129 mean?

CO-129 is a contractual adjustment code tied to payer rules that do not match the timely filing logic. CO-29 is the late filing code. Resolution steps differ because the root cause differs.

CO-22 is a denial that blocks payment even after a clean claim, valid eligibility, and complete documentation. The payer accepts the claim for processing, then refuses payment because a different plan is expected to pay first. That single decision triggers avoidable rework: eligibility rechecks, phone calls, patient statements, delayed secondary billing, and rising A/R days.

What is the CO 22 Denial Code?

CO-22 is not a “fix the CPT” denial. CO-22 is a coordination of benefits (COB) failure that starts at registration and surfaces later on the ERA/EOB. The right response is not guessing. The right response is a structured COB workflow that:

• (1) confirms the correct payer order
• (2) proves primary adjudication,
•  (3) routes the claim to the payer that has payment responsibility.

What Is the CO-22 Denial Code?

CO-22 combines a Claim Adjustment Group Code and a Claim Adjustment Reason Code (CARC):

• Group Code CO = Contractual Obligation
  
• CARC 22 = “This care may be covered by another payer per coordination of benefits.”
  

It shows the payer is stating that it is not the payer with primary payment responsibility for this service under COB rules. COB exists to assign a payment order when more than one plan covers the patient. CMS describes COB as the process plans use to determine their payment responsibilities when multiple coverages exist.

CO-22 is triggered in common multi-coverage situations: employer plan + spouse plan, Medicare + employer plan, Medicaid secondary scenarios, accident coverage, workers’ compensation, and other “third-party liability” setups. The payer’s systems detect another coverage signal and stop payment until the billing sequence and prior assessment are aligned.

What “CO” Means in CO-22

Group Code CO indicates a contractual obligation adjustment category in the X12 code structure.
A key operational point applies in Medicare contexts: Medicare guidance states that a provider is prohibited from billing a beneficiary for an adjustment amount identified with a CO group code (Medicare uses CO vs PR to distinguish provider vs patient liability).

That distinction matters because CO-22 often tempts teams to shift the balance to the patient while COB is unresolved. Patient billing during a COB dispute creates complaints, delays, and write-offs later.

How CO-22 Shows Up on ERA (835) and EOB

ERA/EOB posting displays CO-22 as:

• CAS segment (Claim Adjustment) showing CO with reason 22
  
• A message that points to another payer as primary
  
• In many cases, a remark that indicates missing primary payer evidence
  

A frequent pairing is MA04, which states, “Secondary payment cannot be considered without the identity of or payment information from the primary payer.” Noridian publishes this exact pairing under Reason Code 22 with Remark Code MA04.

Why CO-22 Denials Happen

CO-22 is the output. The input is usually one of these trigger points:

1) Wrong payer billed first

Claim routing fails when the claim is sent to the secondary before the primary. CARC 22 exists specifically to prevent payment when another payer should be involved first.

2) Primary vs secondary order mismatch in the patient file

A correct claim form still denies if the insurance order in the PM/EHR is wrong. The payer sees other coverage and rejects responsibility.

3) Missing primary payer adjudication for a secondary claim (MA04 pattern)

Secondary billing fails when the claim lacks primary EOB/ERA details. Noridian’s MA04 explanation describes this as missing or illegible primary payer info/payment data.

4) Coverage overlap and stale termination dates

Termination dates, plan changes, and employer switches cause “phantom” primary coverage signals. A payer match can identify another active plan even when the patient believes it ended.

5) Medicare Secondary Payer (MSP) data not aligned

Medicare COB depends on MSP rules and data captured through MSP questioning and payer files. A mismatch pushes Medicare (or the other payer) into a “secondary expected” posture. CMS frames COB as determining which plan is primary and how others contribute.

6) Patient demographic or policy data errors

COB discovery fails when the name, DOB, subscriber ID, group number, or relationship to the subscriber is wrong. That failure breaks eligibility verification and confuses the payer order.

The Real Cost of CO-22 Inside the Revenue Cycle

CO-22 creates revenue cycle damage through measurable operational effects:

• Delayed reimbursement: Payment pauses until primary adjudication is obtained and the claim is rerouted.
  
• Higher cost per claim: Extra touches occur across teams: registration, billing, denial management, and patient accounts.
  
• A/R aging creep: CO-22 claims drift into 31–60, 61–90, and 90+ day buckets through slow back-and-forth.
  
• Patient dissatisfaction: Patient statements go out before COB is resolved, producing disputes and refund cycles.
  
• Timely filing risk: Secondary timely filing clocks can be missed if primary processing proof is not gathered quickly.
  

CO-22 is predictable. Predictable denials belong in front-end controls, not back-end hero work.

CO-22 Triage in 10 Minutes: A Decision Tree That Prevents Guessing

A denial team needs a short, repeatable triage that drives the next action.

Step 1: Confirm the payer posture from the ERA/EOB

• CARC 22 present (“covered by another payer per COB”)
  
• MA04 present (primary payer payment/identity missing)
  

Step 2: Identify the scenario type (pick 1)

• Secondary claim sent without primary EOB/ERA
  
• The wrong payer was billed first.
  
• Other coverage exists but is terminated/stale.
  
• MSP/accident/liability coverage expected
  

Step 3: Decide the route

• Resubmit when the payer order or missing primary evidence caused the denial.
  
• Appeal only when the payer is wrong after the correct COB proof is present.
  

Most CO-22 cases close through corrected sequencing and resubmission, not appeal, because the payer denial logic matches the X12 definition of CARC 22.

Step-by-Step Guide to Resolve CO-22 (Execution Workflow)

1) Validate patient demographics and insurance fields

Fields that drive COB accuracy:

• Subscriber name + DOB
  
• Subscriber ID + group number
  
• Patient relationship to subscriber
  
• Plan effective date + termination date
  
• Coordination indicators (primary/secondary/tertiary)
  

2) Run eligibility for each plan on the date of service

A single “eligible” response is not enough. Eligibility needs payer order clarity.

3) Determine the correct payer order

COB rules vary by plan type. Medicare COB relies on MSP rules and the payer responsibility order.
Dependent coverage disputes often use the “birthday rule” in commercial insurance contexts (plan of parent whose birthday falls earlier in the calendar year is primary).

4) Bill the primary payer first (or correct primary billing)

Primary adjudication is the anchor event for secondary billing.

5) Obtain the primary payer ERA/EOB and payment details

Secondary payers often require:

• Primary payer paid amount
  
• Adjustments (deductible, coinsurance, copay)
  
• Denial reason if primary denied
  
• Claim control number or trace numbers
  

6) Submit the secondary claim with primary adjudication attached or populated

MA04 patterns resolve when primary payer identity/payment data is present.

7) Use the correct submission type

• Corrected claim indicators when the payer requires them
  
• Secondary claim filing rules for the specific payer
  
• Clearinghouse COB fields are populated consistently.
  

8) Track to closure with 2 checkpoints

• Checkpoint A (48–72 hours): Claim accepted and in process
  
• Checkpoint B (14 days typical): Adjudication or request for info
  

Resubmit vs Appeal: Rules That Resolve Issue

Resubmit CO-22 when the primary and secondary orders in the claim were wrong.

• Primary EOB/ERA data was missing (MA04 pattern)
  
• Another plan was omitted from the claim.
  
• Termination dates were missing and corrected.
  

Appeal CO-22 when:

• Primary adjudication is already attached and complete
  
• Eligibility and COB documentation confirm that the billed payer is the primary
  .
• The payer continues denying despite the verified absence of other coverage.
  

Appeals need evidence. Evidence means eligibility proof, COB notes, and prior payer adjudication logs.

Preventing CO-22: Front-End Controls That Stop the Denial Upstream

CO-22 prevention is registration design, not denial management.

Control 1: Collect 12 data points at every visit

A registration checklist that reduces stale COB:

1. Subscriber name
   
2. Subscriber DOB
   
3. Subscriber ID
   
4. Group number
   
5. Patient relationship
   
6. Plan name + payer ID
   
7. Effective date
   
8. Termination date (when present)
   
9. Secondary plan presence
   
10. Accident/work-related indicator
    
11. Employer name (for employer plans)
    
12. Authorization/referral requirements
    

Control 2: Ask COB questions in the same structure every time

A consistent script produces consistent payer order decisions:

• “Coverage through an employer plan today?”
  
• “Coverage through a spouse plan today?”
  
• “Coverage through Medicare or Medicaid today?”
  
• “Coverage tied to an accident, auto claim, or workers’ compensation today?”
  

Control 3: Re-verify coverage at defined intervals

COB changes faster than teams expect. A practical cadence:

• Every visit tohigh-volume clinics
  
• Every 30 days for recurring therapy, DME, and home health
  
• Every new episode of care for hospital outpatient
  

Control 4: Use claim scrub rules for COB conditions

Edits that reduce CO-22:

• Secondary claim blocked without primary EOB/ERA fields
  
• Claims are blocked when the primary/secondary order conflicts with the plan type flags.
• Alerts for overlapping effective dates across plans
  

Control 5: Build a “COB exception que..ue”

A/R control improves when CO-22 is routed to a small queue with:

• same-day insurance discovery
  
• patient outreach template
  
• payer portal verification
  
• resubmission ownership
  

Denial Management Metrics for CO-22 (What to Track Weekly)

A CO-22 program needs numbers that drive operational change:

• CO-22 rate per 1,000 claims (target reduction trend)
  
• Touches per CO-22 claim (registration touch + billing touch + denial touch)
  
• Days to primary adjudication (front-end to payer response)
  
• Secondary submission lag (primary ERA date → secondary submit date)
  
• CO-22 overturn rate (closed by corrected COB vs appeal)
  
• Timely filing saves (count of claims rescued before deadline)
  

A CO-22 spike usually traces back to a single operational change: new registration staff, new payer, new eligibility tool, new employer enrollment season, or a clearinghouse mapping issue.

Conclusion

CO-22 is a COB signal: another payer is expected to carry primary payment responsibility. X12 defines CARC 22 as care that may be covered by another payer per coordination of benefits, and the CO group code identifies the adjustment category.
A paired MA04 message often means the claim reached a secondary payer without primary payer identity or payment information.

Payment speed improves when CO-22 is handled as a front-end data and workflow problem. A clean process uses 3 anchors: correct payer order, primary adjudication proof, and structured resubmission rules. That system reduces claim touches, protects timely filing, and keeps patient billing aligned with payer responsibility expectations.

FAQs

What does claim status code 22 mean?

CARC 22 means the payer believes the care may be covered by another payer under the coordination of benefits.

What is code 22 in medical billing?

Code 22 commonly refers to CARC 22 on an ERA/EOB. The denial indicates COB sequencing or “other coverage” responsibility, not a clinical documentation failure.

What is the error code CO22?

CO22 is the combination of Group Code CO and CARC 22, which communicates payer non-responsibility due to expected primary coverage elsewhere.

What does CO 22 mean?

CO-22 means the billed payer is not expected to pay as primary under COB, so payment stops until the correct payer order and prior adjudication are supplied.

What is MA04 with CO-22?

MA04 states that secondary payment cannot be considered without primary payer identity or payment information. This remark commonly appears with Reason Code 22.

What is a 22 modifier?

Modifier 22 is a CPT modifier for increased procedural services. Modifier 22 is not connected to CO-22 (CARC 22) COB denials.