Notes on payer behavior

CO-16 means read the remark code

Clearia · August 2026 · denial codes, read properly

Denial code CO-16 is the payer saying: "Claim/service lacks information or has submission/billing error(s)." What that means for your practice, and whether it's worth chasing, below.

CO-16, "claim/service lacks information which is needed for adjudication," tells you almost nothing. That's on purpose. The code is just the wrapper. The actual reason rides along next to it.

Why the code is empty on purpose

The X12 standard requires CARC 16 to be paired with a remark code (RARC) that names the missing or invalid element: a missing modifier, an invalid identifier, an attachment that never arrived. Think of the CARC as the envelope and the RARC as the letter inside. Work a CO-16 without reading the remark and you're working blind. Same goes for a whole family of codes that carry mandated remarks: CARC 96, 97, 234, and the records-request codes. On 97 the remark code even decides which of two completely different plays you run. The CO-97 note walks through that one.

The play: fix, don't argue

A CO-16 is a data problem. So the fix is a data fix:

1. Read the remark code on the electronic remittance (or on the front-end acknowledgment, if the claim got rejected before it ever reached adjudication).
2. Populate the named element.
3. Resubmit through the right door. An adjudicated claim goes back as a corrected claim, meaning a replacement (frequency code 7) that references the original claim number. A claim rejected at the front end was never adjudicated, so it goes back as a new original claim. Get this backwards and it costs you: a replacement for a claim the payer never adjudicated just bounces, and a new original for an adjudicated claim comes back as a duplicate denial.

What a CO-16 is not: an appeal. There's nothing to argue about. The payer asked for a data element, and a letter burns weeks of clock without fixing the claim. The one escalation worth writing is the case where the "missing" information was verifiably on the original claim already.

The rejected-versus-denied distinction matters for another reason too. A front-end rejection never entered adjudication, so it produces no remittance, and that means reports built on payment data may not see it at all. Rejected claims quietly age toward the filing deadline while looking like work in progress. Reconcile your submission acknowledgments against remittances so nothing sits in that gap.

What goes missing, by specialty

What's missing depends on what you bill. Anatomical modifiers (digit modifiers in hand surgery, right/left in ophthalmology and ENT). Drug identifiers on medication lines (dermatology biologics, pain management injectables). Ordering- or referring-provider identifiers on pathology and diagnostics (GI, urology). Accident and injury details on trauma claims (orthopedics, where it's often a patient-side questionnaire the payer is waiting on rather than a claim defect). The remark code tells you which. The fix looks the same every time.

The records-request cousins

Two codes in the same read-the-remark family deserve a mention, because handled correctly they're the easiest recoveries on the board: the attachment-required and attachment-deficient codes (CARC 252 and 251). These are development requests, not judgments. The payer is asking for the chart, or telling you what it got failed quality control (wrong pages, missing signature, illegible copy, wrong date range). Send exactly what the remark code names, through the payer's records channel, referencing the claim, inside the deadline printed on the request. Medicare's record requests run on a 45-day clock. Commercial deadlines vary, so read them off the letter each time. Answer completely and on time and these claims simply pay. Answer late and a clean claim turns into a denial.

Watch the clock while you fix

Corrected-claim windows are often shorter than appeal windows, payer-specific, and poorly documented. Verify per contract rather than assuming the appeal clock applies. The appeal windows themselves are mapped in the working deadlines table. One more thing. A claim that cycles through repeated CO-16s while the filing window runs down is exactly how a fixable denial turns into a timely-filing denial, which is a much worse problem.

The habit this code teaches is the cheapest upgrade any billing operation can make, in any specialty: route every denial by its remark code, not its reason code. Practices that do this rework a denial once. Practices that don't work the same denial three times.