Provider Credentialing: The Enrollment Error That Underpays Every Claim

Most organizations treat credentialing as a gate. Is this provider approved with this payer, yes or no. Once the answer is yes, the file closes and attention moves on.

The gate framing is not wrong. It is just half the job. Enrollment also sets what you get paid, because it is when the payer loads your provider into their system alongside the fee schedule that will apply to every claim you submit under that enrollment.

And that second function usually has no owner. Credentialing sits with a credentialing specialist or a medical staff office, measured on turnaround time and approval status. Nobody in that workflow is measured on whether the rates that came with the approval are the right ones.

I train practice staff on this and it is consistently the part that surprises people, because the failure it produces does not look like a credentialing failure at all. If you want the wider picture first, how to improve revenue cycle management covers it, and the 13 steps of the revenue cycle is the plainer orientation.

Three Ways Enrollment Fails, and Only Two of Them Are Obvious

Worth separating, because organizations invest almost entirely in preventing the first two.

1. Not enrolled, or deactivated. You cannot bill. Claims reject immediately and everybody knows within a week. Painful, but self-announcing.
2. Enrolled late. Billing privileges arrive after the provider starts seeing patients. An error restarts the submission cycle, and every day of that delay is either unbillable or dependent on retroactive rules.
3. Enrolled wrong. The provider is approved. Claims submit. Claims pay. And the rate they pay at is not the rate the contract says, because something in the enrollment record is incorrect.
4. Only the third is invisible. The first two announce themselves through rejected claims and idle clinicians. The third produces a functioning revenue cycle that is quietly short, and it stays that way until somebody goes looking for a reason to look.

How the Wrong Rate Gets Loaded

The mechanism is mundane, which is part of why it survives.

When a contract is signed or renewed, the payer loads the negotiated rates into their adjudication system against your provider records. For Medicare, the reference schedule is public, in the Physician Fee Schedule, which makes a mismatch checkable. For commercial contracts, the negotiated rates exist only in your agreement, which makes it checkable only by you. That load is a data-entry operation performed by someone at the payer, working from documents, under volume.

Things that go wrong there:

1. A mistyped effective date. New rates get applied to the wrong service period, so a batch of claims adjudicates against the previous schedule. This one is common enough to be worth checking for specifically.
2. The provider record and the contract not linked. A newly enrolled provider is attached to a default or group schedule rather than the negotiated one.
3. A partial load. Some codes update and others do not, which produces a fee schedule that is right in most places and wrong in a few, and that is considerably harder to spot than one that is wrong throughout.
4. A group-versus-individual mismatch. The provider is enrolled individually when claims are billed under a group, or the reverse.

None of these produce an error on your side. The claim goes out, the payer adjudicates against whatever they have, and a remittance comes back. Everything works. It just works at the wrong number.

The Check You Can Run This Week

There is one diagnostic that costs almost nothing and finds this class of problem directly.

Take a claim with a date of service after a new contract’s effective date. Look at the allowed amount. If it matches what the same code allowed under the previous schedule, the new rates are almost certainly not loaded.

That is it. One comparison, per payer, after every contract change.

It works because the failure is systematic rather than random. If the rate is wrong it is wrong the same way on every affected claim, which means a sample of one or two per payer per code family is usually enough to detect it. You are not auditing; you are checking whether a load happened.

The reason so few organizations run it is a sequencing problem rather than a difficulty problem. The contract effective date is known by the people who negotiated it, and the claims come back weeks later to a different team who were not told a rate changed. Nothing in the standard workflow connects a contract event to a claims check.

Making that connection is a calendar entry, not a project: when a contract’s effective date passes, somebody checks a claim.

Deactivation, and the Revenue That Does Not Come Back

One consequence severe enough to state on its own.

Enrollment is not permanent. Records lapse through revalidation deadlines, address or ownership changes not reported in time, or administrative deactivation. Reactivation does not automatically make work billed during a lapse recoverable, so the exposure is worth confirming against current CMS enrollment guidance for your own situation.

That is different from late enrollment, where retroactive billing rules may allow some recovery. Deactivation creates a window where the work was done, the patient was seen, and the revenue is simply gone.

There is a live regulatory change here worth tracking, and it is important to be precise about what is settled and what is not.

Already the case: some Medicare enrollment revocations take effect retroactively, back to the date the provider’s noncompliance began, rather than prospectively from the notice date. Where that applies, revenue already received for services billed after that date is exposed.

Proposed, not final: in the CY2027 Home Health Prospective Payment System proposed rule, CMS-1844-P, CMS proposes to make all revocation grounds retroactive, alongside several new and expanded bases for revocation or denial. The enrollment provisions are written for providers and suppliers generally rather than home health alone, which is easy to miss given the rule they are travelling in.

The comment period closes August 31, 2026, the same date as the outpatient rule covered in our CMS-1850-P analysis. If your organization intends to comment on either, it is one deadline, not two.

Two things follow. Read it from CMS rather than from a summary, because the distinction between what is already in force and what is merely proposed is exactly the part secondary coverage collapses. And treat enrollment accuracy as a financial control rather than an administrative one, because the exposure is no longer bounded by the date somebody notices.

The pattern is the same: revalidation dates deserve the same treatment as any other hard deadline in the revenue cycle, which is the argument made about filing limits in days in AR and timely filing. A date that is absolute and unforgiving needs a calendar and an owner, not a folder.

What Happens When You Find One

