How to Use AI to Manage and Prevent Claim Denials

By Clayton Severson, Principal Consultant · Published August 11, 2026

AI does four useful jobs in denial management: it groups denials by root cause instead of reason code, ranks the work queue by recoverable dollars instead of age, flags claims likely to be denied before submission, and drafts appeals from the payer's own policy language. It should not decide medical necessity, write-offs, or patient balances.

Denial management has a specific failure pattern, and it is not laziness. A biller opens a work queue sorted by date, sees 1,400 denials, works the top forty, and the rest age out of the appeal window. Nothing in that process asks which denials are worth the most, which share a single fixable cause, or which should never have been submitted. That is a prioritization and pattern-recognition problem, which is exactly the shape of problem machine learning is good at — and exactly the shape of problem that buying "AI for denials" without fixing your data will not solve.

How much do denials actually cost?

Enough that the arithmetic on fixing it is not close. Premier's analysis of 2023 data from 280 hospitals across 23 states found that roughly 15% of claims submitted to private payers were initially denied, reaching as high as 49% in some cases, and that providers spent $25.7 billion adjudicating claims with payers that year. The average cost to fight a single denied claim was $57.23, up from $43.84 the year before.

The number that should change behavior is the outcome: Premier found approximately 70% of appealed denials were ultimately overturned and paid. Premier put roughly $18 billion of that $25.7 billion in the "potentially unnecessary" column on exactly that basis — most of the fight ends with the payer paying anyway.

The contrast on the patient side is starker. KFF's review of HealthCare.gov qualified health plans found insurers denied 19% of in-network claims in 2024 and 37% of out-of-network claims, about 20% of all claims — with in-network denial rates ranging from 3% to 36% depending on the insurer. Consumers appealed under 1% of those denials, roughly 263,000 internal appeals against about 85 million denied in-network claims, and insurers upheld 66% of the appeals they did receive.

Read those two datasets carefully, because they measure different populations — Premier is provider appeals on hospital claims, KFF is consumer appeals on marketplace plans, and the denominators are not comparable. What they agree on is the shape of the problem: denials are common, appeals work far more often than people assume, and the overwhelming majority of denials are never contested at all.

Which denials are preventable?

Most of them, and the payers' own stated reasons say so. Here is KFF's breakdown of why in-network marketplace claims were denied in 2024, with the preventability read in the right-hand column.

Stated reason	Share of in-network denials	Where it gets fixed
"Other" — reason not listed	36%	Nowhere, until you make the payer specify — this is the finding, not a category
Administrative	25%	Front end: registration, eligibility, coding, claim scrubbing
Excluded service	13%	Eligibility and benefit verification before the visit
Lack of prior authorization or referral	9%	Scheduling and pre-service authorization workflow
Medical necessity	5%	Clinical documentation and the appeal itself
All remaining categories (investigational or cosmetic, benefit maximum reached, member not covered)	12%	Eligibility, benefit design, and enrollment data — rarely a billing fix

Source: KFF analysis of HealthCare.gov QHP transparency data, plan year 2024. Percentages are for in-network claims. KFF publishes shares for the first five categories; the final 12% is the remainder across the categories it does not break out individually.

Two things fall out of that table. First, medical necessity — the fight everyone braces for — is about 5%. The denials that actually drain revenue are clerical. Second, the single largest bucket is "other," at 36% — more than administrative and medical necessity put together, and no stated reason at all. That is a data problem before it is a billing problem: you cannot fix a root cause the payer never named, which is precisely why grouping denials by your inferred cause rather than their stated code is where AI earns its keep.

What can AI actually do about denials?

Four jobs. They are worth doing in this order, because each one makes the next cheaper.

Job	What it does	What it needs
Categorize	Clusters denials into root causes across reason code, payer, provider, code pairing, and site of service	835 history with CARC/RARC at line level, joined to the submitted 837
Prioritize	Ranks the queue by recoverable dollars and appeal-window urgency, not claim age	Contracted rates, historical overturn rates by denial type, filing deadlines
Predict	Scores claims pre-submission for denial risk so they get fixed before they go out	Paid claims as well as denied ones — a model needs negatives
Draft	Writes the appeal letter grounded in the payer's own policy and your documentation	Payer policy corpus, clinical notes, retrieval that cites sources

How does AI categorize denials to root cause?

By treating the reason code as one feature among many rather than as the answer. A denial carries far more signal than CO-16: the payer and plan, the rendering and referring provider, the code and modifier combination, place of service, whether an authorization number was present, the days between service and submission, the claim's dollar value, and the specific RARC text that qualifies the CARC. Cluster on all of it and the shapeless mass of "claim lacks information" resolves into a handful of concrete operational failures.

