CO-15 Denial Code: Why It’s Deactivated and How to Fix Auth Number Denials in 2026

Key Takeaways

• X12 defines CARC 15 as “The authorization number is missing, invalid, or does not apply to the billed services or provider.”
• X12 retired the code. The official list shows Start: 01/01/1995, Last Modified: 11/01/2017, and Stop: 05/01/2018.
• CO means Contractual Obligation, so the provider absorbs the adjustment and the patient can’t be billed for it.
• Most of these denials resolve with a corrected claim, not an appeal, because the authorization usually exists and the number on the claim is wrong.
• Three active codes now carry the same failure modes: CARC 197 for an absent authorization, CARC 284 for a number that does not apply to the billed services, and CARC 296 for a number that does not apply to the provider.

Quick answer. The co 15 denial code combines group code CO with Claim Adjustment Reason Code 15, which X12 defines as an authorization number that is missing, invalid, or inapplicable to the billed services or provider. X12 stopped the code on May 1, 2018, so a claim carrying it in 2026 needs a corrected claim in almost every case.

This guide is for AR specialists, billers, and practice managers working an authorization denial on a remittance today. Every code description below comes from the X12 external code list. Every claim placement rule comes from CMS documentation.

What the CO-15 Denial Code Means: The Official X12 Definition

The Verbatim CARC 15 Description

X12, the ANSI-accredited body that maintains all HIPAA-mandated claim adjustment reason codes, publishes this description for CARC 15:

The authorization number is missing, invalid, or does not apply to the billed services or provider.

In billing terms, the payer looked for an authorization number on the claim and found a problem with it. Pull up the X12 Claim Adjustment Reason Codes list and one detail stands out that most guides skip.

That description covers three separate failures, not one:

• Missing. No authorization number reached the payer on this claim.
• Does not apply to the billed services. A number came through, but it covers different procedure codes than the ones billed.
• Does not apply to the provider. A number came through, but it belongs to a different rendering provider, NPI, or location.

Those three failures need three different fixes. Track which one applies before touching the claim, because sending a corrected claim for the wrong reason wastes a submission and burns time on the filing clock.

One more correction worth making. Some published versions of this code open with the phrase “Payment adjusted because.” That prefix doesn’t appear in the current X12 text. The description begins with “The authorization number.”

What the CO Prefix Means for Patient Billing

CO stands for Contractual Obligation. Per X12, group codes assign responsibility for the adjustment amount, and CO puts that amount on the provider under the terms of the payer contract.

The practical result: your practice writes off the balance and can’t transfer it to the patient. Bill a patient for a CO adjustment and you’ve broken the contract you signed with that payer.

X12 maintains five group codes:

That CR caveat matters if you work older transaction sets or migrate historical data. X12 states it in the group code notes, and a CR adjustment arriving on a current 835 signals a mapping problem on the payer side.

The 2026 Status: CARC 15 Is a Deactivated Code

What the X12 Code List Shows

CARC 15 carries three date fields on the X12 external code list: Start: 01/01/1995, Last Modified: 11/01/2017, and Stop: 05/01/2018. A Stop date means X12 deactivated the code. It sits in the Deactivated filter of the published list rather than the Current filter.

One detail keeps this from becoming speculation. X12 attaches an explicit replacement note when a replacement exists. Code 38 carries this note in the published list:

CARC codes 242 and 243 are replacements for this deactivated code.

Code 15 carries no such note. X12 retired it without naming a successor, so nobody can state that another code officially replaced it. What the maintenance record does show comes next.

Why Payers Still Send CO-15 in 2026

Payers still send the co 15 denial code in 2026, and two explanations hold up.

The first is standards-compliant. CMS instructs Medicare contractors not to use deactivated codes in original business messages past the deactivation date. The same CMS Transmittal R1862CP also requires that a deactivated code be accepted in derivative messages when a prior payer used it before deactivation and adjudicated ahead of Medicare.

Coordination of benefits creates a legitimate path for an old code to travel forward.

The second explanation is operational. Commercial adjudication engines and their code maps update on their own schedules, and some still emit CARC 15 for authorization problems.

