Here is the uncomfortable pattern in revenue cycle right now. Roughly two thirds of provider organisations report using AI or automation somewhere in the revenue cycle. Initial denial rates over the same period have risen rather than fallen, and only around fifteen percent of those organisations report a positive return on the AI investment.
Two thirds adopting. Denials climbing. One in seven seeing a return.
That is not evidence that the technology does not work. It is evidence that most of it is being pointed at the wrong end of the process. Denials management is now the single largest source of revenue cycle leakage practices report, ahead of front end issues, billing and collections, and coding combined. Yet the majority of AI spend lands on appeals, which is the most expensive possible place to intervene, because by then the money has already been delayed and the rework already has to happen.
So this piece runs backwards. Start at the denial and walk back through the systems until you reach the moment the problem was actually created. It is rarely where the denial appeared.
Step back one: the appeal that never happened
The denial arrives. Someone decides whether to fight it.
The most quoted statistic in this category is that fewer than one percent of denied claims are appealed. It is worth being careful with that number, because the widely cited sub one percent figure comes from research into how often patients appeal coverage denials, not how often provider billing teams do. Provider side estimates are far higher, with hospital sector analysis suggesting a large share of denials, commonly put at up to sixty percent, go unappealed.
Either way the direction holds, and the important half of the statistic is the other half: first level appeals succeed more than half the time when providers actually file them. A denial is closer to an opening position than a verdict.
The system question. Does anything in your stack score a denial by recovery probability and route it automatically, or does a person triage a work queue by hand? Unrouted denials are where the never appealed share comes from. Nobody decides to abandon revenue. It just ages out of a queue.
Step back two: submission, where the payer answered in milliseconds
The claim went out. Something on the other side evaluated it and returned a rejection faster than any human could have read it.
This is the asymmetry that defines the current environment. A payer algorithm pattern matches documentation against code specific requirements in real time. The provider response runs through staff queues, appeal letters, and a wait that can push resolution forty five to ninety days past the date of service. Milliseconds on one side, weeks on the other.
In the American Medical Association's 2025 survey, seventy five percent of physicians reported prior authorisation denials increasing over five years, and sixty one percent attributed the increase specifically to payer use of AI.
The system question. Is anything checking the claim against payer specific rules before it leaves? Pre submission scrubbing against the rules of the specific payer, not generic edits, is the highest leverage automation available in the whole cycle, and it is the least glamorous. This is ordinary workflow automation work rather than anything exotic.
Step back three: documentation and coding
The claim was assembled from what the clinician wrote and what the coder derived from it. Denials citing medical necessity almost always trace here.
One practical detail worth carrying into any build. Denial reasons that sound similar require different responses. Not medically necessary and insufficient documentation of medical necessity are distinct problems, one contesting the clinical decision and the other contesting the record of it. Systems that bucket both into a single denial category produce work queues that cannot be worked efficiently, because the response strategy differs.
The system question. Can your systems cross reference clinical documentation against payer medical necessity criteria at the point of documentation rather than after submission? That is a genuine use for AI development in revenue cycle, and it is upstream, which is the point. It also depends on reaching the clinical record cleanly, which is a custom EMR and EHR development and integration problem before it is a model problem.
Step back four: registration, and the fields nobody validated
Now we are usually at the origin. Eligibility mismatches, demographic errors, and coverage details captured wrongly at registration are a leading and entirely preventable denial category.
Nothing about this is clinical. It is a data capture problem that happened before the patient was seen, and it is why intake and revenue cycle are the same subject viewed from different departments. The field a patient mistyped, or that staff retyped from a photograph of an insurance card, becomes a rejection weeks later, at which point the cost of fixing it has multiplied.
The system question. Does eligibility get verified electronically at registration, and do the verified values write into the system of record rather than sitting in a separate tool? This sits directly with intake forms software, and it is the clearest example in healthcare of a problem that is cheap at the source and expensive everywhere else.
The regulatory lever most providers do not use
One fact worth knowing, because it changes what an appeal can argue.
CMS's 2024 Medicare Advantage rule bars payers from denying care based solely on an algorithm where that determination conflicts with the patient's actual medical history or the treating physician's notes. That is a narrow provision and it is not a general prohibition on automated adjudication. But it means an algorithmic denial that contradicts the documented record is contestable on grounds beyond clinical disagreement.
For a software team the implication is concrete. If your systems can demonstrate, from the record, that the denied determination conflicts with documented history, that evidence is worth surfacing automatically rather than leaving it for a coder to reconstruct by reading the chart. Build the evidence assembly, not just the letter.
As ever with a regulatory point, confirm the application with counsel or a compliance lead rather than with an article.
Why most revenue cycle AI is not paying off
Return to the opening contradiction. Adoption up, denials up, returns rare. Three reasons show up consistently.
It is deployed downstream. Automated appeal drafting is useful and it is rework acceleration, not prevention. Making the expensive path faster does not make it cheap.
It is generic rather than payer specific. Denial patterns are payer specific and code specific. Automation built against generic rules catches generic problems, and the revenue is leaking through the specific ones.
It replaces people instead of triaging for them. The organisations that get results consistently treat automation as a triage layer feeding an experienced human team, rather than as a substitute for one. Complex appeals still need judgement, and the models that work are the ones that put the right claim in front of the right person with the evidence already assembled.
The number to build against
One metric decides whether any of this worked: the first pass rate, meaning the share of claims paid on first submission.
It is the right measure because it is the only one that improves when the fix is upstream. Appeal win rate improves when you get better at rework. Days in accounts receivable improves for several unrelated reasons. First pass rate moves only when fewer claims are wrong on the way out.
Track it by payer and by service line rather than in aggregate, because an aggregate figure hides exactly the payer specific patterns that are causing the leakage. That is a reporting problem rather than a billing one, and it sits with healthcare data analytics platform work.
Where Woltrio fits
Woltrio builds the systems that produce claims rather than billing services that chase them, which puts the work at steps three and four of the trace above.
In practice that means eligibility verification that writes back cleanly at registration, documentation and coding support that runs against payer specific criteria before submission, denial routing that scores by recovery probability instead of queueing chronologically, and reporting that exposes first pass rate at a granularity fine enough to act on. The broader capability set sits under services.
The framing that tends to change the conversation is the one this article opens with. A denial is not a billing event. It is a software decision made weeks earlier, in a system that did not check something it could have checked. Fixing it in the billing department is fixing it in the most expensive place available.
Start with a scoped discovery from Woltrio.