That is the analysis that converts a 1,400-claim queue into a five-line memo: one payer rejecting a modifier combination since a policy update in March, one clinic location omitting a required field, one provider's credentialing lapsed for a single plan. Three fixes retire most of the volume. The reason codes themselves are covered in detail in the most common medical billing denial codes and how to fix them; the point here is that the code is the starting input, never the conclusion.

Note what this requires that most shops do not have: the 835 joined back to the 837. Knowing a claim was denied tells you nothing actionable without knowing exactly what was submitted. If your denial data and your claim data live in systems that cannot be joined at line level, that integration is the project — not the model.

Can AI predict a denial before you submit the claim?

Yes, and this is where the money is, because a denial prevented costs nothing to appeal. A model trained on your own paid-and-denied history scores each claim before it leaves the building, against the same feature set used for categorization. Claims above a risk threshold route to a human for review instead of going out the door.

Three constraints decide whether this works. It has to train on your data, because denial behavior is payer-specific and market-specific — a vendor model trained on somebody else's book will find somebody else's patterns. It needs paid claims as well as denied ones, which sounds obvious and is the most common data-collection mistake. And it needs a defined action: a risk score that no one is staffed to act on is a dashboard, not a control.

Be honest about the ceiling. Prediction works well on administrative and authorization denials, which is most of the volume, because the patterns are deterministic and repeat. It works poorly on medical-necessity denials, where the payer is making a judgment call on clinical facts. Do not buy a prediction system on the promise that it will stop the 5%.

Should AI write your appeal letters?

It should write the draft. Appeals are the highest-leverage use of a language model in the revenue cycle, because the task is exactly what LLMs do well: take a payer's policy document, your clinical documentation, and the denial rationale, and produce an argument that connects them. Retrieval over the payer's own published medical policy is what separates a real appeal from a template — an appeal that quotes the payer's coverage criteria back at them and shows the chart meets each element is a materially different document from "please reconsider."

The hard rule is that a human verifies every factual claim and citation before it is sent. A fabricated policy number or a misquoted coverage criterion does not merely lose that appeal; it damages your credibility with that payer's review staff on every subsequent one. Build the workflow so the model must cite a retrieved source for each assertion and the reviewer can click through to it. If your appeal system cannot show its sources, it is not ready to send anything.

What should AI never decide?

Three decisions stay with people, and the reasons are different in each case.

• Medical necessity. Whether care was warranted is a clinical judgment. A model can surface the documentation that supports the case and identify which coverage criteria are unmet. It cannot be the one to conclude the service was not necessary, and a provider organization that lets it will not enjoy explaining that to a licensing board.
• Write-offs. Adjusting a balance off the books is a financial control with audit implications. AI can rank claims by expected recovery and recommend which are not worth pursuing. A human with authority signs the adjustment.
• Patient balances. What a patient owes is where a billing error becomes a real consequence for a real person, and increasingly a regulatory one. Automate the calculation, review the output, never let it bill unattended.

Underlying all three: claims and remittances are protected health information. Any AI vendor that processes them is a business associate and needs a signed BAA before data moves — the specifics are covered in can you use ChatGPT with PHI and, for the Azure path, is Azure OpenAI HIPAA compliant. Pasting a denial into a consumer chatbot to "just check something" is a breach, no matter how the prompt is worded.

Where should you start?

In this order, because each step de-risks the next and the first two require no model at all.

1. Get the 835s parsed to claim-line detail and joined to the 837s. Everything downstream depends on it, and this is usually where the real work is. If you cannot answer "what did we submit and what came back, line by line" in SQL today, start here.
2. Measure the baseline. Denial rate by payer and by reason code, dollars denied, current overturn rate, average days to work a denial, and the share aging out unworked. You cannot show improvement against a number you never took.
3. Cluster to root cause and fix the top three. This is where the first real money appears, and it typically appears without any predictive model — just honest analysis of data you already had.
4. Add prediction once the front-end fixes are in. Predicting denials you have already eliminated is wasted effort. Sequence matters.
5. Automate appeal drafting last, with retrieval and source citation from day one, and track overturn rate as the acceptance test.

The unglamorous truth is that steps one through three are data engineering, not artificial intelligence, and they produce most of the return. Vendors sell step five. Buy it after you have done the rest, or you will be paying a subscription to write elegant appeals for denials you should have prevented.

Frequently asked questions