Neither explanation means the code is prohibited. CMS governs what its own contractors originate, and commercial payer behavior varies by plan.

What Deactivated Status Means for Your Claim

A CO-15 on a 2026 remittance tells you something beyond the denial itself. The payer described an authorization problem using a code X12 retired eight years ago, which means the remittance carries less detail than a current code would have supplied.

CARC 284 would have told you the number failed against the billed services. CARC 296 would have told you it failed against the provider. CARC 15 tells you neither, so your team reconstructs that answer from the claim and the approval letter.

Work the failure mode rather than the code string. The next section maps each mode to the active code that describes it.

Where CO-15’s Three Failure Modes Live Now: CARC 197, 284, and 296

The X12 Maintenance Timeline

The published dates on the X12 list form a clear sequence around the deactivation:

The co 15 denial code described three failures. Each one now has a dedicated active code: 197 for absent, 284 for a service mismatch, and 296 for a provider mismatch.

That pattern sits in the maintenance record as a correlation. X12 never designated any of them as the official replacement, so treat the mapping as operational guidance rather than a formal crosswalk.

The Authorization Code Family

CARC 197 runs on a different recovery track because no authorization exists to correct. The CO-197 authorization denial playbook covers the retroactive authorization workflow and the appeal structure for that scenario in full.

How CO-15 Appears on the 835 Electronic Remittance Advice

Reading the CAS Segment: Group Code Plus CARC Plus RARC

The co 15 denial code is a pairing, not a single code. It appears in the CAS segment of the 835 transaction, where CO is the group code and 15 is the claim adjustment reason code. One or more remark codes travel alongside it.

Read all three before you open the claim. The group code tells you who absorbs the money. The CARC tells you the category of problem. The RARC names the specific data element that failed.

That third code carries extra weight on a retired CARC. Because code 15 collapses three failure modes into one string, the remark code is frequently the only element on the remittance that separates a missing number from a mismatched one.

RARC Pairings That Point at the Authorization

Two remark codes verified against the X12 remark code list speak directly to authorization problems:

A note on remark code accuracy. Two rows here beat six rows built from memory. Every remark code your team relies on should be checked against the current X12 remark code list before it goes into a workflow document, because payers pair codes differently and the list changes three times a year.

When a CO-15 arrives with no remark code at all, the payer has handed you a retired CARC and zero specificity. That claim needs a phone call, and Section 13 gives you the script. For the mechanics of how remark codes and reason codes divide the work on a remittance, see how remark codes pair with CARCs.

Why the CO 15 Denial Code Fires: Six Root Causes

Cause 1: The Authorization Number Never Reached the Claim

Blank field on a service that required approval. Somebody secured the authorization, filed the letter, and nobody moved the number onto the claim. This one overlaps CARC 197 territory, so confirm an authorization exists before you treat it as a data error. If none exists, you’re working a 197 recovery instead.

Cause 2: A Digit Was Transposed or the Number Got Truncated

The number is there and it’s wrong. A biller retypes 14 characters from a fax and swaps two of them, or a field with a 12-character limit clips the last two digits off a 14-character authorization. That’s the most common true CO-15 cause, and the cleanest corrected-claim fix in the set.

Cause 3: The Service Fell Outside the Approved Date Window

Performed too late, or performed too early. Everybody’s watching expiry dates. Fewer teams catch the reverse problem, where a case moves up on the schedule and the patient gets treated two days before the authorization start date. Both directions produce the same denial.

Cause 4: The Auth Does Not Cover the CPT or HCPCS Billed

Approved for one procedure, billed for another. A surgeon opens the case, finds more than the imaging showed, and the coder appends procedures the original authorization never named. Same patient, same day, same provider, and the authorization still fails against the billed codes.

Cause 5: The Auth Belongs to a Different Provider, NPI, or Location

Right authorization, wrong rendering provider. A physician leaves the group and the case transfers, or the procedure moves to a second site. The authorization stays tied to the original NPI, TIN, or service location. Payers also flag mismatches like these during authorization integrity reviews, which slows resolution further.

