Medicaid claim denials: the 5 root causes we see most
Denial codes tell you what was wrong with the claim. The real causes are upstream, and almost always fixable. Here are the five we see most often — and what to do about each.
Every billing supervisor has a stack of denial codes they can recite from memory. They're diagnoses — useful, specific — but they're not the disease.
The disease lives upstream. In the agencies we work with, denials trace back to the same five root causes, in roughly this order of frequency. Here's the list, with what to do about each.
1. Authorization and service mismatches
By a wide margin, the most common cause of denials we see: the service that was billed doesn't match the authorization on file at the state.
The mismatches are usually small. A service code that's one digit off. A unit count that exceeds the authorization. A service date that falls just outside the authorization window. A modifier that wasn't on the auth.
The fix isn't to be more careful at billing time. The fix is to enforce the match upstream — at the point of scheduling or service delivery, not at the point of claim submission. If a visit is scheduled outside the authorization window, the scheduling system should refuse to schedule it (or surface a warning to the supervisor). By the time billing runs, the constraint is already satisfied.
In ctAgency Suite™, authorization data drives both scheduling and billing — so a mismatch is much harder to create in the first place.
2. Eligibility lapses
A consumer's Medicaid eligibility lapses, the next month's claim gets denied, and the agency finds out at remittance time — 30 to 60 days later. By then, you've already delivered (and paid for) the services.
Eligibility verification is a daily-cadence problem. Agencies that get hit by this aren't checking eligibility frequently enough — usually because the workflow to check it lives in a different system from the one where services get scheduled.
The fix is to make eligibility verification part of the scheduling workflow. If a consumer's eligibility hasn't been verified in the last N days, the system should require verification before the next visit can be scheduled. Treat it as a precondition, not a follow-up.
3. Documentation gaps
The claim went out clean. The denial says "documentation does not support service billed." That means the state pulled the chart and didn't find what they expected.
This is usually a timing problem rather than a content problem. The documentation gets done, but it gets done after the claim. By the time the state pulls the chart, the visit note exists — but it was written three weeks after the visit, and the date stamps make that visible.
The fix is enforce same-day or next-day documentation, with the system refusing to release claims for services that don't have current documentation. This is uncomfortable; field staff hate it. It's also the cleanest way to eliminate the denial category.
4. Duplicate or near-duplicate claims
Two claims for what looks like the same service, on the same date, for the same consumer. The state denies the second one.
The most common cause is two systems billing for the same encounter — an EVV system and a separate billing system, or a back-office system and a state-portal manual entry — without a deduplication layer between them. Less common but more painful: an agency genuinely re-billed a service because the first claim was incorrectly thought to have been denied.
The fix is a single source of truth for billed encounters, with the state portal as the system of record for what's been submitted. Reconcile against that, not against your internal billing history.
5. Coding and modifier errors
The bottom of the list, but never zero: service codes, modifiers, place-of-service, and rendering-provider identifiers that don't line up with what the state expects for the service in question.
Different from category 1: here, the service really did happen and was authorized correctly — the coding on the claim just doesn't match what the state wants to see. State guidance changes. Codes get retired. Modifiers get added.
The fix is a centralized, maintained coding library — not coding rules embedded in individual claim templates. When the state updates its guidance, you change one mapping, and all your claims pick up the change.
The hidden sixth cause
These five are the operational causes. There's a sixth cause that's structural: the billing system doesn't tell anyone outside the billing team that a denial happened.
The visit happened. The service was delivered. The claim went out. The denial came back. The billing team works the denial. And the SC, the supervisor, and the agency leadership never see any of it. So the upstream behavior — the scheduling pattern, the documentation timing, the eligibility-check cadence — never changes.
The biggest single win for most agencies isn't a better denial-resolution workflow. It's visibility of denial patterns to the people whose upstream behavior is causing them. That's not a billing problem. That's a software problem.
ctAgency Suite™ handles claim denial management as a connected workflow — denials route back through the operational data they came from, so the patterns are visible to the people who can change them, not buried inside the billing module.
The bottom line
If your denial rate is north of 3-4%, the volume isn't usually a billing-team execution problem. It's an upstream-systems problem. Fixing it means fixing the systems that produce the claims, not just getting better at re-working them.
Most of the agencies we've worked with have been able to drop their denial rate by half within a quarter once the upstream patterns are addressed. That's not a small number — it's a real revenue line item for any volume agency.
If you want to talk through what your specific denial patterns look like, schedule a demo. Bring a recent denial report; we'll walk through what's upstream of it.