Denial Reporting by Payer
A denial report is the analytical view of the denials a practice is receiving — how they are behaving as a book, not which one to work next. Cutting that view by payer is the most useful single design choice, because the payer is the one thing about a denial the practice did not decide and cannot correct upstream the way it can fix its own registration or coding: a payer sets its own policies, runs its own edits, and changes both when it chooses. Reporting denials by payer makes that behavior visible — which payer is denying more of what, whether a payer's pattern is moving, and whether appealing that payer is worth the effort — so the report becomes a management instrument rather than a scoreboard. It is a different artifact from the worklist, built from the same data, and it is worth designing deliberately rather than accepting whatever a system prints by default.
Updated 14 min read
On this page
Key takeaways
- A denial report answers how the denials are behaving; a worklist answers what to work next. They draw on the same data and are different artifacts, and keeping them separate is a deliberate design decision, not an accident of tooling.
- Payer is the most useful primary cut, because payer behavior is the denial driver a practice cannot fix upstream. Comparing a practice's own payers to each other, and each payer to its own past, is the honest comparison — not against an industry number.
- A count is not a rate. A raw denial count rewards volume: the payer you send the most claims denies the most claims. Every headline figure needs a denominator over the same period and the same population.
- Pick the unit and hold it. Denials counted by claim, by service line, and by dollar tell different stories; a report that mixes them cannot be read. State the unit and keep it consistent across payers and across time.
- Segment inside the payer. Within a payer, the reason mix, the provider or service line, and the trend say where the pattern is coming from — and hand off to prevention, to contracting, or to an appeal decision.
- The report drives the worklist; it does not replace it. A payer pattern tells a team where to push, but sequencing the individual denials is a separate step, and the report must not double as the task list that reorders as work is done.
What a denial report is, and what it is not
A denial report is the aggregated, retrospective view of the denials a practice has received over a period — grouped, counted, and measured so that a pattern can be seen. Its question is analytical: how is the denial book behaving? That is a different question from the one a worklist answers, which is operational: of the open denials right now, which is worked next. The two are built from the same underlying events, but they are not the same artifact, and confusing them is the most common reason a denial report is never trusted.
The distinction is not specific to denials. Keeping the actionable queue separate from the analytical view — so that reordering the work never distorts the trend, and the trend never quietly becomes a task list — is the general discipline of separating work queues from reporting views. A denial report is one instance of the reporting side of that split. Its job is to describe, so it is aggregated rather than itemized, it is stable across a period rather than changing as items are worked, and it is read to decide where to direct effort — not to hand a person the next task. Deciding the order the individual denials are then worked in is prioritizing denial work, and it belongs to the worklist, not the report.
A report describes; a worklist directs
Why payer is the cut that matters most
Denials can be grouped by many things — reason, provider, service line, location, the month they posted. Each is a useful lens. But payer is the one worth making the primary cut, and the reason is structural: the payer is the only major driver of a denial that the practice neither chose nor can correct at the source. A registration error is fixable at the front desk; a coding error is fixable in coding; a clean claim that still denies did so because of something the payer decided. Each payer sets its own coverage policies, runs its own claim edits, and interprets its own contract — and it can change any of them without notice. Grouping by payer is what makes that external, moving behavior visible as behavior rather than as scattered noise across the queue. The choice is not only an internal convenience: federal transparency rules require marketplace health plans to report the number of claims they deny, and the Centers for Medicare & Medicaid Services publishes that data at the issuer level — an official recognition that the payer is a meaningful unit of denial analysis.
That framing also fixes the comparison problem. There is a strong temptation to ask whether a payer's denial rate is "high," which invites a published industry average as the yardstick — and this site does not publish one, because a denial mix is specific to a practice's specialty, payers, and process, so a general figure is not the practice's number and cannot say what to do. The honest comparisons are internal: one of the practice's payers against another under the same process, and each payer against its own past. Both are comparisons the practice's own data can actually support, and both point at an action; a comparison against a stranger's average does neither.
The benchmark trap
What the report carries: dimensions and measures
A denial report has two kinds of content: dimensions, which are the axes it is sliced along, and measures, which are the quantities shown in each slice. Payer is the primary dimension; the others nest inside it. The measures are where design discipline matters most, because a measure stated without a base misleads more than it informs — the next section is entirely about that. The raw material for all of it is the structured data the payer already returns: on the remittance advice, every adjusted line carries a claim adjustment group code and a CARC — X12 maintains those codes and states that the group code (CO, PR, OA, PI) generally assigns responsibility for the amount, and how to read them is reading a denial. A denial report is those codes aggregated up from the line to the payer.
| The measure | The question it answers | How to build it honestly |
|---|---|---|
| Denial rate, by payer | What share of this payer's claims came back denied over the period? | A ratio, never a raw count — denials over the claims or lines that payer adjudicated in the same period. Its definition lives on the denial rate metric page; the report applies it per payer. |
| Denied dollars, and where they went | Of the amount denied by this payer, how much was recovered, how much is still open, and how much was written off? | Separate the recovered, the open, and the written-off amounts — a denied-dollars total that hides the disposition overstates the loss and the opportunity alike. Keep a contractual adjustment out of it: that is not a denial. |
| Overturn rate on appeal, by payer | When this payer's denials are appealed, how often does it reverse? | The share of appealed denials the payer overturned. It tells whether appealing this payer pays off, and it is a summary of many individual appeal decisions, not a substitute for making them. |
| Reason mix, within the payer | What is this payer denying for — and is it a front-end, clinical, or avoidable cause? | Roll the codes up to the recurring categories in why claims get denied rather than listing every code, so the mix names a cause with an owner rather than a code with none. |
| Aging of open denials, by payer | How long have this payer's unresolved denials been sitting, relative to the windows to act on them? | Age is only meaningful against the deadline it is running toward — a filing or appeal window that runs from the payer's decision. Report it as time left, not time elapsed, so it drives the worklist rather than just describing a backlog. |
Every measure here is reported per payer and, where it helps, trended over time. None of them is compared to an external benchmark, because none has an honest one.
Below the payer, three sub-dimensions do most of the diagnostic work: the reason category (what the payer is denying for), the provider or service line (whose work, or which service, the denials cluster on), and time (whether the pattern is steady, seasonal, or newly moving). A single denial report rarely needs more than payer, one of these, and a trend — a report that adds every possible axis at once stops being readable, which is its own kind of failure.
The one rule that makes the report honest: a count is not a rate
The single most common way a denial report misleads is by showing raw counts and inviting them to be read as severity. A count of denials rewards volume: the payer a practice sends the most claims to will, all else equal, produce the most denials, and will sit at the top of a count-ranked report while doing nothing unusual at all. Ranking payers by denial count answers "which payer do we send the most work to," not "which payer is denying an unusual share of it" — and only the second question points at an action.
The fix is a denominator. Every headline figure on the report should be a ratio against the population it came from over the same period — denials against the claims or lines that payer adjudicated, denied dollars against billed or expected dollars, overturns against appeals filed. A rate lets a small payer with a genuine problem rise above a large payer behaving normally, which is exactly the signal the report exists to surface.
This is not a house convention. The standardized definitions of these measures are built the same way: an industry denial rate is expressed as the number or gross charges of claims denied over the claims submitted in the same period — a ratio, not a count — and the same standards define a companion measure for the share of appealed denials a payer overturns, both intended to be trended over time rather than read once. Those standards also state plainly that the reason the overturn measure is worth tracking is to surface potential issues with specific plans and specific types of denials, which is exactly the payer-and-reason segmentation this report is designed around.
Pick the unit and hold it
Two more design choices decide whether the report can be read. A snapshot answers what the book looks like today; a trend answers whether it is getting better or worse — and a denial report almost always needs the trend, because a single period's rate means little without the direction of travel beside it. And the period has to be settled: denials arrive and resolve on a lag, so a report run over a window still filling up will understate both the denials and the recoveries, and reads worse or better than the truth purely because of when it was run.
Reading a payer pattern into an action
A denial report is only worth building if a pattern on it changes what someone does. Because the report is cut by payer, the patterns it surfaces route to a small number of destinations, and knowing which is which is the skill the report is for.
A reason category rising at one payer → prevention or a payer inquiry
If one payer's denials concentrate in a front-end or avoidable category, the destination is usually upstream — the controls in preventing denials — unless the category jumped suddenly for that payer alone, which points instead at a payer-side change (a policy update, an edit flip, an enrollment gap) worth confirming with the payer rather than absorbing as rework.A high overturn rate at a payer → its denials are worth appealing
A payer that reverses a large share of what is appealed is telling the practice its denials are frequently wrong; that is a signal to appeal that payer's denials rather than write them off. A payer that rarely overturns calls for the opposite read — put the effort into preventing and correcting rather than contesting. Either way the report informs the appeal decision; it does not make it.A structural pattern across many payers → a process or contracting question
When the same category is elevated across most payers, the cause is more likely internal than payer-specific, and the report has just found a process problem. When a single payer's overall rate drifts up over several settled periods with no internal cause, that is a payer-relationship or contract matter, escalated with the report as the evidence.
In every case the report ends by handing off, and the most important hand-off is back to the worklist. The report says where the recoverable volume and the winnable payers are; sequencing the individual denials inside that — by deadline first, then expected recovery — is prioritizing denial work, a separate step on a separate artifact. Keeping the two apart is the discipline this page opened with: the report is read to decide where to push, and the worklist is worked to actually recover the money. The rest of the cluster is indexed on the Denials & Appeals pillar.
Common questions
What is a denial report, and how is it different from a denials worklist?
A denial report is the analytical, aggregated view of the denials a practice has received — it answers how the denial book is behaving over a period. A worklist is the operational queue of open denials that answers which one to work next. They are built from the same underlying data but serve different purposes: the report describes and is read to decide where to direct effort, while the worklist directs and is worked item by item. Keeping them separate is deliberate, because a view used to reorder work cannot also hold a stable picture of the trend.
Why report denials by payer rather than by reason?
Both are useful, but payer is the better primary cut because payer behavior is the one denial driver a practice cannot fix at its own source — a payer sets its own policies and edits and can change them at any time. Grouping by payer makes that external behavior visible as a pattern. Reason then nests inside the payer as a sub-dimension: within a payer's slice, the reason mix names what it is denying for. Reason mix on its own is covered in Why Claims Get Denied; this page adds the payer axis and treats the report as the artifact.
Should a payer's denial rate be compared to an industry benchmark?
No, and this site publishes no such benchmark. A denial mix is specific to a practice's specialty, payers, and process, so a general average is not the practice's number and cannot tell it what to do. The honest comparisons are internal: one payer against another under the same process, and each payer against its own past. Both are supportable from the practice's own data and both point at an action, whereas a comparison to an unverifiable average points at nothing.
Why does a denial report need a denominator?
Because a raw count of denials rewards volume rather than revealing a problem. The payer a practice sends the most claims to will produce the most denials simply by scale, and will top a count-ranked report while behaving completely normally. Expressing each figure as a ratio — denials over the claims that payer adjudicated, overturns over appeals filed — lets a small payer with a real problem rise above a large payer behaving normally, which is the signal the report exists to find.
Should denials be counted by claim, by line, or by dollar?
Any of the three, but consistently. A claim with one denied line out of five counts as a whole denial by claim, a fifth of one by line, and its dollar amount by value — three different pictures of the same event. Each answers a different question, and none is wrong, but a report that mixes units between payers or across months cannot be compared to itself. State the unit, hold it constant, and introduce a second unit only as an explicit second view.
Key terms in this article
Defined once, on their own pages.
Continue learning
Where to go next.
Prioritizing Denial Work
The operational counterpart to this report — how the workable denials are sequenced into a work order once the report says where to push.
Why Claims Get Denied
The recurring reason categories the report's reason mix rolls up to — and how to read them as a map of your own process.
Reading a Denial
The group codes, CARCs, and RARCs on the remittance — the structured, per-line data a denial report is aggregated from.
Separating Work Queues from Reporting Views
The general discipline behind keeping the denial report and the denials worklist as two distinct artifacts.
Denial rate calculator
Calculate the denial rate that anchors the report, per payer, from your own claim figures.
Authoritative sources
- X12 — Claim Adjustment Reason Codes and Group Codes (opens in a new tab)
Maintains the national code sets used on the remittance advice. States that Claim Adjustment Reason Codes describe why a claim or service line was paid differently than billed, and that the group codes (CO, PR, OA, PI) generally assign responsibility for the adjustment amounts — the structured, per-line data a denial report is aggregated from.
- Standardizing Denial Metrics for Revenue Cycle Benchmarking and Process Improvement (opens in a new tab)
Healthcare Financial Management Association (HFMA), Claim Integrity Task Force. Defines a standard denial rate as a ratio of denied claims or charges to claims submitted, and a companion measure for the share of appealed denials overturned, both intended to be trended — and frames the overturn measure as a way to surface issues with specific plans or types of denials. The authority behind the denominator and payer-segmentation discipline used here.
- Transparency in coverage — 45 CFR 156.220 (opens in a new tab)
Electronic Code of Federal Regulations. Requires qualified health plan issuers to report data on the number of claims that are denied and to make it public; the Centers for Medicare & Medicaid Services publishes that data at the issuer level pursuant to Section 1311(e)(3) of the Affordable Care Act — the federal recognition that the payer is a first-class unit of denial analysis.