Cause 6: The Number Landed in the Wrong Field or the Wrong Loop

Correct number, wrong place on the transaction. Your billing system writes the authorization to a segment the payer doesn’t read, uses the wrong qualifier, or stamps it at both claim level and service line. The authorization checks out and the claim still denies. Section 11 covers exactly where the number belongs.

Most practices see one or two of these six on repeat rather than all six. Pull 90 days of authorization denials, sort them by cause, and the pattern shows up in the first hour.

Five of these six causes resolve with a corrected claim. Only the first one, where no authorization exists at all, routes anywhere near an appeal.

Code 15 Disambiguation: Different Code Sets, One Number

The Code 15 Comparison Table

Search “code 15” in medical billing and you land on several unrelated identifiers. They live in different code sets, appear on different documents, and mean different things.

The two that trip up billing teams most. RARC M15 is a bundling code. RARC MA15 is a claim-split alert. Neither one has anything to do with prior authorization, so a search for “M15 denial code” that lands you on an authorization page has sent you to the wrong answer.

Why Your Remittance and Your Claim Form Use Different Code Sets

The confusion has a structural cause. CARCs and RARCs live on the remittance, which travels from the payer to you. Condition codes and value codes live on the claim form, which travels from you to the payer. Same numbers, opposite directions.

Ask one question before you look anything up: which document am I holding? A number on an 835 or an EOB is a remittance code. A number on a UB-04 is a claim form code. That single check resolves most of the confusion before a lookup starts.

Pre-adjudication rejections follow a third set again, covered in the guide to clearinghouse rejection codes.

CO-15 vs CO-B15: Two Unrelated Codes That Look Alike

What CO-B15 Means

X12 publishes this description for CARC B15:

This service/procedure requires that a qualifying service/procedure be received and covered. The qualifying other service/procedure has not been received/adjudicated.

The payer is telling you a prerequisite service is missing from its records, so the service you billed can’t stand on its own. Nothing about authorization shows up in that description.

B15 is active. The X12 list shows Start: 01/01/1995 and Last Modified: 07/01/2017, with no stop date. That contrast alone separates the two codes: one is retired, one is current.

Two scenarios produce a cob15 denial code in practice. A component code goes out without the primary procedure it attaches to, often after a coder splits an encounter across two claims. Or a DME supplier bills an item with no matching practitioner claim on file for the same date of service.

CO-15 and CO-B15 Side by Side

The two codes don’t share a workflow. One sends you to the authorization file. The other sends you to the claim history.

If you searched for cob15 or co-b15 denial code reason and landed on a CO-15 page, you need the qualifying service answer above, not the authorization workflow below.

CO-15 vs CO-16 vs CO-197: Which Code Are You Working?

The Three-Way Comparison

CO-16 works as a wrapper. The reason code says information is missing and the paired remark code names the specific element, which sometimes points at the authorization field. That overlap is why an auth problem occasionally arrives as CO-16 rather than an authorization-specific code, and the CO-16 missing information denials guide maps every remark code that pairs with it.

Why This Distinction Changes Your Next Action

The co 15 denial code, CO-16, and CO-197 route to three different queues on three different clocks. Send a CO-15 to appeals and you’ll spend the appeal window arguing a decision the payer made correctly on the data it received. The claim needed a corrected number, and the payer upholds the denial.

Run it the other way and you’ll get the same result. Resubmit a CO-197 as a corrected claim and it denies again, because no authorization existed the first time and none exists now.

Whether a corrected claim or an appeal fits depends on which code the payer sent and what the paired remark code says. Read the group code, the CARC, and the RARC together, and the routing answers itself.

Few billing teams keep a written routing rule for these three codes, which is why they end up in the same queue. A 90-day denial export sorted by CARC shows the split in minutes.

Corrected Claim or Appeal? The CO 15 Denial Code Decision Rule

Why Most of These Denials Are Not Appeal Cases

An appeal argues the payer decided wrong. A corrected claim concedes the payer decided right on the data it received and supplies better data. The co 15 denial code sits in the second category almost every time, because the code describes a problem with the authorization number rather than the authorization itself.

