# Claim denial routing: a worked exception case | SourceX

Canonical: https://refer.sourcex.si/guides/claim-denial-routing-exception-examples
Last updated: 2026-10-19

The records that explain a claim denial routing exception are the line-level denial reasons on the first payment advice, the routing log showing which rule version sent each line where, the hand correction that fixed a misroute, the rule change log with its approver, and each later payment advice that proved whether a fix worked. In the worked case below, those five records show a two-cause denial, a rule that read only one cause, an 18-day detour, and the rule change that closed the gap.

This worked case is part of the [claim denial routing guide](/guides/workflow-claim-denial-routing). It walks one hard case decision by decision, so a billing operations consultant can recognize the same pattern at a client and describe it without touching a claim. The code background comes after the case, for readers who want it.

## Step by step: two causes, one queue (Illustrative)

Written for this page: a 340-person billing company working claims for orthopedic clinics. A two-line claim comes back denied. Line 1 carries CARC 197, an authorization problem. Line 2 carries CARC 16 with a remark pointing to a missing referring provider, a billing error. The company's routing rule, version 3, reads the first adjustment code it parses for the claim and sends the whole claim to one queue.

| Day | What happened | Line 1 (authorization) | Line 2 (billing error) |
|---|---|---|---|
| 0 | First payment advice received | Denied | Denied |
| 1 | Rule version 3 routes the claim on the code it reads first | Sent to coding with line 2 | Sent to coding |
| 4 | Coder adds the referring provider; corrected claim sent | Untouched | Corrected |
| 18 | Second payment advice received | Denied again, same code | Paid |
| 19 | Analyst moves line 1 by hand | Sent to authorization team | Closed |
| 21 | Authorization team finds the authorization: obtained before the visit, number never put on the claim | Cause identified | Closed |
| 22 | Corrected claim with the authorization number | Corrected | Closed |
| 25 | Rule version 4 approved: route each line by its own code | Rule changed | Rule changed |
| 36 | Third payment advice received | Paid | Closed |

At the claim level, the case looked "worked" on day 4 and "resolved" on day 36. Only the line-level view shows that line 1 sat for 18 days in a queue that could not fix it.

## Who decided what, and the record each decision left

Every step in the table was someone's decision, and each left a trace in a specific system. This is the part a buyer of operational history cares about: the chain from problem to authorized action to checked result.

| Decision | Who made it | Record that captured it | System |
|---|---|---|---|
| Route the claim to coding | Rule version 3, approved months earlier by the revenue cycle analyst team | Routing log with rule ID and version | Denial worklist |
| Fix the referring provider | Coder | Case note and claim edit history | Billing system |
| Treat line 1 as a different problem | Analyst, after the second payment advice | Hand correction with timestamp | Denial worklist |
| Find the missing authorization number | Authorization specialist | Authorization work queue entry | Authorization tracker |
| Change the rule to read each line | Revenue cycle head | Rule change log with approver and reason | Denial worklist or ticket tracker |
| Confirm the fix worked | The payer | Second and third payment advice files | Billing system |

If any one of these records is missing, the story breaks. Without the rule version, nobody can tell whether the misroute was a rule error or a staff choice. Without the second payment advice, nobody can show that only one cause was fixed. Without the change log, the new rule has no explanation. The [system map for claim denial routing](/guides/claim-denial-routing-records-across-systems) shows which keys join these records.

## Why this sequence is useful evidence

Because it holds a mistake, its detection and its correction, each dated and attributed. Most operational data records only the happy path. A multi-cause denial records a judgment that was reasonable, failed in a specific situation, and was fixed by changing a rule.

Three features make it valuable:

- **Bracketed outcomes.** The first payment advice shows both causes; the second shows only one was addressed; the third shows the fix worked. The payer, not the company, supplied the checked result each time.
- **A rule change with a reason.** Version 3 to version 4 is a small, explainable improvement in how work is assigned. That is the kind of decision AI systems for revenue cycle work need to learn from, as [why operations data is valuable](/proof/why-operations-data-is-valuable) explains.
- **Time cost.** The dates show exactly how many days the misroute cost, which matters wherever a payer counts days for appeals or corrected claims.

Why the authorization number went missing upstream is a separate workflow, covered in [prior authorization follow-up](/guides/workflow-prior-authorization-follow-up).

## Reading the codes and rules behind the case

Two things shaped every decision above.

**Codes.** Each denied line carries a reason code from the industry list, sometimes with remark codes that add detail. In this case the two codes pointed at two different problems: one says information was missing or billed wrongly and must come with a remark; the other says the authorization was absent. Two codes, two different teams able to fix them.

**Rules.** A routing rule reads those codes and assigns the line to a team: coding, authorization, eligibility or a payer desk. Rules have versions, and each version is a decision someone approved.

## Spotting similar cases at a client

Ask the revenue cycle head these questions, and listen for the answers in brackets:

1. **Are cases opened per claim or per line?** [Per claim usually means multi-cause denials share one case.]
2. **Does the denial worklist keep each rule version, or are rules edited in place?** [Kept versions make misroutes explainable.]
3. **Are hand corrections logged with a timestamp, or only noted in free text?** [Logged corrections mark the exceptions.]
4. **Is there a change log for routing rules, with an approver?** [That is where the lessons are written.]
5. **Do closed cases link to every later payment advice for the line?** [That is the checked result.]

Three or more yes answers usually mean the company can reconstruct cases like this one. Similar exception patterns in other industries are described in [identifying logistics exceptions and their resolutions](/guides/how-to-identify-logistics-exceptions-and-their-documented-resolutions).

Stay at metadata level. Payment advices and case notes contain protected health information; anything licensed would need de-identification under one of HIPAA's two methods, Expert Determination or Safe Harbor, and a billing company's client agreements decide what it may do with claim records. Rule sets and change logs often contain no patient data. The revenue cycle head convenes; authority usually sits with the CEO, COO or general counsel.

The introduced company needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Sign the Channel Partner Agreement before submitting; the first valid introduction within the 90-day window is credited when the company submits a verified application. Buyer interest, the rights outcome for each client's records, the de-identification required and any offer stay unknown until SourceX reviews them. The [medical billing company data guide](/guides/medical-billing-company-data) and the [revenue cycle management page](/industries/refer-revenue-cycle-management-company-data-licensing) describe the wider fit.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If a billing client keeps rule versions, hand corrections and line-level payment advices that let a case like this be rebuilt, [register as a partner](/register), check the company against [who qualifies](/who-qualifies) and read the [program terms](/terms) before you introduce the revenue cycle head.

## Sources

- https://x12.org/codes/claim-adjustment-reason-codes
- https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html
- https://refer.sourcex.si/terms