What Is the CO-16 Denial Code?

The official X12 definition of CARC 16 is: 'Claim/service lacks information or has submission/billing error(s) which is needed for adjudication. At least one Remark Code must be provided.' That last sentence is the key to the entire denial — X12 requires the payer to attach a RARC whenever it uses CARC 16, because CARC 16 by itself says nothing actionable.

Think of CO-16 as an envelope and the RARC as the letter inside. The envelope (CARC 16) tells you a correction is needed. The letter (the RARC) tells you exactly which field to fix: a missing rendering NPI, an invalid procedure code, an absent prior authorization number, a member ID that does not match the payer's records, a missing referring provider, an invalid place-of-service code, and so on.

The Group Code matters. CO-16 pairs CARC 16 with Group Code CO (Contractual Obligation), meaning the adjustment is the provider's responsibility under the payer contract — it cannot be billed to the patient. Because CO-16 is almost always a fixable data error rather than a coverage decision, the correct response is to fix the flagged element and resubmit a corrected claim. (You will occasionally see PR-16 — Patient Responsibility 16 — covered below.)

CO-16 is informational about data completeness, not coverage or medical necessity. A claim can be perfectly documented and clinically appropriate and still deny CO-16 because one required loop or segment was missing from the 837 file. In our denial audits we typically see CO-16 at or near the top of the denial-reason frequency report for practices that have not invested in front-end scrubbing — and it is one of the most preventable categories, because nearly every CO-16 traces to a discrete, scrubbable data element.

The single biggest mistake billers make with CO-16 is treating it as a denial reason in itself and trying to appeal it. You cannot meaningfully appeal 'the claim lacks information' — the payer is correct, the claim did lack information. The productive question is which information, and only the RARC answers that.

Every CO-16 line on the 835 ERA carries one or more RARCs in the remark-code field. Most are informational N-codes and M-codes that name the missing or invalid element — for example N822 (missing element/modifier), M51 (missing/invalid procedure code), or N290 (missing/invalid rendering NPI). These drive your fix. Others are alert codes that provide regulatory or appeal-rights context rather than a field to correct (for example MA13, which warns against billing the patient for amounts not reported under a Patient Responsibility group code).