Getting that backward costs money. Appeal windows run shorter than timely filing windows at most payers, and an appeal filed on a data error returns an upheld denial. Nothing about the claim changed, so the payer reaches the same conclusion and your window closes on you.

The Four-Question Routing Test

Work these in order. The first “no” tells you where the claim goes.

1. Does a valid authorization exist for this patient, this service, and this date? A no means you’re working a CARC 197 recovery rather than a CO-15. Route it to retroactive authorization.
2. Is the number on the claim identical to the number on the approval letter? A no means transposition or truncation. Route it to a corrected claim.
3. Does the authorization cover the CPT or HCPCS billed and the provider who rendered the service? A no means a scope or provider mismatch. Route it to a corrected claim if the right authorization exists, or to a new authorization request if it doesn’t.
4. Did the number transmit in the correct loop and segment on the outbound claim? A no means a placement failure. Route it to a corrected claim and open a scrubber rule so it stops repeating.

When an Appeal Is the Right Path

One scenario earns an appeal. A valid authorization existed, it matched the service and the rendering provider, it transmitted in the correct field, and the payer denied anyway. That’s a payer adjudication error, and it belongs in appeals with the approval letter attached and the outbound claim as evidence.

Multi-level appeals and peer-to-peer escalation on those cases are what denial management services handle day to day.

Corrected claim eligibility, resubmission windows, and appeal deadlines vary by payer and by contract. Check the provider manual for the specific plan before assuming any of them, because no national rule governs all three.

Separating the data fixes from the genuine payer errors across a full quarter of denials is the analysis most in-house teams never find time for, and it’s usually where the recoverable money hides.

Where the Authorization Number Goes on the Claim

Most co 15 denial code fixes come down to one question: did the number reach the field the payer reads? Three claim formats answer that question differently, and the paper form is the one most guides stop at.

Electronic Professional Claims: Loop 2300, REF01 Equals G1

On an 837 professional claim, the tracking number belongs in the 2300 Claim Information loop, inside the Prior Authorization REF segment, with REF01 set to the G1 qualifier and REF02 carrying the number. CMS Prior Authorization Operational Guide ties that placement directly to the ASC X12 837 Technical Report 3.

Loop 2300 sits at claim level, so a number placed there applies to every service line on the claim. Your biller doesn’t need to read EDI to use this. They need to know which field their software writes to, then confirm it maps to the right segment.

Electronic Institutional Claims and the 14-Byte Field

Institutional claims use the same construction. CMS Hospital OPD guidance specifies loop 2300 REF02 with REF01 equal to G1, and adds a length rule: the treatment authorization field carries a 14-byte tracking number.

The operational warning matters more than the syntax. Institutional claims submitted without blanks or valid data in that field get rejected outright, which means the claim never reaches adjudication and has to be corrected and resubmitted before anything else happens.

Facility billers rarely find this in a denial-code guide, because most of them address the CMS-1500 and stop there.

Paper Claims: Item 23 on the CMS-1500

Paper submission puts the authorization in Item 23, and MAC guidance sets a position rule. The number occupies the first 14 positions of the field, and any other data starts at position 15.

Treat paper as the legacy path now. Most competitor guides lead with Item 23 and never mention the electronic loops, which leaves the reader with the answer for the smallest share of their claim volume.

The Duplication Rule Most Systems Get Wrong

CMS states that a number submitted in the 2300 loop applies to the entire claim unless a REF segment in the 2400 service line loop overrides it. That override exists for a specific case: a service line carrying a different authorization than the rest of the claim.

Some billing systems stamp the identical number in both places automatically. A valid authorization can still create trading partner edit friction when it appears twice, and the resulting denial looks inexplicable because the authorization itself checks out.

Pull the outbound 837 and look at it. The number should sit at claim level, and at service line only when that line carries a different authorization.

How to Resolve a CO-15 Denial: Seven Steps

Step 1: Pull the 835 and Read Both the CARC and the RARC

Open the remittance before you open the claim. The reason code gives you the category and the remark code names the failed element. On a retired code, that remark code is often the only specificity the payer supplied, so working without it means guessing.

