Revenue Cycle Automation with AI Agents

Unevenly. Some steps are solved and have been for years, some are genuinely changed by language models, and some are marketed as automated while remaining a person in a chair. This is our read as of mid 2026.

Three of these have their own pages because they carry enough operational and regulatory detail to need one: medical coding automation, denial management and prior authorisation automation. The rest are covered below.

The standard transaction is close to fully automated already, and has been for years. What is not automated is everything the transaction does not return: whether this specific plan covers this specific service at this site, what the accumulator looks like today, whether a referral is required, and whether the patient's coverage changed since the appointment was booked.

Those gaps are why practices still call payers. Voice agents that place those outbound calls, wait on hold and record structured answers are one of the more convincing applications in the whole cycle, because the task is bounded, the output is checkable and the alternative is a person losing forty minutes.

Two design points decide whether it works. First, re-check timing: a coverage check run at booking and never repeated is the single most common source of front end denials, and the fix is a scheduled re-check inside 72 hours of service rather than a smarter check at booking. Second, what happens to the answer: an eligibility result that lands in a work queue rather than on the registration screen changes nothing, and this is where most eligibility projects quietly fail.

The same coverage data feeds patient estimates and the intake conversation, which is why we usually scope this alongside the patient intake agent rather than as a standalone revenue cycle project.

This is the step with the largest theoretical saving and the largest downside, and it deserves to be treated separately from the rest of the cycle for exactly that reason.

Charge capture, meaning catching services that were delivered and never billed, is the low risk half. An agent that reconciles the schedule, the documentation and the charge file and flags gaps produces a defensible list that a human works. Missing charges are pure recovered revenue and carry none of the exposure that changing a code carries.

Coding itself is the exposed half. Assisted coding, where a certified coder approves every line, changes throughput without moving accountability. Autonomous coding, where a defined slice of charts goes to billing untouched, changes the operating model and requires governance that most organisations do not have on day one. The CMS Comprehensive Error Rate Testing programme put the Medicare fee for service improper payment rate at 7.66 percent for fiscal 2024, and documentation and coding error rather than fraud accounts for most of it, which is a reminder that this step is already the largest source of payment error before any automation is added.

The full treatment, including how to read vendor accuracy claims and what happens to the coding team, is on the medical coding automation page. If you take one rule from it: a blind audit sample, measured before deployment and monthly after, is the control that makes everything else defensible.

Yes, and they are the least glamorous and most reliable wins in the cycle. Neither one involves a clinical judgement, neither one creates audit exposure, and both consume real hours.

Claim status is the safest automation in the whole revenue cycle. An agent polls the standard 276/277 transaction, calls or checks a portal where the transaction returns something uninformative, and escalates only claims that have stalled beyond a threshold. The saving is not dramatic per claim. It is that nothing sits unnoticed for sixty days, which is where timely filing losses come from.

Payment posting is nearly as safe and has a hidden benefit. Automating the reconciliation of remittance to claim, including the paper remits and correspondence that still arrive, produces a clean, structured record of what was actually paid line by line. Without that record, underpayment detection is impossible and denial root cause analysis is guesswork. Posting is therefore the foundation for the two steps that produce the most money, and it is usually attempted last.

Our recommendation on sequencing is unpopular and consistent: fix posting quality before buying analytics. Clustering models built on badly posted data produce confident findings about nothing, a point we make again on the denial management page.

Because an underpayment does not announce itself. A denial arrives as a denial and lands in a queue. An underpayment arrives as a payment, gets posted, and closes the balance. Nobody looks again.

The mechanism is simple and the tooling is mature. Model the contracted rate for each payer and service, reprice every paid line against it, and flag variance beyond a tolerance. Where an agent adds something over the traditional contract management module is in the messy parts: reading amendments and fee schedule updates out of PDFs, handling the carve outs and stop loss terms that never made it into the model, and drafting the variance letter.

The blocker is almost never technology. It is that the contract terms have not been loaded, or were loaded three amendments ago, and nobody owns them. If you are assessing readiness for this step, the only question that matters is who in your organisation can produce the current, complete fee schedule for your top five payers today. If the answer is nobody, no tool will help until that changes.

In roughly half the revenue cycle assessments we run, underpayment recovery is a larger identified opportunity than denial recovery, and it is almost always the one nobody has a project for. We test for it explicitly during an AI readiness audit.

They are the two ends of the same problem. A prior authorisation that was never obtained is a denial waiting to be filed, and a denial for lack of authorisation is a prior authorisation that failed several weeks earlier.

Denials are where the industry's attention sits, and there is real money there: Premier's survey of 280 hospitals put total provider spend on claims adjudication at 25.7 billion US dollars, of which roughly 18 billion went on claims Premier judged should have been paid the first time. Root cause clustering, workqueue ranking by expected recovery and drafted appeal letters all work, and the honest arithmetic of when to appeal and when to write off is set out on the denial management page. Before you scope anything there, check whether your denial rate is unusual at all using the denial rate benchmark.

Prior authorisation is the least automated transaction the CAQH index measures and the one where regulation is actively changing the terrain. The CMS Interoperability and Prior Authorization Final Rule imposes decision timeframes, specific denial reasons and a set of FHIR APIs on affected payers, with the API obligations landing on a later date than the operational ones. That changes what is buildable, and the current timeline is on the CMS prior authorisation rule page. The workflow itself is covered on the prior authorisation automation page, and the vendor landscape on our prior authorisation software comparison.

Most organisations should extend before they buy, and almost none should build. The reason is not technical. It is that revenue cycle value comes from data completeness across the whole chain, and every additional vendor adds a boundary where that completeness is lost.

• Extend. Your EHR, your clearinghouse and your existing revenue cycle platform all now ship automation modules. They are rarely best in class and they are already integrated, already under a business associate agreement and already understood by your team. For a first project this usually wins on total cost even when the feature list is thinner.
• Buy a specialist. Justified where one step is both your largest leak and genuinely poorly served by your incumbent, most often underpayment detection or payer phone work. Insist on a defined data return path so the specialist's findings land back in your system of record rather than in its own dashboard.
• Build. Only defensible for a payer specific integration nobody sells, and only where you already run an engineering team that will still exist in three years. The build cost is not the problem. The payer change management is.

The decision that saves the most money is the one made before any of this: which two steps are you actually fixing this year. Organisations that scope the whole cycle at once take eighteen months to prove anything and usually lose their sponsor first. We set the sequence and the measurement plan in a deployment roadmap, and select the vendor against it rather than the other way round.

Less than a clinical agent and more than most finance teams expect, because these systems touch protected health information continuously and make decisions that show up in an audit.

The baseline is a signed business associate agreement covering every subprocessor, explicit retention terms, a documented position on whether your data trains shared models, and access logging that matches the rest of your estate. That ground is covered on the HIPAA and AI compliance page. Where suggestions surface inside a certified EHR module, the transparency obligations attached to certified decision support are worth reading before configuration is fixed, on the ONC HTI-1 page.

Beyond compliance, four operational controls do most of the work. A named owner per automated step, not a committee. A monthly blind audit sample for any step that changes a code or releases a claim. A circuit breaker with a numeric threshold that suspends automation without needing a meeting. And a standing review of what the automation wrote off, deferred or closed, because failing deployments hide in the queue nobody reads.

The failure we see most often is none of these. It is that the automation worked and the organisation never redeployed the time. Hours returned to a revenue cycle team become either lower cost or more recovered revenue, and which one it is has to be decided in advance by someone with the authority to decide it. That conversation, and the sequencing that precedes it, is where an AI readiness audit starts.