The check tells you a rate is wrong. It does not tell you what to do next, and the next part is where most of the value sits, because a wrong rate that has been running for two years has already cost far more than it will cost this month.

Correction and recovery are separate conversations, and they move at different speeds.

Correction is usually straightforward once you have evidence. You are not disputing a clinical decision or a coding judgment; you are pointing out that the rate in the payer’s system does not match a document you both signed. That is a factual disagreement with a documentary answer, which makes it one of the easier conversations to have with a payer. Bring the contract, the effective date, and a claim example showing the allowed amount.

Recovery is where it gets slower, and the practical questions are how far back the payer will reprocess, and whether they will do it themselves or require you to resubmit.

Four things determine how that goes:

1. Whether the error was theirs. A load error on the payer’s side is a stronger position than an enrollment form your team completed incorrectly.
2. How far back it runs, against timely filing. This is where the two halves of this cluster collide. A systematic underpayment stretching back years may include claims now outside the filing window, and those may not be recoverable even when the error is undisputed. The timely filing analysis covers why that deadline is the one with no appeal.
3. Whether you can produce the claim-level detail. “You have been underpaying us” is a position. A list of affected claims with expected against allowed for each is a case, and producing it requires the contract model described in payer contract management.
4. Volume. Reprocessing thousands of claims is operationally significant for the payer too, and that reality shapes what gets agreed.

The uncomfortable arithmetic: the sooner you find it, the more of it you can recover, and the detection cost is roughly constant regardless of when you run it. A check that takes an hour is worth more the earlier it happens, which is the argument for tying it to a contract event rather than to an annual review.

Why This Belongs to the Revenue Cycle, Not Just to Medical Staff

Credentialing usually reports somewhere other than revenue cycle, and the split is where the problem lives.

The credentialing function is measured on approvals and turnaround. Nobody in it is measured on whether the rate attached to the approval is correct, because rate accuracy is a revenue cycle concern and revenue cycle was not in the room when the enrollment was completed.

So the organization has a team accountable for getting providers enrolled, a team accountable for collecting correctly, and no one accountable for the join between them, which is exactly where a wrong fee schedule enters and stays.

Two structural fixes, neither requiring a reorganization:

Add a rate verification step to the enrollment completion checklist. Enrollment is not done when approval arrives. It is done when a claim has paid at the expected rate.

Give revenue cycle visibility of contract effective dates and revalidation deadlines. They currently sit with managed care and credentialing respectively, and the team that would notice a problem sees neither.

This is the same organizational pattern described in payer contract management, where the contract model is built by one team and needed by another. Credentialing is where the wrong number gets loaded; contract management is where you would detect it. Neither works without the other.

What Credentialing Software Does and Does Not Solve

The product category is mature and the tools are genuinely useful. Worth being precise about which half of the problem they address.

What they do well: track application status, manage documents and expirables, send revalidation reminders, maintain primary source verification, and shorten turnaround. These target failures one and two, the visible ones, and they target them effectively.

What they generally do not do: verify that the rate the payer loaded matches the rate you negotiated. That requires joining enrollment data to contract terms to claim-level remittance, which is three systems that rarely speak, and it is not what a credentialing platform is built for.

So buying credentialing software is a reasonable answer to the enrollment-speed problem and not an answer to the enrollment-accuracy problem. If a vendor tells you otherwise, ask specifically how the product knows what your contracted rate is. Most will not have a good answer, because knowing that is not their job.

The verification capability sits closer to the expected-versus-allowed reconciliation described in revenue cycle management software build or buy, and the claims processing configuration layer is where the comparison would run.

What Your Systems Have to Do

Four requirements, and only the first is about credentialing.

Track enrollment status and revalidation dates as deadlines with owners, in the same way filing limits are treated. A date nobody watches is a date that passes.

1. Join enrollment records to contract terms. Which provider, under which contract, at which rates, effective when. Without this join, rate verification is manual forever.
2. Verify the first paid claim after any enrollment or contract change. Automated where possible, manual where not, but never skipped, and never assumed because approval came through.
3. Alert on allowed-amount changes that should not have happened, and on the absence of changes that should have. The second half of that is the one nobody builds, and it is the one that catches a rate that never loaded.

The integration honesty: enrollment data, contract terms, and remittance detail live in three different systems with three different identifiers for the same provider, and reconciling that identity is where the work actually is. Anyone scoping this without asking how your provider identifiers map across those systems has not scoped it.

Six Checks Before Your Next Revalidation Cycle

In the order I would run them.

1. Pull one post-effective-date claim for each of your top payers and compare the allowed amount against the previous schedule. This is the check from earlier and it is the highest-yield thing on this list.
2. List every provider’s revalidation date in one place. If this does not exist, that is the finding.
3. Check whether any provider is currently billing under a group when enrolled individually, or the reverse.
4. Ask who verifies the rate after an enrollment completes. If the answer is a job title rather than a name, or a shrug, you have located the gap.
5. Confirm revenue cycle can see contract effective dates. They usually cannot.
6. Check enrollment status directly in the payer’s system rather than in your own records for a sample of providers. Your record of their status and the record of their status are different data.

For where this sits in the wider cycle, medical billing versus revenue cycle management sets out the scope. Upstream, insurance eligibility verification covers the patient-side equivalent of this problem, and CDI and charge capture cover the revenue that never becomes a claim at all. If handing the work over is on the table, outsourcing revenue cycle management covers where that line falls, and denial management handles the loud failures at the other end. A revenue cycle analytics view is where a rate discrepancy would surface if anything were watching for it.