Step 2: Confirm an Authorization Exists for This Patient, Service, and Date

Check the authorization log or the payer portal before calling anyone. If no authorization exists at all, stop here. That is a CARC 197 recovery running on a retroactive authorization clock, and it needs a different workflow than the one below.

Step 3: Compare the Number on the Claim Against the Approval Letter

Read it character by character, out loud if you have to. Transposition and truncation account for the largest share of true CO-15 denials, and both hide from a quick visual scan. A 14-character string with two swapped digits still looks correct at a glance.

Step 4: Verify the Auth Covers the Billed Code and the Rendering Provider

Match the authorized CPT or HCPCS against what went out, and the authorized NPI against the rendering NPI. A mismatch on the service points at CARC 284 behavior. A mismatch on the provider points at CARC 296. The retired code hid that distinction from you.

Step 5: Check the Field Placement on the Outbound Claim

Pull the 837 your clearinghouse transmitted and confirm the number sits in loop 2300 with the G1 qualifier. This step catches the denials that make no sense on paper, where the authorization is valid, current, and matched, and the claim denied anyway.

Step 6: Correct and Resubmit, or Route to Appeal

Run the four-question routing test from Section 10 and act on the answer. Replacement claims use frequency code 7, though resubmission mechanics and required identifiers vary by payer, so confirm the format that specific plan accepts before you send.

Step 7: Log the Root Cause and Feed It Back to the Front End

Categorize the denial against the six causes and send the pattern to whoever owns authorization capture. A co 15 denial code that repeats is a workflow failure, and no amount of AR effort fixes a workflow from the back end.

Keep the approval letter, the corrected claim confirmation, and the payer reference number together in one place. A second denial on the same claim requires all three, and reconstructing them three weeks later takes longer than filing them took.

What to Ask the Payer When You Call About a CO-15 Denial

Before You Dial

Have these six items in front of you and nothing else:

• The 835 or EOB showing the reason code and any remark code
• The claim number
• The approval letter with the authorization number
• The date of service
• The billed CPT or HCPCS codes
• The rendering provider NPI

The Eight Questions

1. “Which specific remark code was attached to this adjustment?” The retired reason code told you nothing. The remark code narrows it.
2. “Does an active authorization exist in your system for this patient, this date of service, and this procedure code?” This separates a data error from a missing authorization.
3. “What authorization number do you show on file? Please read it back digit by digit.” This one question resolves more of these denials than any other.
4. “Which rendering provider NPI is that authorization assigned to?” Catches the provider mismatch that CARC 296 would have named.
5. “What date range does the authorization cover?” Catches both expiry and a service performed before the start date.
6. “Which procedure codes does the authorization cover?” Catches the scope mismatch that CARC 284 would have named.
7. “Do you accept a corrected claim for this denial, and what submission method do you require?” Payers differ on this, and sending the wrong format restarts the cycle.
8. “What is the deadline for correction or appeal on this claim, and what is my call reference number?” Get both before you hang up.

Question three does the heaviest lifting on a co 15 denial code. Reading the number back one character at a time surfaces a transposition in about fifteen seconds, and most billers skip it because they assume the number on their screen is the number that transmitted. It isn’t always.

What to Document From the Call

Write down the representative name, the call reference number, the date and time, the authorization number exactly as the payer stated it, and the deadline they gave you. A second denial on the same claim makes that record the difference between a recovery and a write-off.

Payer Behavior: CO-15 Across Medicare, Medicaid, and Commercial Plans

Medicare Fee-for-Service and the UTN Field

CMS instructs its contractors not to originate deactivated codes past the deactivation date. A CO-15 arriving from Medicare fee-for-service in 2026 runs against that instruction, and it’s worth raising with the MAC rather than working around it.

The Medicare mechanics that do apply center on the unique tracking number. Noridian UTN field requirements state that institutional claims submitted without blanks or valid data in the treatment authorization field get rejected, and those claims need correction and resubmission before adjudication happens at all.

