> ## Documentation Index
> Fetch the complete documentation index at: https://mso.getlemma.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Your first denial
> A CO-197 arrives. Read it, root-cause it, decide between correcting and appealing, and close the prevention loop.
A **denial** is a claim the payer adjudicated and refused to pay. Unlike a rejection, it has a determination behind it, an explanation in the 835, and appeal rights with deadlines. This tutorial walks one denial from arrival to prevention.
## What arrived
Meridian's 835 for a Mohs surgery claim came back with a line showing \$0 paid:
```text theme={null}
Billed: $1,240.00
Allowed: $0.00
Paid: $0.00
Adjustment: CO-197 $1,240.00
```
**CARC 197** means: *Precertification/authorization/notification/pre-treatment absent.*1
Group code **CO** means the payer is treating it as a contractual obligation, which is important, because it means you generally **cannot bill the patient** for it. The patient did nothing wrong; your practice failed to get an authorization the contract required.
The instinct when a \$1,240 line comes back at zero is to write it off or bill the patient. Both are wrong. A CO-denial is not billable to the patient, and a write-off before you've assessed appeal rights forfeits real money.
## Step 1: read the whole line, not just the CARC
Before deciding anything, extract:
| Field | Meridian's claim |
| ------------------------------ | ------------------------- |
| Group code | CO |
| CARC | 197, authorization absent |
| RARC | N/A on this line |
| Claim status code (CLP02) | 4, denied |
| Date of service | 22 days ago |
| Payer | Regional BCBS |
| Amount at risk | \$1,240.00 |
| Appeal deadline (per contract) | 180 days from remittance |
The **RARC** matters when present — it often distinguishes "no auth on file" from "auth was obtained but doesn't match the service billed," which are different problems with different fixes.
## Step 2: root-cause it
Do not skip to the fix. Ask what actually happened, in this order:
1. **Was an authorization required?** Check the payer's authorization list for that CPT under that plan on that date. Sometimes the payer is wrong.
2. **Was one obtained?** Search the chart, the auth log, and the payer portal. Auth numbers get obtained and never recorded on the claim more often than they get missed entirely.
3. **Does the obtained auth match?** Right CPT, right units, right provider, right date range, right facility. An auth for one procedure code does not cover a different one.
4. **Was it on the claim?** An auth obtained but omitted from the 837 denies exactly like an auth never obtained.
5. **Is retro-authorization available?** Many payers allow it within a window, especially for urgent care or when eligibility was in question.
Meridian's answer: **the authorization was obtained** on the day of the visit, and the number was recorded in the chart note, but never entered into the PM system's authorization field, so it never made it onto the 837.
That is a data-flow failure, not an authorization failure. Very different prevention.
## Step 3: correct or appeal?
| | Corrected claim | Formal appeal |
| ------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| **Use when** | The claim had wrong or missing data | The claim was right and the payer's decision was wrong |
| **Mechanism** | Resubmit with a corrected-claim frequency code and the original claim number | Written appeal with supporting documentation |
| **Speed** | Days to weeks | Weeks to months |
| **Deadline** | Corrected-claim window, often shorter than the appeal window | Appeal window per contract; Medicare has its own multi-level track |
Meridian had a valid authorization that was simply missing from the claim, so a **corrected claim** was right: add the auth number, resubmit with the appropriate frequency code referencing the original claim, done in eleven days.
Had the payer denied *despite* a properly submitted authorization, that's an appeal, and appeals get written differently. See [File appeals](/guides/billing/file-appeals).
**Never resubmit a denied claim as a brand-new claim.** It will deny as a duplicate, and you will have burned time and possibly the correction window. Use the corrected-claim mechanism with the original claim reference.
## Step 4: log it
Record, in whatever system holds your denial data:
* CARC / RARC
* Payer
* Dollar amount
* **Root cause from your fixed taxonomy**, here: *authorization obtained but not captured on claim*
* Action taken
* Outcome and days to resolution
Free-text root causes are useless in aggregate. Use a fixed list: eligibility, authorization, coding, credentialing, timely filing, coordination of benefits, documentation, demographic error, payer error.
## Step 5: close the prevention loop
This is the step practices skip, and it is the only one that compounds.
Meridian's root cause was that authorization numbers lived in the clinical note rather than the billing field. Three candidate fixes:
1. Add a required authorization field to the check-in workflow for auth-required services
2. Build a scrubber edit that blocks submission when a CPT on the payer's auth list has no auth number
3. Add "verify auth number is in the PM field" to the daily charge-entry checklist
Meridian did (2) and (3). Fix (2) is structural and catches everything; fix (3) catches the case where the scrubber's payer list is stale.
Prefer **structural fixes over checklist fixes** where you can build one. A scrubber edit works at 3pm on a Friday when your biller is out. A checklist item depends on a person.
## The denial families you'll see next
CO-197 is one of a small number of families that produce most denials:
| Family | Typical CARCs | Usually caused by |
| -------------------------- | --------------- | ---------------------------------------------------------- |
| Eligibility | 26, 27, 31, 32 | No eligibility check, or checked too early |
| Authorization | 197, 198 | Auth missing, mismatched, or not captured |
| Coding / medical necessity | 11, 16, 50, 167 | Code-diagnosis mismatch, missing modifier, LCD/NCD |
| Timely filing | 29 | Charge entry lag, or a claim lost in a rejection loop |
| Coordination of benefits | 22, 23 | Payer order wrong, or COB not updated |
| Credentialing / enrollment | 8, 185, 206 | Provider not linked, taxonomy mismatch, pre-effective date |
| Duplicate | 18 | Resubmitting instead of correcting |
| Non-covered | 96, 204 | Benefit design, not an error |
Each one has a play. See [Denial code playbook](/reference/edi/denial-code-playbook).
## What good looks like
* Every denial has a named owner and a root-cause tag
* Nothing sits untouched more than 14 days
* Corrected claims go out within a week
* Appeals are filed with the policy citation, not just a cover letter
* One upstream process changes every week because of what the data said
## Next
A patient overpays. Now you owe them money, with a deadline.
## Sources
1. Claim Adjustment Reason Codes are maintained by X12. See the authoritative list at [x12.org/codes/claim-adjustment-reason-codes](https://x12.org/codes/claim-adjustment-reason-codes).
## Related topics
- [Work the denial queue](/guides/billing/work-the-denial-queue.md)
- [File appeals](/guides/billing/file-appeals.md)
- [Get prior authorizations](/guides/billing/get-prior-authorizations.md)
- [Claim denials, explained](/concepts/payments/claim-denials.md)
- [The 835: how payers answer](/concepts/payments/understanding-835s.md)
- [Denial code playbook](/reference/edi/denial-code-playbook.md)
- [CARC codes (Claim Adjustment Reason Codes)](/reference/edi/carc-codes.md)
- [Group codes (CO, PR, OA, PI)](/reference/edi/group-codes.md)