AI in revenue cycle management does three jobs today: it reads documents into fields, it scores claims for denial risk before they go out, and it drafts text such as appeal letters and code suggestions. It fails on payer rules it has not seen and on messy pages, so a person still checks its output before money moves.
Where AI in revenue cycle management is already in use
AI in revenue cycle management means software that learns patterns from past data or text instead of following only hand-written rules. The revenue cycle is the chain from scheduling and registration through coding, claim submission, payment posting, denials and patient balances. AI shows up at the steps where a person reads, judges or writes.
The steps where models are commonly applied fall into a short list:
- Document reading. Pulling fields from EOBs, paper claims, intake forms and statements so staff do not retype them.
- Eligibility and registration checks. Flagging insurance details that look incomplete or mismatched before a visit.
- Coding help. Suggesting procedure and diagnosis codes from a clinical note for a coder to accept or change.
- Claim scrubbing and denial risk. Scoring a claim before submission and pointing at the field most likely to cause a denial.
- Denial and appeal work. Sorting incoming denials, summarizing a case and drafting an appeal letter.
- Patient balance work. Predicting which balances need a payment plan or a reminder.
Each use takes a specific input and returns a specific output, and each fails in its own way. The table below sets them side by side with the check a person should apply.
| AI use | Input | Output | Typical failure | Human check |
|---|---|---|---|---|
| Document extraction | Scanned EOB, claim or statement | Named fields with confidence | Misread digit in an amount or code | Reviewer confirms low-confidence fields on the page |
| Eligibility flagging | Registration data, payer response | Mismatch warnings | Flags a valid plan as inactive | Front desk verifies with the payer |
| Coding suggestion | Clinical note | Draft CPT and ICD-10-CM codes | Codes an uncertain diagnosis as confirmed | Certified coder accepts or edits each code |
| Denial prediction | Claim fields, past outcomes | Risk score and reason | Misses a new payer policy | Biller reviews high-risk claims before submission |
| Denial sorting | Remittance reason codes | Queue assignment | Wrong queue for a rare code | Queue owner reassigns and reports it |
| Appeal drafting | Denial, claim, record excerpts | Draft letter | States facts not in the record | Staff check every fact against the chart |
| Balance outreach | Account history | Outreach priority | Treats a disputed bill as unpaid | Staff check open disputes first |
The paper-reading row is often the least glamorous and the most direct to measure, because each field is either right or wrong against the page. The guide to medical billing OCR walks one EOB service line through that process. For the claim side, including how payers use automated adjudication, see the post on artificial intelligence claims processing.
Bots that click through payer portals are a different technology, often sold alongside AI. The comparison of RPA bots versus AI extraction in medical billing explains where each one belongs.
Machine learning models for revenue cycle denial prediction
Machine learning models for revenue cycle denial prediction learn from a practice's past claims and their outcomes. Given a new claim, the model compares its fields with claims that were paid or denied before and returns a risk score, often with the field or rule that drove the score, so a biller can fix the claim before it goes out.
The training data is the remittance history. Every denied line carries a group code and a reason code from the X12 Claim Adjustment Reason Codes list; the categories those codes fall into are set out in the most common claim denial reasons. A model learns, for example, that a given payer often returns code 197, "Precertification/authorization/notification/pre-treatment absent," for a certain procedure when no authorization number is on the claim.
The output is only as good as the history behind it. A model trained on two years of claims knows the payer rules of those two years. It cannot know that a payer added an authorization requirement last month until denials under the new rule start to arrive. That gap is why a prediction is a flag, not a decision.
A useful denial model explains itself. A bare score of 0.82 tells a biller nothing. A score with a reason, such as "authorization number missing for this payer and procedure," tells them what to fix. Ask any tool for the reason behind each score and test it against a sample of your own past denials.
A fictional example of a flagged claim
Suppose a claim for a fictional patient, Marcus Bell, member ID QRT220981 (both invented), lists an imaging procedure for a payer that, in this practice's history, denied the same procedure without authorization in most cases. The model scores the claim high and names the missing authorization field. A biller checks the payer's current authorization list, finds the authorization in the scheduling notes, adds it and sends the claim. The model did not decide anything. It pointed a person at one field.
Generative AI in the revenue cycle: letters, summaries and coding help
Generative AI in the revenue cycle means large language models that write text: draft appeal letters, summaries of long records for a reviewer, plain-language explanations of a bill and suggested codes from a clinical note. They save writing time, but they produce fluent text whether or not it is true, so every factual claim needs checking.
Appeal letters are the most common use. A model takes the denial reason, the claim and excerpts from the record and drafts a letter that argues the case. The draft is a starting point. A model can cite a page of the record that does not say what the letter claims, or describe a policy the payer never published.
Record summaries help a reviewer find the relevant pages in a long chart before writing an appeal or answering a records request. The risk is omission: a summary that leaves out the one note that supports medical necessity can lead the reviewer to drop a winnable appeal.
Coding help is the use with the strictest rules, and a language model that has learned general medical language does not automatically follow the official coding guidelines. How much coding software can do safely, and which encounters need a certified coder, is covered in the guide to encounters medical coding automation can handle.
Where does AI in revenue cycle management fail?
AI in revenue cycle management fails in predictable places: payer rules that changed after the model learned them, documents it was not trained on, rare codes and cases, and any task where a fluent answer can hide a wrong fact. The failures are rarely random. They cluster where the real world moved and the model did not.
Payer rule drift. Payers change authorization lists, edits and coverage policies. A denial model built on last year's outcomes misses this year's rule. Some rule changes are public: the CMS Interoperability and Prior Authorization final rule fact sheet says affected payers must give a specific reason when they deny a prior authorization starting in 2026, and must build a Prior Authorization API by compliance dates that generally begin January 1, 2027. Workflows that depend on how denials arrive will shift as those rules take effect.
Unfamiliar documents. An extraction model that has seen many EOB layouts can still stumble on a new payer's format, a faxed copy with streaks, or a handwritten correction. The safe behavior is a low confidence score, not a confident wrong value.
Coding rules and code-pair edits. Coding models stumble on rules that run against intuition, such as uncertain diagnoses that are coded differently in outpatient and inpatient settings, and on code combinations that federal edits forbid. Each of these cases is laid out in the guide to which coding cases need a certified coder.
Invented facts. A generated appeal letter or summary can state something that is not in the record. Nothing in the text marks it as invented.
Feedback loops. A model trained on its own past decisions can harden its mistakes. If a denial model's flags caused billers to hold back certain claims, the history now has fewer of those claims, and the next version learns from a skewed sample. Keep a record of what the model flagged and what people did, so retraining can tell the two apart.
How much human checking does revenue cycle AI need?
Revenue cycle AI needs a human check wherever its output changes money, a code or a statement sent outside the practice. The amount of checking should scale with the risk of the step and the confidence of the output: high-confidence, low-risk fields can pass, and everything else waits for a person with the source in front of them.
Three rules help set the level:
- Check by field, not by batch. Review the specific values the model was unsure about, shown on the original page or note, instead of re-reading whole documents.
- Never let generated text leave unread. Appeal letters, patient messages and code sets get a named person's approval before they go out.
- Log every decision. Record who approved or changed each value and when, so an auditor or a payer question can be answered from the record.
Measure the checking as well as the model. Track how often reviewers change a model's output, by document type and field. A field that reviewers correct often needs a stricter threshold. A field they never change may be safe to pass more often. This is the ground covered in the human review category, which explains thresholds and review queues in more depth.
Schema Care applies this approach to document extraction only: it reads EOBs, claims, statements and other paperwork into fields, gives each one a confidence score, and sends anything under the threshold your team chooses to a reviewer, as shown on the list of documents Schema Care reads. It does not predict denials, assign codes or submit claims.