Denial rate is not a number
Ask three people in the same organization for the denial rate and you will get three answers, all defensible. One counts denied claims over submitted claims. One counts denied lines over submitted lines, which is larger because a single claim can have several lines and one bad line denies alone. One counts denied dollars over billed dollars, which behaves differently again because the expensive services and the frequently denied services are not the same services. None of them is wrong. They are different questions, and an organization that has not agreed which one it is asking will spend a year arguing about whether a program worked.
Worse, the headline rate hides the only distinction that matters operationally: a denial that was preventable and a denial that was the predictable cost of doing business. A service your contract does not cover, billed for a patient who wanted it anyway, will deny every time. Counting that alongside a claim that denied because somebody typed a subscriber identifier wrong produces an average that describes nothing and directs nobody.
The useful reframing is to stop treating denials as a rate and start treating them as a set of recurring causes, each with a location, an owner and a cost to fix. There are not hundreds of these. In most organizations, a small number of patterns account for most of the preventable dollars, and they are visible in data you already receive electronically.
You are probably here because
- Denials went up and nobody can say which ones or why
- You are being sold a model that predicts denials and you cannot tell what you would do with the prediction
- Your team is working every denial with the same urgency regardless of what it is worth
- Two reports in the same building disagree about the denial rate
Start with the rejection-versus-denial section — it is the most common source of confused numbers. The pattern table is the working map. The section on what to appeal is the one that changes staffing.
A rejection is not a denial, and mixing them corrupts everything
Two very different events get called the same thing in hallway conversation.
A rejection happens before adjudication. The claim fails a format or eligibility edit at the clearinghouse or at the payer's front door and comes back on an acknowledgment transaction. It was never processed. There is no determination, no appeal rights, and usually no financial impact if it is corrected and resubmitted promptly. Rejections are cheap to fix and they are pure signal about data quality.
A denial happens after adjudication. The claim was processed, a determination was made, and the reason arrives coded on the electronic remittance advice. This one has appeal rights, timelines, and real money attached.
Many organizations report these together, or report only denials while rejections are worked quietly by a clearinghouse team whose queue nobody sees. That is a mistake in both directions. Rejections are the earliest and cheapest place to catch registration and eligibility defects, and their causes are the same causes that later produce denials. Separate the two, count both, and route them to the same root-cause analysis.
Read the coded reason, not the summary bucket
The remittance advice carries structured reasons. A group code says which category the adjustment falls in — contractual obligation, patient responsibility, and a couple of others — and that group code alone tells you a great deal, because it says who the payer thinks owes the balance. Under it sit a claim adjustment reason code, which is the machine-readable why, and often one or more remark codes that add specificity.
Two practical notes about those codes. First, they are maintained externally and revised periodically, so any hard-coded list in your analytics needs an owner and a refresh date. Second, and more important, the same code means different things at different payers. A generic “claim lacks information” reason is used by one plan almost exclusively for a missing referring provider identifier and by another for anything at all. Do not analyze codes in aggregate across payers. Analyze the pair — payer plus code — and, where you have it, payer plus code plus remark code. The pair is where the pattern lives.
The patterns, where they are caused, and who can fix them
Below are the recurring families we see in remittance data. The point of the table is the third column: almost none of these are caused in billing, which is where the metric usually lands.
| Pattern | What it usually means | Where it is actually caused |
|---|---|---|
| Eligibility and identity | Coverage not in effect on the date, member not found, wrong plan of several | Registration and intake. Frequently a real-time eligibility check that was skipped, or run and ignored |
| Authorization absent or invalid | No authorization on file, wrong code authorized, expired, or a different rendering site | Pre-service. Often the authorization exists but for a code that changed after the encounter |
| Missing or invalid information | A required identifier, date, or field is absent or malformed | Intake and the claim scrubber. The single largest source of cheap, fully preventable volume |
| Bundling and edits | The service is considered included in another service billed the same day | Coding, and payer edit policy. Some of it is correct and should not be appealed |
| Medical necessity and coverage policy | The diagnosis does not support the service under the payer's policy | Ordering and documentation, weeks earlier. The most expensive to fix and the most worth fixing |
| Coordination of benefits | Another payer is primary, or the order of payers is unknown | Registration, and stale patient coverage data |
| Timely filing | The claim arrived after the contractual window | Workflow and follow-up. Nearly always fully preventable and nearly always a queue that nobody was watching |
| Provider enrollment and credentialing | The rendering provider is not active with this payer for this location | Credentialing. Concentrated in new hires and new locations, and highly predictable |
| Duplicate | A matching claim is already on file | Billing systems and resubmission behavior. Often an artifact of the follow-up process itself |
| Non-covered benefit | The plan does not cover this service for this member | Not preventable in billing. Preventable, sometimes, in patient financial counseling |
Read the third column again. Registration, pre-service, ordering, credentialing, follow-up. The denial shows up on a report owned by revenue cycle, and the behavior that produced it happened in a department with different priorities and no visibility into the consequence. That structural gap explains most denial programs that plateau: the analysis is correct, the feedback never reaches anyone who can act on it, and the same pattern reappears next quarter.
How preventable is each family, before the claim goes out — our read
Our judgment from building this kind of analysis, not a published benchmark. Your mix decides which rows carry the dollars.
The analysis that finds the money in an afternoon
Before anyone builds a model, run one query. Group your remittance data by payer, reason code, remark code, procedure code and rendering department. Sum the denied dollars and count the occurrences. Sort by dollars.
The result is nearly always a short head and a very long tail. The head is a small number of combinations, each of which corresponds to one specific behavior in one specific place. Typically several of them are unambiguous defects — a single clinic that never captures the secondary coverage, a procedure code that one payer requires a modifier on and the others do not, a provider whose enrollment lapsed at one location three months ago and whose claims have been denying quietly ever since.
This is not sophisticated. It is a group-by. It gets skipped because the data lives in a vendor system that renders it as a report rather than as a table, and getting the underlying remittance files into something queryable is the actual project. That project is usually a few weeks of work and it is the highest-return thing on this page.
One caution about the tail. Long-tail combinations are frequently not patterns at all — they are one-off events with no shared cause, and building rules for them creates maintenance without recovery. Work the head. Re-run the query monthly, because the head changes when payers update policy.
What about a model that predicts denials?
It is the standard pitch, and it is not useless, but it is usually sold one level too abstract to act on. A score saying this claim has an elevated chance of denial does not tell anyone what to change. A biller looking at a flagged claim with no reason will either clear it or hold it, and both are guesses.
Three things determine whether prediction earns its cost. Does the output name an actionable defect? “Likely to deny” is a score. “This payer has denied this code without this modifier on the large majority of recent claims” is an instruction. What is the base rate? If a small percentage of claims deny, a model with mediocre precision hands your team a queue that is mostly false positives, and they will stop trusting it inside a month. Could a lookup have done it? Very often the honest answer is yes: a table of payer-code-modifier combinations mined from your own remittance history, refreshed monthly, catches most of what a model catches, and it is explainable, auditable and cheap. Start there. If the deterministic rules leave real money on the table, that is when a model has a job.
There is a real use for learned models further out: estimating expected recovery on a denial so appeals can be prioritized. That is a genuinely probabilistic question, the label is clean because you eventually observe the outcome, and the decision it feeds is a resource allocation decision rather than a clinical or contractual one.
Deciding what to appeal
Most denial teams work the queue in the order it arrives, which means a small balance takes the same effort as a large one and a hopeless appeal takes the same effort as a strong one. The alternative is arithmetic, done once per denial family rather than per claim.
For each payer-and-reason family, you need three quantities: the average balance at stake, the historical overturn rate on appeal, and the average staff time an appeal consumes. Multiply the first two, compare against the third valued at a loaded hourly cost, and the families sort themselves into three bins. Appeal always. Appeal if the balance clears a threshold. Do not appeal, write it off and fix the cause.
That third bin is the one organizations resist and the one that frees the most capacity. Some denials are correct. Appealing them consumes staff time that would return more if spent on the preventable head of the distribution. Writing a denial off is not a concession; it is a decision, and it should be made deliberately with the overturn history in front of you rather than by default because the queue is worked in order.
Mistakes we see
- One denial rate, undefined, used in board reporting and in operational targets simultaneously
- Rejections and denials counted together, hiding the cheapest fixes and inflating the harder number
- Reason codes aggregated across payers, producing a chart with no actionable unit
- The metric owned by billing while the causes live in registration, ordering and credentialing
- Appealing everything, which is indistinguishable from having no prioritization at all
- A predictive score with no reason attached, delivered to staff who cannot act on it
- Remittance data trapped in a reporting tool, so the group-by that finds the money is never run
- Fixing the head once and not re-running the analysis when payer policy shifts
When you do not need help with this
If your remittance files already land in a warehouse and somebody can write a query against them, the analysis in this article is a day of work and you should do it yourself before talking to anyone. It requires no machine learning and no purchase, and doing it in-house means the person who finds the pattern is the person who can walk down the hall and fix it.
If your denial volume is small enough that one experienced person reads every remittance, you likely already know your patterns better than any dashboard would tell you. The gap in that case is usually durability — the knowledge lives in one head — and the fix is writing the payer-specific rules down, not buying a system.
Where outside help genuinely earns its cost is when the remittance data is not queryable at all, when it is spread across several billing systems after an acquisition and the payer identifiers do not reconcile, or when the feedback loop to the causing department has to be built as an actual product rather than a monthly email.
What a working denial program has
- An agreed definition of denial rate, written down, with the denominator named
- Rejections tracked separately and routed to the same root-cause process
- Remittance data in a queryable store, not only in a vendor report
- Analysis by payer-and-code pair, refreshed monthly
- Every pattern assigned to the department that causes it, not to the one that reports it
- Overturn rate by family, measured, and used to decide what gets appealed
- An explicit do-not-appeal list, reviewed rather than assumed
- Deterministic pre-submission rules mined from your own history before any model
- A named owner for reason-code list maintenance and a refresh date
- Preventable denied dollars as the headline metric, not the raw rate
Bottom line
Denials are not a rate to be lowered. They are a few dozen recurring, coded messages about defects that occurred upstream, and most of the recoverable money sits in a short list of payer-and-code pairs that a single query will surface. Get the remittance data somewhere you can query it. Run the group-by. Separate rejections from denials. Route each pattern to the department that causes it, with the dollar figure attached. Decide deliberately what you will not appeal. Do all of that before anyone builds a predictive model, because the model will mostly rediscover the same short list at considerably greater expense, and it will not tell your staff what to change.
Frequently asked questions
Published benchmarks exist but they are not comparable across organizations, because the denominator, the payer mix, the specialty mix and the treatment of rejections all differ. A target imported from a benchmark tends to drive reporting behavior rather than performance. Measure your own preventable denied dollars by pattern, set targets against your own trend, and use outside figures only as a rough sanity check.
Not until deterministic rules mined from your own remittance history have been in production for a few months and you can see what they miss. Those rules are explainable, cheap and immediately actionable, and they capture much of what a model would. A model earns its place when the remaining loss is genuinely probabilistic — prioritizing appeals by expected recovery is the clearest example.
Because coverage policy, edit sets and required modifiers are contractual and vary. This is why analysis has to be done per payer. It is also why a rule learned from your overall history will be wrong for individual plans, and why the useful unit of a pre-submission rule is always payer plus code rather than code alone.
Twelve to twenty-four months of remittance data is usually enough to see stable patterns while still reflecting current payer policy. Going further back adds volume and adds noise, because policies that changed will look like patterns that stopped. Whatever window you pick, re-run on a fixed cadence rather than once, since the top patterns move.
Reporting can sit in revenue cycle, but ownership of each pattern belongs to the department where the cause is. A denial for a lapsed enrollment is a credentialing metric. A denial for missing coverage information is a registration metric. Assigning every pattern to billing guarantees the analysis is correct and the behavior never changes.