ADOPT AI PARTNERS
Insights / healthcare

AI for Claims Handling in Healthcare: The Provider Side of the Revenue Cycle

12 September 2026  ·  8 minute read  ·  Adopt AI Partners
papers and a pen on a desk
Photo via Unsplash

A denial arrives weeks after the patient went home. The theatre slot is used, the supplies are consumed, and the cost is already on your books. Only the money is still in dispute, so all you can change is the paperwork and the argument attached to it.

The question is not how fast your billers work a denial queue. It is how many of those letters never arrive, and how much of the rest becomes cash before a clock closes. Both are rules and document problems before they are staffing problems, seen from the provider billing office rather than the payer assessing the claim.

Most denials are created before anyone treats the patient

Eligibility verification gets treated as a tick box because the answer comes back active, and active is the least useful part of the response. What decides whether the claim survives is the benefit detail for that service: whether the plan on file is still the plan, which payer is primary where more than one exists, whether you are in network at that site of service, and whether a referral must be held on file.

An agent can run that check off the schedule days ahead, and again nearer the date because coverage moves. The output is not a green tick but an exception list: what is wrong and who fixes it. Timestamp every response as received, because it becomes evidence later.

Prior authorisation is an assembly problem and a chase problem

The assembly half is document work with a clinical justification attached. An agent reads the order, the payer's published criteria for the service, and the chart for the evidence those criteria require: the diagnosis, the treatments already tried and their outcomes, the imaging. Where the chart lacks something the criteria demand, it says so before submission rather than letting the gap return as a denial.

The chase half is memory: a pending authorisation has a reference, a decision date and a status nobody owns. The join is what most teams miss: authorisation is granted for a specific procedure, unit count, date range and place of service, so a claim that differs is effectively unauthorised. Compare the two before submission, and leave peer to peer conversations with a clinician.

staff walking through a hospital hallway
Photo via Unsplash

Documentation, coding and the line a model may not cross

The code has to be supported by what the clinician recorded. An agent reading the signed note alongside the codes finds the ordinary mismatches: specificity the code lacks, a procedure documented and never billed, a diagnosis needed for medical necessity that never reached the claim.

Then the hard line. The agent may raise a query to the clinician, quoting the exact sentence that prompted it. It may not edit the record, add a diagnosis the note does not contain, or rewrite a clinician's words to fit a code. Never tune query generation on revenue either, or you have built an upcoding machine with an audit trail. Queries run both ways, including the ones that reduce the claim.

Claim scrubbing is the cheapest place to catch an error

An error caught before submission costs minutes. The same error caught after adjudication costs a full cycle, a rework touch and a slice of your appeal window. Those payer specific edits are mostly folklore.

This payer wants a particular modifier with that service, this one needs the referring clinician named, this one rejects two services on the same day, and that knowledge sits with two senior billers and a spreadsheet. An agent can hold the whole set and learn it from your own remittance history, so a denial you resolved by adding something becomes an edit that fires before submission next time. Hold the claim for a person rather than correcting it silently, and say which edit fired.

Denial triage by what you are going to do about it

The payer's reason code tells you what the payer says, which is not an operational classification. Billers need one of four answers: fix and resubmit, because the defect is yours; appeal with evidence, because the decision is wrong or the justification was never seen; bill the patient, because this is genuinely patient responsibility; or write off.

An agent can produce that classification from the reason code read with the claim, the remittance, the authorisation record and the eligibility response captured before the episode. The buckets need different people, and an undifferentiated queue guarantees appealable claims get the same handling as keying errors.

Write off authority

Stopping work on money is a decision with a named owner. The agent recommends and never approves. Set thresholds by value and reason, name the approver, record a reason on every write off, and watch the pattern: a sudden rise under one reason says something about a payer or about your front end.

reception desk in a healthcare building
Photo via Unsplash

Appeals are an evidence problem, not a writing problem

The letter is the smallest part. What decides an appeal is whether the right evidence is attached and whether you cited the right authority: the contract term, the payer's own published policy for the service, and the documentation that meets their stated criteria.

