Denial reason codes worth building a workflow around

A denial code is not an instruction. CO-16 and CO-197 carry the same group code — contractual obligation — and both stop a claim from paying. One is a documentation gap closed at intake. The other is a claim that should never have been submitted. Routing both to the same “resubmit and resend” queue is how a practice spends a quarter reworking denials that were preventable for two completely different reasons.

The fix is not memorizing more codes. It is a workflow that routes by what caused the denial — because the code on the remittance line tells you almost nothing about that on its own.

The code is a layer, not an answer

Every line on an 835 remittance carries a group code (CO, PR, OA, PI) paired with a Claim Adjustment Reason Code, and often a Remittance Advice Remark Code underneath it. The CARC set is maintained as one national list rather than payer by payer, which is why the same handful of codes keep recurring across every payer's remittances (X12's Claim Adjustment Reason Code list). What varies is which code fires and whether the remark code underneath it gives a billing team anything to act on.

CO-16 shows why that distinction matters. X12 defines it as “Claim/service lacks information or has submission/billing error(s),” and its own usage note requires that at least one remark code be provided alongside it — the code is built to pair with something more specific, not to be read alone. A team that logs CO-16 without capturing which remark code rode with it has recorded that something was wrong and nothing about what.

Four codes, four different root causes

Treating every denial as one undifferentiated “rework” item lumps together root causes that have nothing in common:

• CO-197 — “Precertification/authorization/notification/pre-treatment absent,” in X12's current definition. This is the one denial here that is fully knowable before the claim goes out: authorization status does not change between the visit and the 837. A workflow that checks authorization at readiness, rather than after a denial, turns CO-197 from a rework item into a submission that never happens.
• CO-50 — services X12 describes as non-covered because they are “not deemed a ‘medical necessity’ by the payer.” Unlike CO-197, this is a judgment call the payer has already made. The only path forward is a clinical-documentation appeal, not a corrected resubmission — routing it to a billing queue instead of a clinical reviewer burns the one window that could overturn it.
• CO-96 — X12's “Non-covered charge(s).” This is a benefit-design fact, not a documentation or authorization question: the service is excluded from that plan. No amount of better coding fixes it; the fix is catching the exclusion before the next visit, not after this claim.
• CO-27 — “Expenses incurred after coverage terminated,” per X12. This is an eligibility failure wearing a claims denial's clothing: the claim was correct for coverage that no longer existed on the date of service.

Four codes, four different teams, four different fixes — and a single denials dashboard that reports them as one number tells a practice nothing about where to put the next hire.

The volume is not correcting itself

This is not a problem that improves with tenure or claim volume alone. MGMA's most recent DataDive benchmarking showed a single-specialty aggregate rate of 8% for claims denied on first submission — the same rate documented in 2019 — and a March 2024 MGMA Stat poll of medical group leaders found 60% reporting higher denial rates than the year before, against only 11% reporting a decrease (MGMA Stat). A separate survey puts the current picture at 41% of providers reporting denial rates of at least 10%, per Experian Health's third annual 2025 State of Claims survey (Managed Healthcare Executive). None of that volume sorts itself by root cause; a practice still has to do the sorting.

HFMA's Claim Integrity Task Force built its denial-metrics framework around exactly this gap, organizing denial categories by root cause — medical necessity and level of care, eligibility and coordination of benefits, authorization — rather than by payer or dollar amount. The stakes for getting that categorization right are not small: HFMA frames healthcare's administrative complexity overall as a “$265.6 billion savings opportunity,” and a category structure that cannot tell a documentation gap from a benefit exclusion cannot close any share of it (HFMA).

What a workflow actually requires

Turning a CARC into a routing key means knowing, for each code, which of three questions it answers: was this knowable before submission, is this a clinical judgment to appeal, or is this a coverage fact that changed? CO-197 and CO-27 answer the first — they belong in readiness checks, not denial queues. CO-50 answers the second — it belongs with a clinical reviewer, not a biller. CO-16 answers neither until its remark code is captured, which is why that pairing has to be mandatory at intake, not optional.

None of this replaces correct coding or clean documentation. It replaces guessing at which team should look at a denial with a rule that reads the code and routes it there directly.

Resova iQ's RCM iQ module holds authorization status, eligibility and benefit terms as data tied to each claim before submission, and captures the reason code and its paired remark code together on every 835 line it ingests — using the same 837P submission, 277 acknowledgement and 835 remittance data the platform already processes. It routes a flagged denial toward the team its root cause belongs with; it does not file a correction or an appeal on its own, and every submission goes out under the approvals a practice configures.