Which Location Caused This Denial?

If you run a multi-location medical, dental, or specialty group, the question is usually not if denials exist. It is which location, step, or person created them.

Denial management software helps after the fact. It can sort denials, route appeals, and track follow-up. It usually cannot tell you that the North office forgot secondary eligibility on Tuesday evenings, or that one payer changed a policy version last month and only two sites kept missing it. That is because the software rarely has your scheduling, registration, and site-level workflow data joined to the remittance.

For a single-site practice, that gap may be tolerable. For a group with several locations, it is the whole problem. You do not just need a denial rate. You need denial attribution, which means knowing which operational step manufactured the denial, at which site, and under which policy.

What Denial Management Software Actually Does

At its core, denial management software supports three jobs. Only one of them is truly strategic.

The first two jobs are useful, but they do not tell you why the denial happened. The software may say a claim was denied for eligibility, but that is only a label. The operational cause might be a missed coverage recheck, a front-desk training gap, an inconsistent registration script, or a payer policy that changed before your team updated its workflow.

That distinction matters because the best next action is different in each case. If the problem is appeal handling, software helps. If the problem is upstream registration behavior, software only moves the work around.

Why Your Denial Rate Is Not a Number You Can Act On

Many owners look at one consolidated denial rate and assume it tells them whether the group is healthy. It often does not. Across several locations, the same group-level number can hide two very different realities, where everyone is slightly off or one or two sites are severely broken.

There is also a denominator problem. Different teams use different definitions of denial rate. One report may measure initial denial rate, which is the share of claims denied on first submission. Another may measure final denial rate, which looks after resubmission and appeals. A third may measure denial write-off rate, which is the portion that becomes lost revenue. Those are related, but they are not interchangeable.

Consider an illustrative example. Suppose a six-location group submits 10,000 claims in a month. Overall, 900 claims are denied on first pass, so the initial denial rate is 9%. That sounds like one system-wide issue. But if 600 of those denials came from two sites, each of those sites may be running at 18% while the other four sites are near 3%. A group memo would miss the real fix. A site-level scorecard would not.

That is why denial rate benchmark comparisons are often misleading. If your benchmark was calculated on a different definition, a different mix of specialties, or a single practice rather than several TINs and several workflows, you are not comparing like with like.

Where Denials Are Actually Manufactured

In ambulatory groups, denials usually start upstream of billing. Billing sees the failure late, but it rarely creates it. To find the source, map the operational steps that happen before a claim is sent.

Scheduling

The scheduling team chooses the appointment type, provider, and sometimes the expected payer path. If the wrong visit type or referral path is chosen, later edits may not catch the problem.

Registration and Demographics

This is where patient name, date of birth, coverage, subscriber data, and coordination-of-benefits details are captured. Errors here often show up weeks later as eligibility denials, but the person who entered the data may never see the outcome.

Eligibility and Benefit Verification

Eligibility verification checks if the plan is active and what it covers. A plan can be active and still deny a service because the benefit is limited, prior authorization is missing, or secondary coverage was not re-verified. These are common preventable denials.

Referral and Authorization Capture

Some payers require a referral or prior authorization before the visit. If the authorization number is missing, expired, or attached to the wrong service line, the claim may deny even when the care was appropriate.

Provider Credentialing and Payer Enrollment

If a provider was not credentialed with the payer on the date of service, or the enrollment record is incomplete, the denial may look like a billing issue even though the cause was a credentialing gap.

Coding and Charge Entry

Here the claim can be denied for code mismatches, modifiers, or documentation problems. These denials are easier to blame on billing, but even here the root cause may be upstream documentation or workflow design.

Timely Filing and Follow-Up

Late submission is often the final failure mode, not the original one. When claims sit in a workqueue too long, the root cause may be a process backlog, not a payer issue.

The important point is the feedback loop. The person who created the mistake may be long past the shift by the time the denial appears. By then, a blanket memo does little. You need a join between the denial and the upstream event that created it.

For related reading, see what a payer actually pays and how to improve patient collections.

From Reason Code to Responsible Step

The 835 electronic remittance advice tells you that a claim was denied and gives you a CARC and RARC pair. CARC means Claim Adjustment Reason Code. RARC means Remittance Advice Remark Code. Those codes are useful, but they are not root cause analysis.

A CARC/RARC pair tells you something like “eligibility” or “authorization missing.” It does not tell you who entered the wrong data, at which location, using which workflow, during which policy version, for which appointment. That missing link is the attribution layer.

To build it, you need to join denial events back to operational data that your billing software may not currently connect:

• Appointment ID
• Registration session or encounter ID
• User who performed the action
• Location or site
• Provider and specialty
• Payer plan and product
• Policy version or rule set in force on the date of service
• Claim submission timestamp and denial timestamp

Once those joins exist, you can move from “eligibility denials are up” to “the Tuesday evening registration team at two sites is not re-verifying secondary coverage for Medicare Advantage patients.” That is actionable. It points to a process change, a training fix, or a system rule.

Good attribution also forces a useful classification, preventable or not preventable. A preventable denial is one your own workflow could reasonably have avoided. A non-preventable denial is driven by a payer rule, a coverage change you could not have seen, or a clinical issue outside your control. If your definition is vague, every denial becomes someone else’s fault or nobody’s fault.

What to Buy and What to Build

This is where many groups overspend. They buy appeal automation and expect it to solve prevention. It will not.

The practical split is simple. Buy the recovery work, build the attribution work.

Buy when the work is standardized across payers and does not depend on your organization’s unique structure. Generate the appeal packet. Auto-fill the form. Track the deadline. Those are commodity tasks.

Build when the answer depends on your own entity structure, user behavior, and event data. A software vendor may show denial trends by payer and reason code. That is useful, but it is not enough to explain why one location is underperforming while another is fine.

There are also cases where you should not build much at all. If you have one site, a small provider base, one practice-management system, and a denial rate that is already inside a sensible benchmark for your specialty, the better move may be process cleanup and a better denial work queue. The cost of a custom attribution layer may exceed the savings. For groups with several locations, our healthcare software development work covers this kind of cross-site data model.

How to Size the Prize Before You Spend Money

You do not need a year-long transformation project to estimate if attribution is worth it. Start with one month of remits and one month of upstream workflow data.

Use this sequence:

• Pull all denials from the 835 remittance files for the month.
• Group them by CARC/RARC, payer, location, provider, and date of service.
• Manually assign each denial to an upstream step such as scheduling, registration, eligibility, referral, authorization, credentialing, coding, charge entry, or timely filing.
• Mark each denial as preventable or non-preventable using a written rule.
• Multiply preventable denials by average allowed amount, not billed amount.

That gives you an estimate of preventable-denial dollars. It is not perfect, but it is enough to decide if the problem is big enough to justify a data model, a process change, or a software purchase.

If the same step is driving most of the loss across multiple sites, the fix is usually operational. If the same payer or policy is driving most of it, appeal automation and policy tracking may help. If you cannot tell which site or step is responsible because the data is disconnected, then the first software problem is not denial management. It is attribution.

What to Do Next With Your Denial Data

If your current denial management software can show you payer trends but not site-level attribution, that is not enough to fix a multi-location problem. Ask for the joins, not just the dashboard, meaning appointment, registration, user, site, payer and policy version. Then ask if the result can distinguish preventable denials from payer-driven ones.

That is the decision point. If the answer is yes, you may only need a better configuration or a reporting layer. If the answer is no, no amount of appeal automation will tell you why one location is manufacturing denials while the others are not.

This is the kind of problem where the hard part is not the dashboard. It is the data model, because the scheduling and registration events that explain denials were never designed to be joined to remits across multiple entities. Better Software has done multi-location healthcare workflow and practice-system integration work of that shape, including with Apex Dental Partners. It is the same class of problem, connecting operational events across sites so leaders can see what is actually happening.

Frequently Asked Questions

What Is Denial Management?

We describe it as identifying denied claims, correcting them, appealing when appropriate and preventing repeats. In practice it covers both recovery and prevention, and the recovery half is the commodity work that software handles well.

What Is RCM Denial Management?

We mean denial work inside the broader revenue cycle management process. RCM stands for revenue cycle management, and denial management there runs from claim submission through follow-up and appeal, so it is the same discipline viewed from the whole revenue cycle.

What Is a Denial Root Cause Analysis?

We use it to name the upstream operational step that caused a denial, not just the reason code on the remittance. A CARC and RARC pair says what the payer reported. Root cause analysis adds who, where, which workflow and which policy version.

What Is the Difference Between Soft and Hard Denials?

We treat a soft denial as often temporary or correctable, such as missing information or a claim held for review. A hard denial is generally final or much harder to overturn. The exact usage varies by payer and system, so we verify the definition in each workflow.

Which Software Is Used in Medical Billing?

We usually see a practice-management system or EHR, a clearinghouse and sometimes a separate denial management tool. The first two submit and move claims, and the third helps recover them. None of them knows which front-desk action caused a denial unless the data is connected.