← Blog
Foundations

Agentic AI in Revenue Cycle: Denials, Appeals, Failure Modes

Thien Nguyen · Nov 11, 2026

Agentic AI in revenue cycle management works best on denials: it reads the 835 remittance and denial codes, gathers the evidence, drafts the corrected claim or appeal, and queues it for a human. In 2025, 41% of providers reported denial rates of 10% or higher, and 90% of denials still got human review before resubmission. Keep it that way.

Revenue cycle is where healthcare AI agents are being bought fastest in 2026, because the work is high-volume, rule-heavy and measured in dollars. It is also where they fail in expensive ways: a wrong appeal argument, a resubmission that triggers a duplicate-claim edit, or a payer portal script that quietly stops working. This guide covers the numbers, a reference architecture, the failure modes we design against, and the regulatory pressure from the payer side.

How big is the claim denial problem in 2026?

Big and not shrinking. Experian Health's 2025 survey found 41% of providers face denial rates of 10% or higher, a share that has grown each year since 2022. KFF found that HealthCare.gov insurers denied 19% of in-network claims in 2024, and fewer than 1% of denials were appealed.

From the Experian Health State of Claims 2025 press release (250 respondents responsible for financial, billing or claims decisions):

  • Top denial causes: missing or inaccurate data (50%), authorizations (35%), and incomplete or inaccurate registration data (32%).
  • 90% of denials are reworked with at least some human review before resubmission.
  • 67% believe AI can improve claims, but only 14% use it. Barriers named include unproven accuracy, unproven HIPAA compliance and doubts that AI can handle payer-specific rules.

From KFF's March 2026 analysis of 2024 Marketplace data: in-network denial rates ranged from 3% to 36% across insurers, out-of-network denials were 37%, and insurers upheld 66% of the appeals that were filed. The listed reasons skew administrative: 25% administrative, 13% excluded service, 9% missing prior authorization or referral, 5% medical necessity, and 36% "other."

Read together, the data says most denials are data and process problems, not clinical disputes. That is exactly the kind of work an agent can prepare well, if it has the right data and a human signs off.

Bar chart of reasons for in-network claim denials by HealthCare.gov insurers in 2024: other or unlisted 36%, administrative 25%, excluded service 13%, lack of prior authorization or referral 9%, medical necessity 5%. Overall 19% of in-network claims were denied and fewer than 1% of denials were appealed.
Most denials are data and process problems

What does an agentic AI system for denials actually do?

It turns each denial into a worked case: classify the reason, pull the claim, remittance, chart and authorization evidence, decide the likely fix (correct and resubmit, appeal, or write off), draft the output, and route it to the right person with the evidence attached. A human approves before anything goes to a payer.

Denial categoryTypical signalWhat the agent preparesHuman decision
Registration / eligibilitySubscriber or member ID mismatchRe-run eligibility (270/271), corrected demographics, corrected claimApprove resubmission
Missing authorizationNo auth on file for the serviceSearch for an existing auth; draft retro-auth request if the payer allowsSubmit or write off
Coding / bundlingCode edit or modifier issueProposed code change with the supporting documentation excerptCoder approves the change
Medical necessityClinical criteria not metAppeal draft citing chart evidence and the payer's policyClinician reviews and signs
Timely filingSubmitted past the limitProof of timely submission if it existsAppeal or write off

The ordering matters. Start with the administrative categories, where the evidence is structured and the fix is checkable. Leave medical necessity appeals for later, when you have measured accuracy on the easier ones.

What is the reference architecture for an RCM agent?

Five layers: ingestion of 835s and denial worklists, a case store that joins claim, remittance, chart and authorization data, an agent orchestrator with narrow tools, a human review queue, and outbound submission through your clearinghouse or payer APIs. The model never talks to a payer directly.

1. Ingestion

Parse X12 835 remittances and normalize CARC and RARC codes into your own categories. Pull denial worklists from the practice management system or EHR. This layer is plain software and should be deterministic.

2. Case store

One record per denial, linking the original 837 claim, the 835 line, the authorization record and the relevant clinical documents. Most agent failures we see trace back to a case that was missing one of these.

3. Orchestrator and tools

The agent gets narrow, read-mostly tools: "get claim lines," "get remittance for claim," "search notes for this date of service," "check eligibility," "find authorization." Write tools only create drafts. Payer-specific rules (timely filing limits, appeal levels, required forms) live in versioned configuration, not in the prompt.

4. Review queue

Each draft shows the denial, the proposed action, the evidence with links to source documents, and a confidence label. Reviewers approve, edit or reject, and every decision is logged. Rejections become evaluation data.

5. Submission

Approved corrections go out as 837s through the clearinghouse. Appeals go through payer portals or APIs. As payers bring Prior Authorization APIs live under CMS-0057-F, the authorization step gets cleaner; see our guide to the 2027 CMS prior authorization API deadline.