Treat a co 15 denial code from Medicare as a diagnostic. Medicare remittances should be carrying the active authorization codes, so an old one tells you something about the system that generated the file.

Medicaid Managed Care and the Dual Rule Layer

Medicaid MCOs layer their own authorization requirements on top of state Medicaid rules, so a single claim answers to two sets of requirements. A service authorized under state rules can still fail an MCO-specific requirement your team never saw.

State Medicaid programs bind their encounter data to active standard reason codes from the X12 external code source. A retired code arriving from a Medicaid MCO is worth flagging to the plan, because their own submission standards likely prohibit it.

Commercial Payers and Legacy Code Maps

Commercial plans are where this code still shows up. Their adjudication engines and internal code maps update on their own schedules, and a retired CARC can survive in a mapping table for years after X12 stops it.

The cost to your team is specificity. When a commercial remittance carries a deactivated reason code, you lose the detail that CARC 284 and CARC 296 would have supplied, and someone on your staff reconstructs it by hand from the claim and the approval letter.

Site of Service as an Authorization Trigger

The CPT code, the payer, and the plan drive authorization requirements. The place of service code doesn’t trigger authorization by itself, though plenty of billing teams assume it does.

A hospital outpatient setting changes reimbursement and it changes which claim carries which data. It doesn’t create an authorization requirement on its own, as the guide to POS 22 authorization rules works through in detail. Check the procedure code against the specific plan instead of assuming the setting decides it.

Preventing the CO 15 Denial Code: Five Front-End Controls

Control 1: Verify the Authorization Requirement Before Scheduling

Owner: scheduling. Confirm whether the specific plan requires authorization for the specific procedure before the appointment goes on the calendar, not the week the claim goes out. Requirements differ between two plans from the same carrier. This control prevents Cause 1, the claim that goes out with a blank field.

Control 2: Capture the Full Number at the Source

Owner: the authorization team. Record the number once, at approval, into a field long enough to hold 14 characters. No retyping from a fax, no writing it on a sticky note, no verbal confirmation without a written follow-up. Building that capture step into prior authorization verification removes Causes 2 and 6 at the same time.

Control 3: Validate Auth Against Code, Provider, and Date Before Submission

Owner: charge entry. Run a three-point match on every claim carrying an authorization. Authorized code against billed code. Authorized NPI against rendering NPI. Date of service inside the approved window. Three checks, thirty seconds, and Causes 3, 4, and 5 stop reaching the payer.

Control 4: Track Expiry With a Lead Time, Not a Deadline

Owner: the authorization team. Flag renewals on a lead time measured in business days before the authorization expires, not on the expiry date. A same-day flag gives nobody room to work. Track the start date too, because a case that moves up the schedule can land before the window opens.

Control 5: Add a Scrubber Rule for Field Placement

Owner: billing operations. Write a rule that confirms the authorization number populates at claim level and doesn’t duplicate at service line unless that line carries a different authorization. This is the control nobody builds, and it catches the authorization denials that look impossible to explain.

Your front desk and authorization staff aren’t careless. They’re handling volume, and volume beats memory. Five controls that fire on their own outperform any training program that depends on somebody remembering a step while the waiting room fills up.

Most practices run two or three of these five and can’t say which two. A pattern review across a quarter of denials shows which controls are live and which ones exist only on paper.

Working Aged Authorization Denials Before the Window Closes

Why Deactivated-Code Denials Sit Unworked

These denials age for a reason that has nothing to do with staffing. A reason code that doesn’t appear in a current code list is one your denial software may carry no rule for. It drops into an unmapped or miscellaneous bucket, no queue owns it, and it sits.

That failure mode differs from the usual one. Practices that work every other denial category on schedule still carry authorization balances from retired codes, because nothing in the workflow ever picked them up.

Triage Order for an Aged Queue

Work a backlog in this order:

1. Sort by proximity to the correction or filing deadline. A data fix has no value after the window closes, so the clock outranks the dollar amount.
2. Sort what remains by dollar value. Correcting a $90 claim takes the same effort as correcting a $9,000 claim.
3. Group the whole queue by root cause. One systemic failure usually explains a large share of it, and a single fix clears many claims.
4. Work the systemic group first, then the one-offs. Fixing the pattern also stops the queue from refilling behind you.

