Payer Contract Management: You Cannot Detect What You Never Modelled

A denial announces itself. It arrives with a reason code, lands in a work queue, and somebody is accountable for working it.

An underpayment arrives as a payment. It posts. The account closes. Every report downstream records it as a success, because by the only definition those reports use, it was one.

So the two failures are not comparable operationally, even when the dollars are. One generates a document and a job. The other generates nothing at all, and the only way to notice it is to have independently worked out what the payment should have been before it arrived.

That calculation is what a payer contract model is for, and where most organizations lose this is not in the detection tooling. It is in where the model comes from. For the wider argument about metrics that cannot see their own blind spots, how to improve revenue cycle management covers it, and the 13 steps of the revenue cycle is the plainer orientation.

Payment Variance and Underpayment Are Not the Same Thing

Worth separating before anything else, because conflating them is why variance reports get built and then quietly abandoned.

A payment variance is the gap between what you expected from the contract and what actually arrived. An underpayment is a variance that reflects a genuine payer error, where more was owed based on the contract terms, the documentation and the coding.

Every underpayment is a variance. Most variances are not underpayments.

A variance can arise because your own coding was wrong, because the contract term in your model was captured incorrectly, because a legitimate adjustment applied that the model did not account for, or because the claim genuinely was paid short. Only the last is recoverable, and chasing all four with equal effort is how a recovery program burns its credibility in the first quarter.

The useful discipline is to treat variance as a queue and underpayment as a conclusion. Variance is what the system flags. Underpayment is what a person confirms after checking which of the four it is.

Detection Requires a Number the Payer Never Sends You

Here is the mechanical constraint, and everything else in this article follows from it.

To know a claim was underpaid, you need two numbers: what was paid, and what should have been paid. The remittance gives you the first. Nothing gives you the second. The payer does not transmit their calculation of what your contract entitled you to; they transmit what they decided to pay.

So the expected amount has to be computed on your side, from your contract, against that specific claim’s codes, modifiers, units and place of service. That computation is a contract model.

This is why underpayment detection is not really a detection problem. It is a modeling problem wearing a detection problem’s clothes. Tooling that compares two numbers is straightforward; the difficulty is entirely in producing the second number accurately enough that the comparison means something.

And it explains a pattern I see repeatedly: organizations buy a variance tool, run it, get a flood of flags that turn out mostly to be model errors rather than payer errors, lose faith, and stop looking. The tool was fine. The model underneath it was never built to the standard that claim-level auditing requires.

The Model Gets Built Once, for the Wrong Purpose

Now the part that I think explains most of the gap.

Contracts do get modeled. When a payer contract is up for negotiation, somebody in managed care builds a model to answer a decision question: at these proposed rates, across our expected volume and case mix, what does this contract earn us, and should we sign it.

That model is often good. It is built carefully, because a signature depends on it.

Then the contract is signed, and the model is filed.

Nothing carries those parameters forward into claim-level auditing. The organization computed the expected payment once, for a decision, and never again for enforcement. Six months later, when someone asks whether this payer is actually paying per contract, the answer requires rebuilding from scratch what already existed in a spreadsheet somewhere.

The principle worth adopting is simple to state and awkward to implement: the parameters used to model a contract during negotiation should be the same parameters used to audit that payer’s adjudication afterwards. One model, two uses. Not two models, one of which does not exist.

HFMA’s work on managing and measuring payer performance sits in this territory, and it is worth reading alongside this because it treats payer performance as something you measure continuously rather than assess at renewal.

The organizational obstacle is usually not technical. Managed care owns negotiation. Revenue cycle owns collection. The model lives with the first and is needed by the second, and in most structures nobody owns the handoff.

What a Contract Has to Become Before It Can Be Audited Against

A signed contract is a document. Detection needs it as data, and the gap between those two states is the real work.

Rate structures, expressed per code: Percentage of charges, case rates, per diems, fee schedule references, carve-outs. Each behaves differently, and each has to be computable for a given claim.

The modifiers and conditions that change the rate: Multiple procedure reductions, bilateral rules, assistant surgeon percentages, and place-of-service differentials. Many of these mirror payment policies are published in the CMS Physician Fee Schedule and the National Correct Coding Initiative, which is a useful reference point even where a commercial contract deviates from them. This is where models most often diverge from reality.

Stop-loss and outlier provisions, which apply conditionally and are frequently omitted from a model built for average-case negotiation economics.

Effective dates and amendments: A contract modeled at signature and never updated will disagree with reality the first time an amendment lands, and the disagreement will look like a payer error.

Whatever your chargemaster does, since expected payment for percentage-of-charge arrangements depends on your own pricing being what the model assumes.

None of that is exotic. All of it is detailed, and detail is what determines whether the flags your system produces are worth a human’s attention. This is the same category of problem that claims processing configuration deals with on the edit-rule side: the rules exist, and the question is whether they live somewhere a system can evaluate.

What Your Systems Have To Do

Four things, and the first two are the ones that determine whether the rest is worth building.

1. Hold contract terms as structured, versioned data: Structured so a rate can be computed per claim. Versioned so that when an amendment changes a term, historical claims are still evaluated against the terms that applied on their date of service.
2. Compute expected allowed at the line level, not the claim level: A claim can be correct in total and wrong on a line, and line-level is where a recoverable finding is specific enough to appeal.
3. Triage variance before it reaches a human: Route each of the four causes differently. A model error should go back to whoever maintains the model, not into a recovery queue.
4. Feed confirmed underpayment patterns back into the next negotiation: A recurring underpayment on a specific term is negotiating evidence, and it is usually the highest-value output of the whole exercise. It is also the one most often left in a spreadsheet.

On the engineering side, since it is worth being plain: the comparison logic is easy and the contract digitization is not. Getting terms out of signed documents and into a structure that computes correctly against real claims is where the time goes, and it does not compress well. Anyone quoting this work without asking to see three of your actual contracts has not scoped it. If you are weighing whether to build this capability or buy it, revenue cycle management software, build or buy is the framework, and the expected-versus-allowed argument in that piece is the same one made here from the other direction.

Where Does This Connect to the Rest of the Revenue Cycle

Two links are worth drawing explicitly, because this capability tends to be treated as a standalone finance project.

It is the missing half of denial management: A denial queue handles claims that did not pay. Nothing in it handles claims that paid short. Denial management plus variance detection covers the full space; either alone leaves a category unattended.

It is where the specialty failures become visible: The orthopedic case in this cluster is the clearest illustration: choosing the wrong global-period modifier produces a claim that pays at a reduced rate and never denies. That failure is undetectable without an expected-payment calculation, which is exactly what a contract model provides. Orthopedic revenue cycle management covers the mechanism, and a revenue cycle analytics view is where the comparison would surface.