Five layers of a revenue cycle denial agent: ingestion parses X12 835 remittances and normalizes CARC and RARC codes; a case store joins the 837 claim, 835 line, authorization and chart documents; the agent uses narrow read tools and draft-only writes with payer rules in versioned configuration; a review queue lets a biller, coder or clinician approve, edit or reject; submission sends corrected 837s through the clearinghouse and appeals through payer channels.
The model never talks to a payer directly

Where do RCM agents break?

They break on missing context, payer rule drift, portal automation, and unmeasured accuracy. None of these are model problems you can prompt away; they are data, integration and evaluation problems.

  • Missing context. The agent drafts an appeal without the operative note because the document was scanned and never indexed. The draft reads well and is wrong. Fix: the case is not "ready" until required documents are present.
  • Payer rule drift. Appeal deadlines, forms and policies change. If rules live in the prompt, nobody notices. Keep them in versioned config with an owner.
  • Duplicate submissions. A resubmitted claim without the correct frequency code or original claim reference triggers a duplicate denial. Make submission idempotent and check claim history first.
  • Portal automation. Scripting payer portals with stored passwords breaks on every UI change and usually conflicts with portal terms. Prefer clearinghouse and API routes; leave portals to people when there is no API.
  • Hallucinated citations. An appeal that quotes a policy section that does not exist damages credibility with that payer. Require every citation to resolve to a stored source document.
  • No baseline. Without overturn and first-pass rates from before the agent, you cannot tell whether it helped.

We cover the broader pattern in why AI agent projects fail and how to measure them in LLM testing for regulated industries.

How should you measure an RCM agent?

Measure outcomes per denial category against a pre-agent baseline: overturn rate on appeals, first-pass acceptance of corrected claims, days from denial to resubmission, reviewer edit rate, and dollars recovered net of write-offs. Accuracy of drafts matters only as it moves those numbers.

  • Reviewer edit rate per category tells you where the agent is ready for less oversight and where it is not.
  • Rejection reasons from reviewers should be categorized and fed back into evaluation sets.
  • Payer-level breakdowns catch rule drift early: a sudden drop in overturns at one payer usually means a policy changed.
  • Cost per worked denial, including model and infrastructure cost, against the dollars at stake. Small-balance denials may not be worth an appeal at all. See what it costs to run an AI product.

What is the controversy about payer-side AI?

Payers use algorithms to review and deny care, and regulators are pushing back. A 2024 Senate investigation found UnitedHealthcare's post-acute prior authorization denial rate rose from 10.9% in 2020 to 22.7% in 2022 and documented internal work on machine learning tied to those cases. California now requires licensed clinicians to make medical necessity decisions.

The Senate Permanent Subcommittee on Investigations report (October 2024) focused on UnitedHealthcare, Humana and CVS; UnitedHealthcare disputed its characterization. California's SB 1120, in effect since January 2025, requires that medical necessity determinations by health plans be made by a licensed physician or qualified health care professional, not by an algorithm alone. Federally, CMS's WISeR model, which uses AI to support prior authorization review in Original Medicare in six states from 2026, states that licensed clinicians determine non-payment recommendations.

For provider-side RCM teams, this cuts two ways. Payer AI may increase denial volume, which raises the value of working denials quickly. And regulators are signaling the same standard for everyone: a qualified human owns the consequential decision. Build your agent to that standard now.

Should you build an RCM agent or buy one?

Buy if a vendor already covers your payers, specialties and PM system with measurable results, and will sign a BAA. Build, or extend a bought platform, when your payer mix is unusual, your data is spread across systems the vendor does not connect to, or you need the agent inside your own workflow tools and audit trail.

Questions to ask any vendor: Which denial categories do you automate end to end, and which only draft? What is your reviewer edit rate per category on customers like us? Where does PHI go, and which subprocessors are in the BAA? Can we export every decision and its evidence? Our AI agent cost guide walks through the build side of the comparison.

How BeevR builds this

We build RCM agents as case-based systems: deterministic ingestion of 835s and worklists, a case store that joins claim, remittance, authorization and chart evidence, an agent with narrow draft-only tools, and a review queue where your billers, coders and clinicians approve every outbound action. Payer rules live in versioned configuration with an owner. Every draft, edit and approval is logged. BeevR signs a BAA as a business associate, and the model can run inside your own AWS account under the AWS BAA, with minimum-necessary PHI sent to it.

We are a senior, founder-led team in Hanoi, 5.0 on Clutch, working in fixed-price phases from $10K per phase, with a working demo every Friday and full IP ownership from day one. Read more on healthcare AI agent development, or book a 30-minute call to walk through your denial data.