How to Investigate a Medical Billing Denial

What a Denial Actually Is

A denial is a payer's decision, communicated on the remittance advice, that a claim or a service line will not be paid as submitted. That decision is expressed through standardized codes rather than plain English, which is why investigation starts with reading those codes correctly.

Two points matter before you touch the claim.

First, a denial is not the same as a rejection. A rejection generally happens before adjudication, often at the clearinghouse or in a front-end edit, and the claim never fully entered the payer's system. A denial happens after adjudication, when the payer processed the claim and decided not to pay all or part of it. The two need different workflows, and treating a rejection like a denial (or the reverse) wastes time.

Second, an adjustment is not always a denial. A contractual write-off is an adjustment the payer expects you to accept under your contract. The remittance codes tell you which is which, so reading them accurately is the whole foundation of the investigation.

DenialPro practical note: The habit that separates fast, accurate billers from slow ones is starting at the remittance, not the claim. The remittance tells you what the payer decided and why. The claim only tells you what you sent. You investigate in the payer's language first, then go to the claim to confirm.

Step 1: Read the Remittance First

The remittance advice is the electronic remittance advice (the 835, delivered as an ERA) or the explanation of benefits (EOB). Before anything else, read the affected line and account for every dollar.

On each service line, confirm these amounts and how they reconcile:

If billed, allowed, paid, adjusted, and patient responsibility do not reconcile, stop and resolve the discrepancy before acting. A line that does not add up is a signal that you are misreading the remittance or that something was posted incorrectly.

DenialPro practical note: A zero-dollar payment is not automatically a full denial, and a patient-responsibility amount is not automatically billable to the patient until you have confirmed the group code and the reason behind it. Read the codes before you route a balance anywhere.

Step 2: Connect the Group Code, CARC, and RARC

Every adjustment on a remittance is described by up to three linked pieces of information. Reading them together, rather than in isolation, is what turns a code into an action.

The claim adjustment group code

The group code frames the adjustment by telling you the general category and, in effect, who is responsible. The national standard claim adjustment group codes are maintained through the X12 process:

• CO, Contractual Obligation. The adjustment is tied to a contractual arrangement. These amounts are generally the provider's responsibility and are typically not billable to the patient.
• CR, Correction and Reversal. Used to correct or reverse a prior adjustment. X12 notes that CR is not used with the 005010 and later versions of the transaction, so you will not see it on current 835s in the way older versions used it.
• OA, Other Adjustment. Used when neither contractual obligation nor patient responsibility applies, for example certain coordination of benefits adjustments.
• PI, Payer Initiated Reductions. Adjustments the payer initiates when it believes the reduction is not the patient's responsibility and there is no supporting contract provision.
• PR, Patient Responsibility. Amounts assigned to the patient, such as deductible, coinsurance, copay, or non-covered amounts that fall to the patient.

The national group-code definitions are standardized. Operational handling, contractual responsibility, patient billing requirements, and payer-specific workflows may still vary by payer, plan, program, and contract.

The Claim Adjustment Reason Code (CARC)

The CARC states the reason the line was paid differently than billed. It is the "why" of the adjustment. CARCs are national standard codes, and the same CARC can appear across many payers, though the exact handling can differ by payer.

The Remittance Advice Remark Code (RARC)

A RARC does one of two things. It either provides additional explanation for an adjustment already described by a CARC, or it conveys information about remittance processing. Not every RARC is a correction prompt. Some RARCs are supplemental and add the specific detail you need to act, while others are informational and simply communicate processing information. Read the RARC to learn whether it is telling you what to fix or simply providing context.

DenialPro practical note: The pattern to internalize is group code plus CARC plus the accompanying remark or reject code as a single sentence. The group code sets the category, the CARC gives the reason, and the accompanying remark or reject code often provides the specific detail needed to investigate the issue. Some CARCs, such as CARC 16, require at least one accompanying remark or reject code, which may be a non-Alert RARC or an NCPDP Reject Reason Code. Not every RARC is a correction prompt, so always read the actual code on your remittance against the official list rather than assuming its meaning.

For the full code sets, see the DenialPro CARC directory and RARC directory, and the individual denial code pages such as the CO-16 page for missing or invalid information denials.

Step 3: Categorize the Denial

Once you understand what the codes are saying, place the denial into a working category. Categorizing focuses the rest of your investigation, because each category has a specific set of fields and policies to check.

Common denial categories include:

• Eligibility and coverage (for example terminated coverage, wrong plan, or demographic mismatch)
• Authorization or precertification
• Coding (procedure, diagnosis, or units)
• Modifier related
• Medical necessity
• Documentation or additional documentation request
• Coordination of benefits
• Timely filing
• Duplicate
• Bundled or included service

