Common Denials in Medical Billing

The most common denials in medical billing fall into a short list of categories: eligibility or coverage problems, a missing or invalid prior authorization, coding errors, missing or incomplete information, timely filing lapses, coordination of benefits conflicts, non-covered services, and duplicate claims. Each carries a standardized reason code on the remittance advice, so denial data is sortable and the same reason reads consistently across payers. Most are decided by data captured at the front end, before the claim is submitted, which means a large share are preventable rather than inevitable. Insurers denied 20 percent of in-network claims on HealthCare.gov in 2023, yet consumers appealed fewer than 1 percent of those denials, according to KFF. The sections below take the top reasons one at a time: the cause, how to fix a denial once it lands, and how to prevent it.

What causes eligibility and coverage denials?

Eligibility denials happen when the payer determines the patient was not covered under that plan on the date of service, or that the plan does not cover the member for what was billed. They surface as CARC 27 (expenses incurred after coverage terminated), CARC 26 (before coverage began), or CARC 31 (patient cannot be identified as an insured). The root cause is typically front-end data: a member ID keyed wrong, a plan that changed at open enrollment, or a patient who switched payers. To fix one, pull the correct coverage for the date of service, confirm the member ID and plan, and resubmit a corrected claim rather than appealing, since there is nothing to dispute if the data was simply off. Prevention lives in the eligibility check: a 270/271 inquiry before the visit confirms whether the plan is active and the member matches, and CMS maintains the 270/271 as the standard transaction for this, under Administrative Simplification. In the engagements we run, an insurance eligibility verification agent sends that 270 against tomorrow's schedule and flags a terminated or mismatched plan while the patient can still be reached.

How do you fix a prior authorization denial?

A prior authorization denial means the service required the payer's advance approval and either none was obtained or the one on file did not match the claim. It commonly appears as CARC 197 (precertification, authorization, or notification absent). The causes are practical: the ordering team did not know the service needed authorization, the request was not yet approved when the service happened, or the approval covered a different code, date range, or place of service than what was billed. Fixing one usually means retro-authorization where the payer allows it, or an appeal with clinical documentation supporting medical necessity; if the authorization exists but the claim referenced it wrong, the fix is a resubmission with the right number and matching codes. Prevention is confirming the authorization before the claim: the 278 transaction is the standard request and response for prior authorization, and checking it verifies an approval is on file with codes and dates that match. This is a heavy manual load, with physicians completing about 39 prior authorizations per week, roughly 13 hours, according to the AMA. A prior authorization automation agent can carry that work and reconcile the approval against the claim, so a mismatch is caught before submission rather than returning as a CARC 197.

What are the most common coding denials?

Coding denials come from the codes on the claim rather than the coverage behind it: an invalid or outdated CPT or ICD-10 code, a diagnosis that does not support the procedure, a missing or incorrect modifier, or a bundling conflict where two codes should not be billed together. Typical reason codes include CARC 11 (the diagnosis is inconsistent with the procedure), CARC 4 (the procedure is inconsistent with the modifier, or a required modifier is missing), and CARC 16 when a code is invalid. To fix one, a coder reviews the documentation, corrects the code, modifier, or diagnosis linkage, and submits a corrected claim; where the payer applied an edit the documentation contradicts, the path is an appeal with the clinical note attached. Prevention is largely a claim-scrubbing and coder-review problem, since coding is a judgment task tied to the clinical record. Front-end claim edits and current code sets catch the mechanical errors, invalid codes, expired codes, obvious modifier gaps, before a claim leaves. In our work, an agent scrubs the claim against current code validity and flags missing modifiers or diagnosis-procedure mismatches for a coder to resolve, but does not assign clinical codes on its own, because that decision belongs with a person reading the documentation.

Why do claims get denied for missing information or as duplicates?

Two high-frequency categories share a cause in incomplete or redundant submission. Missing-information denials, often CARC 16 (claim lacks information needed for adjudication) paired with a RARC naming the specific missing field, occur when a required data element is absent: a rendering provider NPI, a subscriber date of birth, an accident date, or a needed attachment. Duplicate denials, typically CARC 18 (exact duplicate claim or service), occur when the same claim is submitted twice, often because a staffer resubmitted while unsure the first attempt went through. Fixing a missing-information denial means supplying the field the RARC calls out and resubmitting; fixing a duplicate means confirming the original claim's status, since the "duplicate" may in fact be the paid one. Prevention for both is front-end discipline the software can enforce: field-completeness edits stop a claim that lacks a required element, and a claim-status check (the 276/277 pair) confirms whether an earlier submission is already in process before anyone sends it again. An agent can run both, holding a claim that is missing a required field and checking status before resubmitting, so the missing element is filled and the duplicate is never generated.

What are timely filing and coordination of benefits denials?

Timely filing denials, usually CARC 29 (the time limit for filing has expired), happen when a claim reaches the payer after that payer's submission deadline, which varies by contract from a few months to a year from the date of service. These are among the hardest to overturn, because the deadline is contractual; an appeal succeeds only with proof of timely submission, such as a clearinghouse acceptance report. Coordination of benefits (COB) denials, commonly CARC 22 (care may be covered by another payer per COB) or CARC 23 (the prior payer's adjustment affects this payment), happen when a patient has more than one plan and the claim went to the wrong payer first, or the primary payer's payment was not attached when billing the secondary. Fixing a COB denial means establishing the correct payer order, billing the primary first, and submitting to the secondary with the primary's remittance attached. Prevention for timely filing is tracking: watch the age of every unbilled and rejected claim against each payer's deadline so nothing quietly crosses it. Prevention for COB is capturing which plan is primary at registration, which the 271 eligibility response often reports when another payer is on file. An agent can surface a claim approaching its deadline before it lapses and read the COB indicators on the 271 so the primary payer is billed first.

Prevent denials before the claim goes out

The pattern across these categories is that the expensive denial and the cheap prevention are separated by only a day or two: a coverage check, an authorization confirmation, a completeness edit, or a filing-deadline watch, each run before the claim is submitted rather than after it is rejected. That is where AI agents fit. Flexbone's voice and browser agents run the 270/271, 278, and 276/277 transactions, scrub claims for missing fields and coding validity, and track filing deadlines and payer order, then route anything they cannot resolve to your team, so preventable denials are stopped at the front end and staff time goes to the ones that need judgment. The work is audit-first, HIPAA compliant, and SOC 2 aligned, and it complements the back-end appeals side covered in AI denials management.

To map which of your denials are preventable and what an agent can catch before the claim goes out, book a call with Flexbone.