AI Denial Triage and Appeal Drafts: A Setup Where Billers Approve Every One

Denials are the best first place for a billing company to use AI. You already have the data. The work is mostly sorting and drafting, which a biller can check in seconds. And it does not depend on payer portals that may block automation.

This post walks through a denial queue that sorts new denials by cause, dollars and deadline, drafts appeals for the common types, and leaves every decision with a biller.

Why denials, and why now

Practitioners already describe this pattern. In an r/CodingandBilling thread on AI in coding, replies describe AI analyzing denial reasons and drafting appeals with a human in the loop (Reddit, Aug 2026). HBMA's 2026 programming includes "From Denials to Dollars: How AI and Automation Are Driving Revenue Integrity Right Now" (April 1, 2026) and "Case Study: Uncovering Denial Trends Using Agentic AI" (March 2026) (HBMA Store, accessed Oct 2026).

There is also a regulatory reason. Under CMS rule CMS-0057-F, starting January 1, 2026, impacted payers (Medicare Advantage plans, Medicaid and CHIP fee-for-service and managed care, and plans on the federal exchanges) must give a specific reason when they deny a prior authorization. They must also decide within 72 hours for expedited requests and 7 calendar days for standard ones, with exchange plans excepted from the time limits. A Prior Authorization API is due by January 1, 2027 (CMS fact sheet, Jan 2024). That rule covers prior-authorization denials, not claim denials, but it means cleaner reason data for the prior-auth slice of your queue.

The five-step queue

Step 1: Intake

Each morning, the queue pulls what your billers would otherwise open by hand:

• remittance files and denial reports from the practice-management system or clearinghouse
• the open-claims list for each client practice
• your library of past appeals, especially the ones that won

No portal logins are needed for this step. If your systems export it, the queue can read it.

Step 2: Match and sort

Each denial is matched to its claim, then sorted by:

• reason: the claim adjustment reason code and any remark codes
• payer: because the same code means different fixes at different payers
• dollars: so a large surgical claim does not sit behind small office visits
• deadline: appeal windows differ by payer and plan type

The output is a ranked list. The biller's first question each morning changes from "what's in here?" to "do I agree with the top ten?"

Step 3: Draft

For the denial types you see most, the queue drafts an appeal letter. The drafts come from your own winning appeals, with patient details stripped out of the templates. Generic appeal language from a chatbot is easy to spot; your own past wording, adapted to the claim in front of it, is not.

Step 4: Checklist

Each draft carries a list of the records the appeal needs (operative note, authorization number, corrected claim form) and flags what is missing. Many appeals stall because a record was never requested, not because the argument was weak.

Step 5: Biller review

A biller approves, edits or rejects each draft and submits it personally. Nothing leaves the building on its own. The biller's edits feed back into the templates, so the drafts get closer to what your team actually sends.

What the AI must never do

Write these rules down before you build anything:

• Never change a code. It can flag a likely coding issue for a person to review. That is all.
• Never submit a claim or send an appeal. A biller does.
• Never run on a tool without a business associate agreement (BAA). Consumer chatbot plans do not qualify. See which AI tools can be used with patient data.
• Never see more than it needs. Each step should get the minimum data required for that step.

Where the queue lives

Put the ranked list where billers already work: a work queue in your billing system, a shared sheet, or a ticket board. A new app nobody opens is worse than no app. The underlying AI runs on a plan covered by a BAA, such as Claude Enterprise with its HIPAA setting turned on, or an API account under a signed BAA (Anthropic support, accessed Oct 2026).

How to know it works

Before you switch anything on, record two weeks of:

• minutes per denial worked (time a sample, do not guess)
• denials worked per biller per day
• denials that aged past their appeal window
• how long new denials wait before anyone touches them

Then run the queue on one client practice or one payer group and measure the same things. Overturn rates take longer to show, because appeals take weeks to resolve. Track them, but do not judge the queue on the first month.

More on setting the baseline is in Accounts per biller.

Where denial projects go wrong

• Messy reason data. If remark codes are missing or your exports truncate them, the sorter guesses. Fix the export first.
• No payer rules. The drafter only knows what you give it. Feed it your payer-specific notes, or it will write the same letter for every payer.
• Drafts that sound like a robot. Start from your winning appeals, not a blank prompt.
• Billers who do not trust it. In an r/EpicEMR thread asking billers about denial tools, one reports a poor experience with an AI vendor (Reddit, Sep 2026). Trust comes from billers testing every step during the build and seeing their own edits show up in later drafts.
• Starting too wide. One practice or one payer group first. Widen only after the numbers hold.

A note on what comes next

Once denials are sorted and drafted well, the same data supports a front-end check: before claims go out, flag ones that match denial patterns you have already seen for that payer. It suggests; a biller fixes. Status checks on unpaid claims are a separate decision, covered in Build, buy or partner.

If you want help scoping the first queue, Lunan offers a free conversation: we look at how denials move through your shop today and write down the best place to start.