The Highest-ROI AI in a Hospital Is in the Billing Office

Walk into any hospital’s business office and you will find a worklist: a queue in a legacy revenue cycle module, sorted by nothing useful, holding several thousand denied claims. A team works it top to bottom. Some of those claims are worth appealing; some are dead on arrival because the filing window closed while they sat in the queue. Nobody in the room can tell which is which until they open each one.

That queue is the most under-served AI problem in the building and nowhere near the most fashionable one. The board wants to talk about a diagnostic model, which carries a regulatory tail, an evidence burden, a validation study, and a failure mode measured in patient harm. Meanwhile the billing office sits on a decade of structured claims data with objective, dated outcome labels on every record — paid or denied, and if denied, exactly why — where the worst thing a wrong prediction does is generate a resubmission.

The economics are not subtle#

Kodiak Solutions, which benchmarks revenue cycle performance across roughly 2,300 US hospitals, reported the average initial denial rate rising to 11.6% in 2025 from 11.4% the prior year, and net revenue lost to final denials and bad debt growing 25% year over year — over $48 billion across that cohort, up from $38.6 billion. The initial denial rate barely moved. The money that never came back moved a lot.

The provider-side view matches. Experian Health’s 2025 State of Claims survey found 41% of providers reporting denial rates over 10%, up from 30% in 2022, with 68% saying clean-claim submission is harder than a year earlier — and 67% believing AI can improve the claims process against only 14% actually using it for denials. That gap is the opportunity. It is also a warning that the hard part is not the model.

The denial pipeline is a data problem with five failure points#

A claim does not get denied at the end. It gets denied at the point where a piece of information was missing, wrong, or never reconciled — and then the denial arrives thirty days later, detached from its cause.

• Eligibility. Coverage was inactive, the plan changed at the start of the month, or the patient was registered under a stale payer ID from a prior visit. Fails at registration, usually because the eligibility check was a batch job that ran the night before rather than a live call at check-in.
• Prior authorisation. The auth was never obtained, covered a different CPT than the one performed, expired before the procedure, or named a different site of service. Fails in the gap between scheduling and the OR.
• Coding. The assigned code exceeds what the documentation supports, modifiers are missing, or the diagnosis does not establish medical necessity.
• Documentation sufficiency. The care happened and was coded correctly, but the note lacks the specific language the payer’s policy requires to prove it. The most annoying category, because clinically nothing was wrong.
• Timely filing. A correct, appealable claim sat in a queue past the window. Pure operational loss, no clinical or coding component at all.

Each has a different owner, system of record, and lead time — which is exactly why a single “denial model” bolted onto the claims table underperforms. Four of the five causes originate upstream of the claim, in data the claim never carries.

Denial prediction needs the claim’s history, not its line items#

The naive framing is a classifier over the 837 — codes, charges, payer, place of service — predicting denial probability. It works well enough to demo and poorly enough to abandon, because the signal is not in the final artifact. It is in the trajectory that produced it.

The features that carry weight are temporal and relational: days elapsed between the auth request and the service date; whether the eligibility response at registration matched the payer on the claim; whether documentation was signed before or after coding; how often this payer denied this CPT–diagnosis pair on this service line in the last ninety days; whether the referring physician’s notes historically require a CDI query. Two claims can be identical on the wire and carry very different risk on the strength of their histories alone.

So treat denial prediction as a data engineering problem before a modelling one. You need an event stream, not a snapshot — registration, auth, charge capture, coding, edits, submission, remittance — joined on encounter and ordered in time. Most hospitals generate every one of those events. Almost none have them in one queryable place. The model is a week of work once the event store exists, and the event store is where the project actually lives.

History matters for a second reason: payer behaviour drifts. Policies change, edits get added, a payer starts demanding documentation for a code it paid without question last year. A model trained on last year’s mix degrades silently unless you monitor denial reasons as a distribution over time and retrain on recent windows. Policy drift is a first-class monitoring signal, not a modelling afterthought.

Coding support is retrieval and a documentation check, not generation#

The temptation with coding is to point a language model at a note and ask for codes. Do not. Code assignment has a right answer defined by a published, versioned rule set and a payer’s policy — a retrieval and constraint-checking problem, where generative freedom is a liability.

