Denial Management Automation: A Workflow That Holds Up

Denial management automation that keeps control of appeals does four things: it captures every denial from remittances, routes each one by reason code to a named owner, ranks the work by dollars and deadline, and tracks every appeal to an outcome. People still decide what to appeal, what to argue and what to fix upstream.

Denial intake: reason codes and routing

Denial intake is the step that captures each denied or reduced claim line from a remittance and turns it into a work item. Automated intake reads the claim adjustment reason code (CARC) on each line, sorts it into a group, and sends it to the queue that owns that kind of problem.

Routing by code is what makes the rest of the workflow possible, and the codes come from a published list. The X12 Claim Adjustment Reason Codes list defines each reason code and the group codes that travel with them, such as CO for Contractual Obligation and PR for Patient Responsibility. Remark codes add detail: the X12 Remittance Advice Remark Codes list says RARCs "provide additional explanation for an adjustment already described by a Claim Adjustment Reason Code." What each code means in depth is covered in the EOBs and remittances category.

Denials arrive in two forms. Electronic remittances, the X12 835, carry the codes as data, so intake is a matter of reading the file. Paper EOBs carry the same codes printed on the page, and someone or something has to read them into fields first. Schema Care does that reading step for paper EOBs: it pulls service lines, payments and remark codes into fields and holds any it is unsure of for a reviewer, which you can see on a fictional EOB in the threshold demo. It does not route, appeal or resubmit claims.

An example routing table by reason-code group

This table is a fictional example of how one practice might route denials. The code summaries are paraphrased from the X12 list, so check exact wording there; the queues, owners and internal targets are illustrative choices, and commercial appeal deadlines come from each payer contract.

Two edge cases break simple routing. First, one line can carry several adjustments, such as a CO-45 contractual write-off plus a denial code, and only the denial code should drive routing; a contractual adjustment alone is normal processing, not a denial. Second, some codes will not appear in your table at all. Send unmatched codes to a catch-all queue owned by a senior biller, who either works the item or adds a routing row, so the table grows from real remittances instead of guesses.

Review the routing table itself every quarter. The X12 list page shows a start date for each code and, for many, a last-modified or stop date, so a code you route today may be retired or joined by a new one.

The Medicare figure has a source. The CMS page on the first level of appeal, redetermination by a Medicare contractor says a party has 120 days from the date of receipt of the initial determination to file, with receipt presumed 5 calendar days after the notice date unless there is evidence otherwise. For original claims, 42 CFR 424.44 on time limits for filing claims sets the Medicare limit at 1 calendar year after the date of service, with listed exceptions.

Denial work queues ranked by dollar value and deadline

Denial work queues should rank items by two things at once: how much money is at stake and how close the appeal or refiling deadline is. A queue sorted only by dollars lets small denials expire. A queue sorted only by date buries large denials behind trivial ones. A simple score that combines both keeps the order honest.

One workable approach is to compute days remaining for every item, from the deadline tracked in the routing table, and sort within bands:

1. Due within 14 days, highest dollar first.
2. Due within 15 to 45 days, highest dollar first.
3. Everything else, highest dollar first.

A fictional queue

Suppose the coding review queue holds three items, all invented for this example. A $1,240.00 denial for patient Rosa Delgado, claim 88310442, has 70 days left. A $185.00 denial for patient Tom Achebe, claim 88310517, has 9 days left. A $460.00 denial for patient Priya Natarajan, claim 88310603, has 30 days left. Banded sorting puts the $185.00 item first, because it expires soonest, then the $460.00 item, then the $1,240.00 item. Sorted by dollars alone, the $185.00 item would sit at the bottom until its window closed.

Three refinements help:

• Group by payer and code inside a band, so one person can work ten similar denials with the same fix in one sitting.
• Show the patient balance impact on each item, because some denials shift the amount to the patient and generate statements.
• Cap queue size per owner, and move overflow to a backup owner rather than letting items age.

How should an automated denial workflow track appeals?

An automated denial workflow should track each appeal as a record with a status, a deadline, a level and an outcome. Every status change gets a date and a person. The record stays open until the payer answers and the money posts, so nothing is lost between the letter going out and the decision coming back.

A minimal appeal record holds:

• Payer claim number, patient, date of service and denied amount.
• CARC and RARC codes from the original denial.
• Appeal level, such as first-level or second-level.
• Date filed, filing method and the deadline it was filed against.
• Expected decision date. For a Medicare redetermination, the CMS page says the contractor generally sends its decision within 60 days of receiving the request.
• Outcome: overturned, partly overturned, upheld or no response.
• Amount recovered, posted from the next remittance.

Statuses should be few and plain: to review, drafting, filed, awaiting decision, decided, closed. An appeal that sits in "awaiting decision" past its expected date should alert its owner to follow up with the payer.

The letter itself is a separate task with its own guide; the medical appeal letter sample covers what a letter should contain. The workflow's job is to make sure the letter goes out before the deadline and that the outcome comes back into the record.

Reporting comes from these records. Count appeals filed, overturn rate and dollars recovered by payer, by reason code and by queue. Those counts show where appeals pay off and where the better fix is upstream.

Which denial management steps should stay manual?

Denial management steps that need clinical judgment, payer conversations or a decision about whether to fight should stay manual. Software can sort, rank, remind and fill in forms. It should not decide that a medical necessity denial is wrong, argue a clinical point, or call a payer to negotiate.

Steps that stay with people:

• Deciding to appeal. Weighing the denied amount, the strength of the record and the cost of the appeal is a judgment.
• Clinical arguments. A medical necessity appeal under code 50 needs someone who can read the record and connect it to the payer's policy.
• Payer calls. Some denials resolve fastest by phone, and the notes from that call belong in the appeal record.
• Patient conversations. When a denial shifts the balance to the patient, a person explains it.
• Write-off approval. Deciding to stop pursuing a denial should need a named approver.

Authorization denials deserve particular attention. Under the CMS Interoperability and Prior Authorization final rule fact sheet, beginning in 2026 impacted payers must state a specific reason for each denied prior authorization decision, whether it arrives by portal, fax, email, mail or phone. That reason helps a rule pick the right queue, but choosing how to answer it still takes a person.

AI can draft parts of this work. Where models help and fail across billing is covered in the overview of AI in revenue cycle management.

Denial automation that hides the root cause

Denial automation hides the root cause when it fixes denials one at a time without asking why they keep happening. The most common version is auto-resubmission: a bot or rule resends every denied claim, sometimes with a small edit, and counts the eventual payments as success while the same error repeats on new claims.

Auto-resubmission causes three problems. It repeats the denial when nothing changed, which wastes a filing cycle and the deadline that comes with it. It can look like duplicate billing, which produces code 18 denials of its own. And it removes the signal: if, to take a made-up case, one registration error causes forty denials a month and a bot quietly fixes each one, nobody fixes registration.

Build the workflow so every denial feeds a count:

• Tag each closed denial with the step that caused it, such as registration, authorization, coding or charge entry.
• Review the counts monthly by payer and by step.
• Send repeated patterns to the team that owns the step, not to the denial queue.

Coding-caused denials, such as modifier and bundling conflicts, often trace back to automated coding defaults; the guide to medical coding automation explains how coding audits catch them. For the method of finding causes, see the guide to tracing each denial to the step that caused it.