A single denial can touch more than one category, and the group code, CARC, and RARC usually point you to the right one. Use the DenialPro Denial Troubleshooter if you want to work from the code to the likely category interactively.

Step 4: Pull the Claim and Review the Right Fields

Now, and only now, open the claim. The category from Step 3 tells you which fields deserve the most attention. Review the claim against what the payer said, looking for the specific element the remittance pointed to.

Patient, payer, and eligibility

Confirm the patient's identifiers, the payer and plan billed, the member ID, and eligibility on the date of service. Many denials that look like coding problems are actually eligibility or wrong-payer problems. You can confirm coverage through the payer portal listed in the DenialPro Insurance Portal Directory.

Dates, place of service, and claim history

Check the date of service, the place of service, and the claim history for this patient and date. Place of service that is inconsistent with the service, or a prior claim already on file, changes the entire investigation. Claim history is where you catch duplicates, prior submissions, and related lines.

CPT and HCPCS considerations

Verify that the procedure or service codes reflect what was actually performed and documented, that the units are correct, and that the codes are appropriate for the date of service and setting. Do not change a procedure code to resolve a denial unless the documentation supports the change. Coding must follow the record, not the desire to get paid.

ICD-10 considerations

Check that the diagnosis coding is present, specific, and supports the service billed. Many medical necessity denials trace back to diagnosis specificity or to a diagnosis that does not support the procedure under the payer's policy. Confirm the ICD-10 coding against the documentation and current official ICD-10-CM guidance.

Modifier considerations

If the remittance points to a modifier, investigate what the payer expected and whether a modifier is actually supported by the documentation and coding rules. Investigate the cause before changing anything.

DenialPro practical note: Do not add a modifier simply to clear a denial. A modifier must be supported by the documentation and the applicable coding rules. Adding one to force payment is a compliance risk and can create a larger problem than the original denial. If the question is whether a distinct-service or other modifier applies, that is a documentation and policy question, not a reflex.

Authorization

If the category is authorization, confirm whether an authorization was required, whether one was on file, and whether it matched the service, units, dates, and servicing provider. Authorization denials have several distinct failure modes (no authorization, expired, units exceeded, wrong entity), and the fix depends on which one applies.

Medical necessity

For a medical necessity denial, compare the documentation and diagnosis to the applicable coverage policy. For Medicare, that means the relevant Local Coverage Determination (LCD) or National Coverage Determination (NCD) in the CMS Medicare Coverage Database. For other payers, that means the payer's published medical policy. Note the policy source and the date you reviewed it.

Documentation

If the payer requested records or cited insufficient documentation, identify exactly what is being asked for and by when. A request for documentation is not the same as a final denial, and the response window matters.

Step 5: Check the Payer's Current Policy

Codes tell you the reason; the payer's policy tells you the rule behind the reason. Before you decide on an action for anything payer-specific, confirm the current policy from an authoritative source: the payer's provider manual or published policy, the CMS manual or coverage database for Medicare, or the state Medicaid agency for Medicaid.

Record the source and the date you verified it. Payer policies change, and a resolution built on an outdated rule can fail on resubmission or appeal. The DenialPro Payer Intelligence resource can help you locate where a payer publishes its rules.

DenialPro practical note: If you cannot confirm the current payer rule, that is itself a finding. It means the correct next action is not yet determined, and the honest step is to verify the policy before you correct or appeal, not to guess.

Step 6: Separate the Root Cause From the Symptom

The denial code is the symptom. The root cause is the underlying reason the claim was submitted in a way the payer would not pay. Fixing the symptom without the root cause produces the same denial again, often across many claims.

Ask what actually caused the denial. A missing authorization might trace to an intake process. A medical necessity denial might trace to diagnosis specificity or documentation. A duplicate denial might trace to a resubmission habit. The root cause is what you want to identify, because it determines both how to resolve this claim and how to prevent the next one. The DenialPro Denial Checklist Library provides category-specific checklists for working the root cause.

The Decision Point: Corrected Claim or Appeal

Once you know the root cause, you reach the central decision of denial resolution. The two main paths are not interchangeable, and choosing the wrong one can waste time and, in some cases, the filing window.

A billing or data error often points toward the payer's corrected, replacement, reopening, or resubmission process, depending on payer rules. Examples include a missing or invalid data element, an incorrect but documentation-supported code, wrong units, or a demographic error. A corrected or replacement claim generally replaces the original rather than duplicating it, and payers have specific processes and requirements for submitting one, so verify the payer's process before you submit.