An agent assembles the pack: the claim as submitted, the remittance, chart extracts with page references, the authorisation, the eligibility response captured at the time, and the governing clause. It drafts the argument in your template, every assertion tied to an attached document, and a person signs. Argue against the reason actually given. The route differs by system: private payer ladders and timings come from the contract, while publicly funded routes are administrative and more uniform. The evidence assembly is the same.

The deadline clock and the queue that loses money quietly

Two clocks run whether or not anyone is watching: the filing deadline on the original submission, and the appeal window that starts from the remittance. Both expire in silence, and a claim resubmitted and denied again often has a clock that never restarted.

Most denial queues sort oldest first. That feels disciplined and loses money, because age is not risk: an old claim whose appeal window is open is safer than a fresh one closing this week. Sort by time remaining against that payer's window, then by recoverable value. An agent can hold those windows, compute remaining time from the correct start date rather than the day somebody noticed, and escalate what is expiring.

Underpayment is not denial

A paid claim looks settled. Some are paid wrong, and nobody disputes them because nobody compared the remittance against what the contract says should have been paid. The causes are mundane: a superseded fee schedule, a reduction the contract does not allow, lines bundled and paid at the lower rate.

The work is document reading followed by arithmetic. Extract the pricing terms with a citation, price each claim as it should have been priced, then compare line by line against the remittance. Keep the arithmetic in ordinary code rather than the model, because one wrong term fills the variance report with false positives. Read patterns: a variance repeating across a service line is a contract conversation, not an appeal.

Payer policy changes arrive as documents nobody reads

Policy changes reach you as documents: a bulletin, a revised medical policy, a new edit, a changed form. They land in a shared inbox and get read once the denials spike.

An agent can read each one on arrival and answer a single question: does this change anything we do. The output is a short change note to the owner of that workflow, and the agent proposes the rule change rather than deploying it. Pair that with the reverse signal, because you will still miss documents: a first pass denial rate by payer and reason that jumps without explanation means something changed whether or not you saw the paper.

Audit and clawback defence

When a payer requests records or proposes a recovery, the deliverable is a complete, dated evidence pack per claim: the order, the note as signed and by whom, the codes as submitted, the eligibility response captured at the time, the authorisation with its reference and dates, the claim as sent, the remittance, and every action since, timestamped and named.

Reviews go badly less often because the care was wrong than because the pack cannot be reconstructed later. It is a versioning and logging problem, designed in at the start rather than retrofitted under a deadline. The same standard applies to the agents: what they saw, what they proposed, who accepted it.

Where AI fails here

Source data defeats it first. An agent will build a confident authorisation request from a stale problem list, and scrub a claim cleanly against an eligibility response that was stale when captured.

Payer behaviour is not a fixed rule set. Published policy and actual adjudication diverge, undocumented edits exist, and the same reason code means different things to different payers. Treat the rules as stable and accuracy drifts quietly.

Interpretation is judgement. Whether a contract term permits a reduction, whether a service sits inside a bundled definition, whether the care was warranted: none is a reading task, and a model must never supply the justification itself.

Scale magnifies small errors, so quality assurance moves onto the agent's output rather than disappearing. And no agent repairs a broken process: automating a denial queue fed by unverified benefits works those denials faster.

Measuring it honestly, and where to start

Most reporting here measures activity: claims touched, tasks completed, letters generated. None of it correlates with money. Measure first pass acceptance, denial rate at first pass by payer and reason, net collection against the expected contractual amount, days in receivable, appeal overturn rate, underpayment recovered, write offs by reason, and touches per paid claim. Take the baseline first, because afterwards you cannot.

Start with pre submission scrubbing: fast feedback, cheap failure, a visible cash effect. Or denial classification, which improves the queue immediately and fails safely, because the biller sees a wrong classification at once. Do not start with appeals: highest judgement, slowest feedback.

Adopt AI Partners builds these systems inside your environment, on the platforms you already run. If your denial rate has a shape nobody can explain, or your appeal queue is aged rather than prioritised, describe the process to Adopt AI Partners and we will tell you plainly which parts an agent should carry and which it should not.

Tell us what your teams keep redoing

One conversation is enough to say whether there is a system worth building, and what would make it fail.

Describe your process