Your workflow is therefore: pull the 835, find the CO-16 line, read every RARC attached to it, map each RARC to the specific field it names, correct those fields, and resubmit as a corrected claim (frequency code 7 on institutional claims, or the payer's corrected-claim process on professional claims) — not as a new original claim, which can trigger a duplicate denial (CARC 18).

From the payer's edit engine, dozens of distinct front-end edits all resolve to the same outcome — 'I cannot adjudicate this until you fix the data' — so they all map to CARC 16 with a different RARC. That is why CO-16 has such high volume and such varied root causes: it is the catch-all for the entire front-end edit layer. The upside is that this also makes CO-16 highly preventable, because each underlying RARC corresponds to a specific scrubber rule you can turn on.

The table below decodes the RARCs you will most often see attached to a CO-16. Always read the RARC exactly as printed on your 835 — payers occasionally pair CO-16 with RARCs not listed here, and the same principle applies: map the RARC to its field, correct it, resubmit.

Build a RARC-to-fix lookup inside your denial worklist so that when a CO-16 lands, the assigned RARC auto-routes the claim to the right correction queue — coding for M51/M76/N822, enrollment for N290/N264, eligibility for N382, COB for N479. That single mapping turns the most ambiguous denial category in billing into one of the fastest to work.

Although the RARC names the specific field, CO-16 denials cluster into a handful of recurring root causes. Knowing the cause behind the RARC tells you which upstream process to fix so the denial stops recurring.

1. Missing or invalid provider identifiers (N290, N264, N265). The billing, rendering, referring, or supervising NPI is absent, transposed, or not enrolled with the payer. For Medicare, the ordering/referring provider must be enrolled in PECOS or the claim denies. This is the most common single CO-16 driver in our experience and ties directly to gaps in provider enrollment.
2. Coding errors (M51, M76, N822, N823). A deleted or invalid CPT for the date of service, a non-specific or invalid ICD-10, a missing required modifier, or a modifier that is not allowed on the code. These route to coding for correction.
3. Eligibility / member-ID mismatches (N382). The member ID, subscriber name, or date of birth does not match the payer's enrollment file — frequently because eligibility was not verified at scheduling or the patient changed plans. Front-end insurance eligibility verification prevents most of these.
4. Missing prior authorization or referral data. The service required a prior auth or referral number and it was not on the claim. (Some payers route this to CO-197 instead; see our CARC 197 explainer.)
5. Coordination-of-benefits gaps (N479). A secondary claim was submitted without the primary payer's EOB/COB adjudication data.
6. Structural 837 errors. A required loop or segment (place of service, NDC for drug lines, units, a charge amount) was missing or malformed in the EDI file itself — often a template or clearinghouse mapping problem rather than a per-claim error.

When the same RARC shows up repeatedly across many claims, the fix is upstream (a scrubber rule, an enrollment correction, an EHR template field), not claim-by-claim rework.

1. Pull the 835 ERA and read every RARC on the CO-16 line. Do not start work from the CARC alone. List each RARC attached to the line — there is often more than one.
2. Map each RARC to its field using the decoder table above. Translate 'N382' into 'member ID mismatch,' 'N290' into 'missing/invalid rendering NPI,' and so on.
3. Verify the correct value at the source. For an NPI, confirm against the NPPES registry and your payer enrollment record. For eligibility, re-run a real-time 270/271 eligibility check. For a code, validate the CPT/ICD-10 against the current code set and the date of service. Do not guess — re-pulling the correct value at the source is what makes the second submission clean.
4. Correct the flagged element(s) on the claim. Fix every RARC-named field, not just the first one, or you will get a second CO-16 with the remaining error.
5. Resubmit as a corrected claim, not a new original. On institutional (UB-04 / 837I) claims, use frequency/type-of-bill code 7 (replacement). On professional (837P) claims, follow the payer's corrected-claim process (resubmission code and original reference number). Submitting a fresh original instead of a correction risks a duplicate denial (CARC 18).
6. Confirm timely-filing room. CO-16 corrections still have to land inside the payer's timely-filing window. If repeated CO-16 loops have eaten the clock, document the original timely submission and, if needed, appeal for a timely-filing exception (see CARC 29 territory).
7. Close the loop upstream. If the same RARC recurs, fix the root process — turn on the corresponding scrubber edit, correct the enrollment record, add the missing EHR template field — so the denial stops generating. Reactive rework on CO-16 is expensive; prevention is the high-ROI play. For volume practices, outsourced denial management services can own the RARC categorization, corrections, and the prevention feedback loop end to end.

The same Reason Code 16 can appear under different Group Codes, and the Group Code changes who is responsible and what you do next. Do not work a 16 denial without first reading the Group Code in front of it.

Bottom line: With CO-16, the provider holds the correction and the patient is never balance-billed for the CO adjustment. With PR-16, the missing element relates to patient/subscriber information, but you still resolve it by reading the RARC and completing the data — not by sending the patient a bill for a denial that has not been adjudicated yet. The Reason Code 16 logic (read the RARC, fix the named element, resubmit) is identical across both Group Codes; only the responsibility flag differs.

For a deeper primer on how Group Codes, CARCs, and RARCs fit together on the 835, see the RARC glossary entry and the CARC glossary entry.

CO-16 frequently shares the worklist with adjacent denial codes that have overlapping causes. Knowing which is which prevents misrouting.

CARC 18 — Exact duplicate claim/service. The classic CO-16 trap: a biller fixes the flagged field but resubmits as a new original claim instead of a corrected claim, and the payer rejects it as a duplicate. Always resubmit CO-16 corrections through the corrected-claim path.

CARC 197 — Precertification/authorization absent. When the missing element on a CO-16 is specifically a prior authorization number, some payers route the denial to CO-197 instead of CO-16. The fix is the same conceptually (supply the missing auth and resubmit, or appeal with proof auth was obtained). See our CARC 197 explainer.

CARC 27 — Coverage terminated. Sometimes a 'member ID mismatch' RARC on a CO-16 is actually a coverage-termination problem in disguise — the ID is right but the coverage ended. Re-verify eligibility; if coverage lapsed, this becomes a CARC 27 situation, not a data-correction one.

CARC 50 — Not medically necessary. Occasionally the missing element a CO-16 RARC requests is documentation supporting medical necessity; once submitted, the determination may flip to CARC 50 if the payer finds the service not covered. Different appeal path entirely.

CARC 97 — Bundled service. Unrelated cause (NCCI bundling) but commonly adjacent on the same claim when multiple edits fire; see the 97 denial code explainer.

The discipline that keeps a CO-16 worklist fast is categorizing by RARC at intake so each denial routes to the team that owns its root cause.

The Reason Code 16 logic is identical across payers, but the most common triggers and the resubmission mechanics differ.

Medicare (MACs). The dominant CO-16 trigger on Medicare is provider-identifier and enrollment data — a rendering or ordering/referring NPI that is missing, invalid, or, critically, not enrolled in PECOS. Medicare denies ordering/referring claims (lab, imaging, DME, home health) when the referring provider is not PECOS-enrolled, surfacing as CO-16 with an NPI RARC (often N290 / N264 / N265). Confirm PECOS enrollment first, then resubmit through the MAC's corrected-claim or reopening process.

Medicaid (state programs and MCOs). Medicaid CO-16s skew toward member-ID and eligibility mismatches (N382), because Medicaid eligibility changes month to month, and toward state-specific required fields (taxonomy codes, attending NPI on certain claim types). Each state program and each MCO can have its own required elements and corrected-claim portal — verify the state's companion guide. Eligibility re-verification at the date of service is the highest-yield prevention step.

Commercial payers. Commercial CO-16s most often involve missing prior authorization numbers, missing referral data on HMO products, invalid modifiers (N822/N823), and COB gaps (N479) on secondary claims. Most major commercial payers accept corrected claims electronically with a resubmission code and the original claim reference number; some require a proprietary form. Always check the payer's companion guide — submitting a correction the wrong way produces a duplicate (CARC 18) instead of an adjudication.

Across all three, the universal accelerant is front-end scrubbing: an enrollment-validated provider table, a real-time eligibility check, and a code/modifier scrubber catch the overwhelming majority of CO-16 RARCs before the claim ever leaves the practice.

CO-16 is the most preventable major denial category in billing because every underlying RARC corresponds to a discrete, checkable data element. A clean front end converts CO-16 from a recurring rework cost into a near-zero line on the denial report.

1. Enrollment-validated provider table. Keep billing, rendering, referring, and supervising NPIs validated against NPPES and your payer enrollment records, with PECOS status flagged for Medicare referrers. This kills the N290 / N264 / N265 family at the source — exactly what robust provider enrollment services maintain.

2. Real-time eligibility verification. A 270/271 check that confirms the member ID, plan, and active coverage before the visit eliminates most N382 mismatches and surfaces coverage-termination problems before they become CO-16 or CARC 27 denials.

3. Code and modifier scrubbing. Validate CPT/HCPCS against the current code set and date of service, ICD-10 to highest specificity, and required modifiers against payer policy and NCCI — catching M51, M76, N822, and N823 pre-submission. This is the same discipline that drives a high clean claim rate.

4. Structural EDI edits. Configure clearinghouse edits for required loops/segments — place of service, units, NDC on drug lines, COB segments on secondaries — so structural 837 errors are caught before the payer sees them.

5. RARC-keyed feedback loop. Track CO-16 denials by RARC monthly. A spike in one RARC points to a specific broken upstream process — a lapsed enrollment, a missing template field, an outdated scrubber rule — and fixing the process fixes hundreds of future claims at once.

Practices that operationalize these five disciplines typically move CO-16 from a top-three denial reason to a rounding error and recover the staff hours previously spent on RARC-by-RARC rework. The economics favor prevention overwhelmingly: a corrected-claim cycle costs real labor and delays cash, while a scrubber rule costs nothing per claim once configured.