The version that works retrieves candidate codes with their guideline text attached, checks the note against the documentation elements each code requires, and surfaces the specific gap. Not “code this as X” but “this code requires documented laterality and acuity; the note has neither; here are the two sentences that come closest.” Make the coder faster and the CDI query more precise; do not replace the judgement call.

Appeals follow the same discipline. A model that drafts an appeal letter is mildly useful. A system that retrieves the payer’s own published policy, pulls the record passages satisfying each criterion, and hands a human a stack of citations with the gaps flagged is far harder to argue with.

Surface evidence, not a verdict#

The instinct in AI implementation is to output a decision. In revenue cycle, the decision output is what kills adoption. A billing specialist handed “denial risk: 0.83” has no idea what to do. Handed “this payer denied this CPT-diagnosis pair 40 times last quarter, the auth on file expired eleven days before the service date, and the note is missing the medical-necessity language the policy names,” they fix the claim in four minutes and trust the system next week.

There is a regulatory argument for the same design. States have moved fast on automated determinations in health insurance — Texas barred utilization review agents from issuing an adverse determination via an automated system without human oversight, California’s SB 1120 requires AI-assisted utilization review to rest on individual clinical history, and Maryland now requires reporting on whether AI was used in adverse decisions (Holland & Knight tracks the 2026 wave). Those laws point at payers, not providers, but the direction of travel is clear: systems that produce evidence for a human decision age well; systems that produce autonomous determinations acquire a compliance surface.

Prior authorisation is where this bites soonest. Under CMS-0057-F, impacted payers must return prior-auth decisions within 72 hours for urgent and seven calendar days for standard requests as of January 2026, publish approval and denial metrics, and stand up FHIR APIs including a Prior Authorization API by January 2027. Providers with auth data in a queryable platform will consume those APIs and that published payer data. Providers whose auth history lives in a fax log will not.

Measure in dollars recovered and days in A/R#

The fastest way to lose a revenue cycle AI programme is to report model accuracy to a CFO. The metrics that matter are the ones the finance office already runs: net collection rate, initial denial rate by payer and reason, final denial write-offs, cost to collect, days in accounts receivable. It is entirely possible to improve AUC while moving none of them — by getting very good at predicting the denials the team was already catching.

Two habits are worth enforcing. Attribute recovery to intervention — a claim flagged, corrected pre-submission, and paid is a tracked dollar, and that tracking must be built in from day one rather than reconstructed later. And watch the front-end rate, not just the back-end one: the point of Operational Automation here is to stop denials being generated, which shows up as fewer claims entering the worklist rather than better performance inside it. If the appeals team gets busier, something is wrong.

The upstream leverage is real. The AMA’s 2025 physician survey found that among appealed prior-authorisation denials, 81.7% were overturned fully or partially — but only 11.7% were appealed at all, most non-appealers citing past futility. Money is being left on the table by triage decisions made without evidence. That is a ranking problem, and ranking is what these systems are good at.

The precondition: the ERP has to become a data platform#

None of this is reachable while the data is trapped. The standard hospital estate is a Hospital Management System covering registration, scheduling, orders, charge capture, and billing — every module emitting exactly the events a denial model needs, and every module exposing them through a report writer, a nightly extract, and a support ticket. Legacy ERP vendors optimised for transaction integrity and printed reports, and the reporting layer is where the analytical value goes to die.

Getting to a queryable event store is the actual project: change data capture off the operational tables, an encounter-keyed event model, remittance and denial reasons joined back to the originating events, and a warehouse the team can query without a vendor in the loop. It is the same argument we make about School ERP deployments and about Data Platforms generally — the ERP should be a data platform with a thoughtful UI on top, not a vault with an export button.

Do that and the AI is almost anticlimactic: a gradient-boosted model over well-built features predicts denial risk credibly, a retrieval layer over the code set and payer policies supports coders, and a ranking model tells the appeals team which twenty claims to work today. Those things are missing from most hospitals not because the models are hard, but because nobody built the pipe. So start with the unglamorous version — eligibility, auth, coding, and remittance events in one place keyed by encounter, denial reasons reported weekly by payer, an appeals queue ranked by expected recovery instead of by date. It pays for itself before a single model is trained.

---

The billing office has the cleanest labels, the fastest feedback loop, and the lowest blast radius in the hospital — start there. Tell us what your denial data looks like at /#contact.