A denial report that shows volume tells a practice how much rework it did, not what caused it. The cause is already written on the remittance advice, in the group code, the Claim Adjustment Reason Code and the Remittance Advice Remark Code. A denial root cause analysis groups those codes by payer, provider and owner, sizes the work with one month of denied lines, and turns the three largest groups into changes made before the claim goes out the door.
What this covers
- The 835 explains every adjustment with three code sets: a claim adjustment group code, a Claim Adjustment Reason Code and usually one or more Remittance Advice Remark Codes.
- Group codes decide who absorbs the money. CO is a provider write-off, PR may be billed to the patient, and a log that mixes them collects a total nobody can work.
- X12 updates the CARC and RARC lists three times a year, and Medicare contractors are barred from using a deactivated code in an original business message.
- Group the same month of denials four ways: by reason code family, by payer, by provider or location, and by the front-end function that has to change.
- Size the list with one month of data. A family that costs a few hours a month is noise, and the top three families are where a front-end change belongs.
A denial log records what the payer did. The root cause analysis records what the practice will stop doing.The second list is the one that changes next month’s claims.
The definitions here come from the code lists themselves and from the Medicare instructions that govern them. X12 maintains the Claim Adjustment Reason Codes as external code list 139 and the Remittance Advice Remark Codes as external code list 411, and CMS explains how Medicare contractors must apply them in Chapter 22 of the Medicare Claims Processing Manual. The X12 scope statement is the line to keep in mind: these codes describe why a claim or service line was paid differently than it was billed.
Two things follow. A reason code describes an adjustment, so it has to be read beside the group code that assigns financial responsibility. And the lists move. X12 updates the lists three times a year, on or about March 1, July 1 and November 1, and contractors are told to use only the current valid codes. A practice that keeps a 2016 spreadsheet in its denial taxonomy will report families no payer returns any more.
What a denial log has to capture
A denial log is one row per denied service line, and the columns decide whether analysis is possible at all. Most practice management reports carry the denial amount and the payer. That is enough to total the write-off and not enough to prevent it.
- Date of service, and the filing deadline computed from it.
- Payer and plan type, since Medicare Advantage, Medicaid managed care and commercial behave differently.
- Claim level or service line, plus the group code, the CARC and every RARC on that line.
- Billed charge and denied amount, so a family can be ranked in dollars.
- Provider, location and the front-end source: registration, eligibility, authorization, coding, charge entry or documentation.
- One owner and a next action date.
Log the group code next to the reason code. CO assigns the adjustment to the provider, PR assigns it to the patient, and only a PR adjustment can be billed to the patient. A log that adds both into one denial figure produces a number that cannot be worked, because part of it may already be collectible.
A claim can carry several adjustments across claim and service line level. The Medicare instructions state that the same adjustment may not appear at both levels on a remittance advice, so a log built from claim level totals alone will miss the line level detail that tells a coder what to change.
How the 835 explains a denial: group code, CARC, RARC
Every adjustment on an electronic remittance advice is explained by three code sets, and each one answers a different question.
| Code set | Question it answers | Maintained by |
|---|---|---|
| Claim Adjustment Group Code | Who is financially responsible for the unpaid amount | X12, external code list 974 |
| Claim Adjustment Reason Code (CARC) | Why the claim or service line was paid differently than billed | X12, external code list 139 |
| Remittance Advice Remark Code (RARC) | The additional or more specific explanation of that adjustment | CMS, external code list 411 |
The standard lists five group code values, and CR, corrections and reversal, is not for use with version 5010 and later. Medicare’s manual lists CO, OA and PR as valid on the remittance advice. CO means a contractual agreement or a regulatory requirement caused the adjustment, and Medicare treats it as a provider write-off. PR means the amount may be billed to the patient. OA applies when no other group code fits.
RARCs carry the detail that makes a cause actionable. A reason code saying the claim lacks information does not say which element is missing, and the remark code arrives on the same line.
The X12 definition for 16 states that at least one remark code must be provided, and the Medicare manual repeats that requirement for its contractors. A log that stores only the CARC shows a large documentation family and no idea which document is missing.
X12 keeps deactivated codes in the published list with a stop date, and Medicare contractors are told not to use a deactivated code in an original business message. The remark code N29 for missing documentation was deactivated on 03/01/2016 and replaced by the current documentation RARCs. A taxonomy built from a stale code spreadsheet can still carry it, and the report will name a family no payer returns.
Four ways to group denials
The same month of denials can be grouped four ways. Each grouping answers a different question, and a practice needs all four to move from volume to cause.
| Grouping | Question it answers | Typical owner |
|---|---|---|
| CARC and RARC family | What is going wrong on the claim itself | Coding and charge entry |
| Payer and plan type | Which contract is producing the rework | Billing manager and payer contracting |
| Provider, location or service line | Where the pattern concentrates | Department lead or the clinician |
| Front-end function | Which step in the workflow has to change | Registration, eligibility, authorization or documentation |
Group by reason code first, because the payer hands it over at no cost and it translates straight into a claim edit. The payer split shows whether the problem is systemic or concentrated in one contract. The provider split separates a training gap from a template gap, and the function split produces the fix list.
When denial notes are typed by hand, one cause arrives under four spellings and no report groups it. Store the code on the row and keep the note as a comment on the code.
The denial families, in the wording X12 and CMS use
A workable taxonomy follows the reason code definitions rather than an internal vocabulary. The families below use the current X12 wording, with the codes that most often open each one.
| Family | Representative codes | What the payer is saying | Front-end change |
|---|---|---|---|
| Information missing or invalid on the claim | 16 with a data remark such as M76 or M20 | A required element is absent or wrong | Add the field to the scrubber and the charge entry template |
| Documentation required or insufficient | 226, 251, N706, N237, M127 | The record does not support the service as billed | Visit template and signature control, then the records request workflow |
| Authorization or referral | 197, 198, 296, M62 | The authorization is absent, exceeded or misapplied | Authorization captured before the visit and attached to the claim |
| Eligibility and coverage dates | 26, 27, 177, N30 | Coverage was not in effect, or the member data does not match | Real-time eligibility at scheduling and again at check-in |
| Bundling, frequency and medical necessity | 97, 234, 151, M80, N362 | The service is not separately payable or not supported | Coding review and a payer policy check before submission |
| Wrong payer or wrong contractor | 109 | This payer does not own the claim | Payer ID and plan verification at registration |
| Timely filing | 29 | The filing limit expired | Work the A/R by days remaining, not days elapsed |
Two families deserve a warning. Documentation denials are the largest source of error in Medicare fee-for-service and almost never an appeal problem, so the fix belongs in the template. Authorization denials look like appeal work and are usually a scheduling problem.
CARC 16 shows up in practices with a charge entry problem, a clearinghouse problem and an eligibility problem. The remark code and the payer split separate them, so keep the RARC on the row instead of collapsing it to the CARC.
Sizing the work with one month of data
One month of remittance advice is enough to size the job. Pull the 835s, count the denied service lines, sort them into the families above, then work out the touch time each family costs. Forty denials at two minutes each is not the same problem as 12 denials at 25 minutes each.
Keep claim and line level adjustments, with the group code, CARC and every RARC on the same row.
One claim can deny on three lines. The rework is measured in lines.
Use the CARC and the RARC together. Count whatever does not fit in an unclassified bucket, because it usually means the taxonomy has a gap.
About two minutes for a corrected claim, 25 minutes or more for a records request. The product is the monthly hours spent repairing prevention failures.
A family can be small in lines and large in dollars. Rank both ways.
Three is what a team can change in a quarter without letting the rest of the A/R slip.
Here is the arithmetic for a practice submitting 2,000 claims a month at an 8 percent first-pass denial rate. That is 160 denied claims a month, about eight a working day. If 45 percent of those lines are documentation problems at 25 minutes each, the practice spends roughly 30 hours a month answering records requests. That is most of a full-time role spent on a template defect.
Turn the top three groups into front-end changes
A fix changes a step that happens before the claim leaves, and it has a named owner and a date to check whether it worked. A note in meeting minutes is not a fix.
| Family | Front-end change | Owner | Review date |
|---|---|---|---|
| Documentation, N706 and N237 | Add the missing elements to the visit template, then audit 10 notes a week | Clinical documentation lead | First working day of next month |
| Authorization absent or misapplied, 197 and 296 | Capture the authorization at scheduling, and have the biller match it to the claim before submission | Front desk supervisor | Six weeks from the change |
| Eligibility and coverage dates, 26 and 27 | Real-time eligibility at scheduling and again at check-in, with the response stored on the encounter | Registration lead | First working day of next month |
- Each fix names one owner, not a committee.
- Each fix has a review date, and the review reads the same family in the next month of 835s.
- The review has a number to move: lines in the family, hours of touch time, or dollars written off.
- The front-end edit is tested on 10 claims before it is made mandatory.
- The change lands in the template or the workflow, not in a training deck.
- Anything the fix did not move goes back on the list with a reason.
Run the same analysis next month against the same taxonomy. If a family does not fall after a documented change, the cause was misidentified and the log says so, which is the feedback a monthly denial rate cannot give. That loop is what denial management means in practice.
Questions about denial root cause analysis
It is the step after denial reporting. Reporting counts what came back. Root cause analysis groups denied service lines by group code, Claim Adjustment Reason Code and Remittance Advice Remark Code, splits those groups by payer, provider and the front-end function that owns them, and names the change that stops the family recurring. The output is a short fix list with owners and review dates, not a rate.
A Claim Adjustment Reason Code gives the general reason the payment differs from the billed amount. A Remittance Advice Remark Code adds the specific detail, such as which element is missing or which record was not received. Some reason codes require at least one remark code, and CARC 16 is one of them. Read the two together, because the reason code alone rarely names the field to fix.
Every denied service line the practice received that month, with no sampling. A practice submitting 2,000 claims a month at an 8 percent first-pass denial rate is looking at about 160 denied claims, or roughly eight a working day. Sampling is reasonable for a quality audit, not for a root cause count, because the small families are often the expensive ones.
Four ways on the same data: by reason code family, by payer and plan type, by provider or location, and by the front-end function that has to change. Group by reason code first, since the payer supplies it and it maps directly to a claim edit. Add the payer split to see whether the problem is systemic, and the function split to decide who owns the fix.
The Claim Adjustment Reason Code and Remittance Advice Remark Code lists are updated three times a year, and a deactivated code stays visible in the published list with a stop date. Medicare contractors are told not to use a deactivated code in an original business message. A taxonomy built from an old spreadsheet reports families no payer returns, and a scrubber rule tied to a retired code never fires.
Three. A billing team can change three workflows in a quarter without letting the rest of the accounts receivable slip. Pick the three families that cost the most hours or the most dollars, give each one a named owner and a review date, then check the same family in the next month of remittance advice. Fixes that do not move the number go back on the list.
The bottom line
A denial log records what the payer did. The analysis records what the practice will stop doing, and it ends up as a small number of families with a named owner and a review date. Run it monthly against the same taxonomy and the report stops being a scoreboard and starts being a to-do list.
Which three denial families cost you the most hours?
Send us one month of electronic remittance advice. We will group the denied lines by group code, CARC and RARC, split them by payer and by owner, convert each family into hours and dollars, and hand back the front-end changes for the top three with a review date on each. For the vocabulary first, start with what denial management in medical billing covers, or see how denial management solutions are built around this loop.
Request a free denial root cause auditThis article describes general billing practice and the code sets and Medicare instructions in force at the time of writing. Payer contracts, state Medicaid rules and code list versions change, so confirm any code against the current X12 list and the payer’s own remittance advice before you build a report or a scrubber rule on it.