Filing and correction windows vary by payer and contract, so the deadline sort depends on your own payer matrix rather than a national number. Structured aged AR recovery runs this triage against the payer-specific windows instead of a generic aging report.

An aged authorization queue is usually one workflow failure repeated across dozens of claims. Finding the pattern takes an afternoon. Working the claims one at a time takes a month and leaves the cause in place.

What Changed in 2026: Denial Specificity, PA APIs, and Code Set Discipline

Mandatory Denial Reason Specificity

The CMS Interoperability and Prior Authorization Final Rule changed what payers owe you on a denied authorization. Per the CMS-0057-F fact sheet, beginning in 2026 impacted payers must provide a specific reason for denied prior authorization decisions, regardless of the method used to send the request. Portal, fax, email, mail, or phone, the specificity requirement applies.

That gives your team leverage. A vague authorization denial from an impacted payer is now easier to push back on, and the specific reason they supply becomes usable material in a correction or an appeal.

The direction of travel points one way. Payer denial decisions are getting more specific under federal rule, and outside oversight is pushing the same direction. OIG Medicare Advantage denial findings documented plans overturning roughly 75 percent of their own appealed denials, which raised questions about how those denials got issued in the first place.

The Prior Authorization API Timeline

The same CMS fact sheet sets the technical deadline. Impacted payers must implement a Prior Authorization API that identifies covered items and services, surfaces documentation requirements, and returns approval, denial with a specific reason, or a request for more information. That requirement begins January 1, 2027.

For a practice, the change is transcription. Authorization numbers moving through a structured electronic channel remove the fax-to-keyboard step that produces most transposition denials. Treat it as a planning input for next year, not a workflow change for this month.

Why Code Set Currency Matters More Now

Three rules point the same direction. HIPAA requires payers to use approved code sets rather than proprietary adjustment codes. CMS instructs its contractors not to originate deactivated codes. State Medicaid programs bind encounter data to active standard reason codes, as MassHealth CARC guidance spells out for its managed care entities.

A retired reason code arriving in 2026 runs against all three. That makes it a claim to fix and a signal to notice, which is the whole argument of this guide in one sentence.

How One O Seven RCM Works Authorization Denials

Our team pulls the remittance and reads the group code, the reason code, and the remark code before anyone opens the claim. A co 15 denial code won’t classify itself, so we classify the denial by failure mode instead: missing number, service mismatch, provider mismatch, timing, or placement.

Those five modes route to two queues on two clocks. Data corrections go to corrected claims with the payer-specific format and identifiers already confirmed. Genuine payer adjudication errors go to appeals with the approval letter and the outbound transaction attached as evidence.

Root causes get logged against the front-end step that produced them and routed back to whoever owns that step. A repeating authorization denial is a workflow problem, and working it from AR forever costs more than fixing the capture point once.

Our coders and billers hold AAPC certification, we operate under HIPAA-compliant workflows with a BAA signed before any access, and we work claims across all 50 states.

About This Guide

Carter Hensley writes on denial management and revenue cycle operations for One O Seven RCM. Every reason code description in this guide comes from the X12 external code list rather than a secondary summary, and every claim placement rule comes from CMS documentation. Both sources are linked above so you can check them yourself.

If your denial file has authorization denials nobody has classified by failure mode, that’s a straightforward review and it usually surfaces recoverable claims still inside their correction window. We can walk your last 90 days with you when the timing works.

CO 15 Denial Code: Frequently Asked Questions

What is the CO-15 denial code?

The co 15 denial code pairs group code CO with Claim Adjustment Reason Code 15, which X12 defines as “The authorization number is missing, invalid, or does not apply to the billed services or provider.” CO means Contractual Obligation, so the provider absorbs the adjustment and can’t bill the patient. The description covers three separate failures: no number reached the claim, the number doesn’t match the billed services, or the number doesn’t match the rendering provider. Each one needs a different fix.