A disagreement with an adjudicated payment decision may point toward reconsideration or appeal, generally when the claim was submitted correctly and you are disputing the payer's decision. Medical necessity disputes and bundling decisions you believe were applied in error are common examples. Some payers require an informal reconsideration before a formal appeal, so verify the payer's specific process and deadline.

A few rules keep this decision clean:

• Match the path to the problem. A billing or data error often points toward a correction, replacement, reopening, or resubmission process; a disagreement with an adjudicated payment decision may point toward reconsideration or appeal. Confirm which process the payer requires.
• Do not appeal a claim you should have corrected, and do not correct a claim you should have appealed. The wrong path can consume the timely filing or appeal window.
• Confirm the payer's specific corrected-claim and appeal processes and deadlines, and note the date you verified them.

For deadlines and proof-of-timely-filing questions, use the DenialPro Timely Filing resource.

When You Need More Information Before Acting

Sometimes the honest investigation result is that you cannot yet choose the right action. That is a legitimate and important outcome. Pause and gather before you act when:

• The RARC or CARC is broad and you have not confirmed the specific element at issue.
• The correct action depends on documentation you have not reviewed.
• The coding question depends on details in the record that you need to confirm.
• The payer's current policy is not yet verified.
• The claim history suggests a related claim you have not examined.

Acting without this information is how billers create resubmission loops and avoidable second denials. Gathering first is faster than guessing twice.

Common Investigation Mistakes

A Practical Example

Consider a service line that returns with group code CO and CARC 16, which signals that the claim or service lacks information or contains a submission or billing error. On its own, CARC 16 is broad. Under current X12 usage, CARC 16 requires at least one accompanying remark or reject code, which may be a non-Alert RARC or an NCPDP Reject Reason Code. In this example, the line also carries a RARC.

Working the method:

1. 1Remittance first. The line shows the charge billed, zero paid, and the full amount adjusted under group code CO with CARC 16. This is a denial, not a contractual write-off, because the reason points to missing information rather than a contractual reduction.
2. 2Connect the codes. CARC 16 says information is missing or invalid, and you read the accompanying code on the remittance against the official list to find the specific detail. In this example the accompanying RARC is N290, which identifies a missing, incomplete, or invalid rendering provider primary identifier. Not every CARC 16 carries N290; a different accompanying code points to a different problem, so you always read the actual code rather than assume it.
3. 3Categorize. This is a missing or invalid information denial, a data problem rather than a payment dispute.
4. 4Pull the claim. You verify the rendering provider information on the claim and confirm that the identifier field was in fact blank or incorrect, matching what the accompanying code indicated.
5. 5Check policy. You confirm the payer's requirement for that field and its corrected-claim or resubmission process, and note the date you verified it, before deciding the next action.
6. 6Root cause. The identifier was dropped during claim creation, which may be affecting other claims, so you flag the pattern.
7. 7Decision. Because this is a data error that will allow proper adjudication once corrected, a corrected or replacement claim is generally the appropriate path here, not an appeal. You submit the correction through the payer’s corrected-claim process within the filing window.

Notice what made this resolvable: reading the RARC for the specific element, confirming it in the claim, verifying the payer requirement, and matching the action to the type of problem. If the RARC had instead pointed to a payment decision you disputed, the path would have been an appeal, not a correction. The method is the same; the action follows the facts.

Frequently Asked Questions

Sources Reviewed

• X12, Claim Adjustment Group Codes (CO, OA, PI, PR). The legacy CR (Correction and Reversal) group code is referenced in X12’s Claim Adjustment Reason Codes documentation, which notes that CR is not used with 005010 and later versions.
• X12, Claim Adjustment Reason Codes (CARC)
• X12, Remittance Advice Remark Codes (RARC) including the supplemental and informational (Alert) distinction. RARCs are maintained by CMS and published in the X12 external code lists.
• CMS, Medicare Claims Processing Manual (Pub. 100-04), via the CMS Internet-Only Manuals for remittance advice (Chapter 22) and claims adjudication guidance.
• CMS, Medicare Coverage Database for Local Coverage Determinations (LCDs) and National Coverage Determinations (NCDs).
• CMS, National Correct Coding Initiative (NCCI) for bundling and edit guidance.
• CMS and NCHS, ICD-10-CM Official Guidelines for Coding and Reporting for diagnosis coding.
• Official payer provider manuals and published policies, for payer-specific requirements (record the source and verification date for each payer).
• Official state Medicaid agency guidance, for Medicaid-specific rules.

Payer-specific rules should always be confirmed from the payer's current published source, with the verification date recorded, because these rules change.

Last Reviewed: August 2026