Is CARC 15 still an active code in 2026?

No. The X12 external code list shows CARC 15 with Start: 01/01/1995, Last Modified: 11/01/2017, and Stop: 05/01/2018, which places it in the deactivated section rather than the current one. Payers still send it, and there are two reasons why. CMS requires deactivated codes to be accepted in derivative coordination of benefits messages, and commercial adjudication systems update their code maps on their own schedules. X12 attached no replacement note to code 15, so no other code officially succeeded it.

What does COB15 or CO-B15 mean?

CO-B15 is a different code. X12 defines CARC B15 as “This service/procedure requires that a qualifying service/procedure be received and covered. The qualifying other service/procedure has not been received/adjudicated.” The payer is missing a prerequisite service, not an authorization number. B15 is active with no stop date, while CARC 15 was deactivated in 2018. If you searched cob15 denial code reason and you need the qualifying service answer, check whether the primary procedure was billed and adjudicated for that patient.

Can you bill the patient for a CO-15 denial?

No, under standard group code rules. Per X12, group codes assign responsibility for the adjustment, and CO means Contractual Obligation, which places the amount on the provider under the payer contract. CMS states that Medicare beneficiaries may be billed only when group code PR is used. For commercial plans, the specific contract governs, so read your participation agreement before making a patient-liability decision. Transferring a CO adjustment to a patient balance without contractual authority creates a compliance exposure.

Should I file a corrected claim or an appeal for CO-15?

A corrected claim, in most cases. An appeal argues the payer decided wrong, while this denial usually means the payer decided right on bad data. Confirm the authorization exists, compare the number character by character against the approval letter, verify it covers the billed code and rendering provider, and check that it transmitted in the correct field. An appeal only fits when a valid authorization matched everything and transmitted correctly. Corrected claim eligibility and deadlines vary by payer, so confirm in the provider manual.

Where does the authorization number go on an 837 claim?

On an 837 professional claim, CMS specifies the 2300 Claim Information loop, in the Prior Authorization REF segment, with REF01 set to the G1 qualifier and REF02 holding the number. A number in loop 2300 applies to the whole claim unless a REF segment in the 2400 service line loop overrides it, and that override should only carry a different authorization. Institutional claims use the same loop 2300 REF02 construction with a 14-byte treatment authorization field. Paper CMS-1500 claims use Item 23.

What is the difference between CO-15 and CO-197?

CARC 197 means no authorization exists at all, defined by X12 as “Precertification/authorization/notification/pre-treatment absent.” CARC 15 means an authorization number was expected or submitted and it failed validation. The distinction changes your workflow. A 197 routes to a retroactive authorization request or an appeal with medical necessity documentation. A 15 routes to a corrected claim with the right number in the right field. Sending a no auth denial code down the corrected-claim path produces a second denial for the same reason.

Is condition code 15 the same as CO-15?

No. They belong to different code sets and travel in opposite directions. CARC 15 is an X12 claim adjustment reason code that appears on the remittance the payer sends you. Condition code 15 is a NUBC UB-04 code reported on the institutional claim form you send the payer, in Form Locators 18 to 28, and it’s payer-assigned rather than provider-submitted. Value code 15 is a third, separate UB-04 field. Confirm current condition and value code definitions against the NUBC manual or your MAC.

What does reason code 015 mean?

Reason code 015 is how some payer portals and internal EOB displays render CARC 15, padded to three digits. The meaning is identical: the authorization number is missing, invalid, or does not apply to the billed services or provider. The code carries the same deactivated status, with a stop date of May 1, 2018 on the X12 list. If your payer portal shows 015 rather than 15, work it exactly the way you would work any authorization number denial.

Does a corrected claim restart the timely filing clock?

Generally no. Payers typically treat a corrected claim as a continuation of the original submission rather than a new claim, which is why frequency code 7 identifies it as a replacement. Treatment varies by payer and contract though, and some plans apply separate correction windows that run shorter than the filing limit. Check the provider manual for the specific plan before you rely on the original submission date. Hold on to the original claim number and the submission confirmation, because you’ll need both if the payer disputes timeliness.