What Does This Payer Actually Pay Us?

You cannot detect an underpayment you cannot price. Before any detection tool works, a multi-location group needs a dated, location-aware model of what each payer actually owes by CPT, modifier, and TIN. Most owner-operated groups that grew through acquisition do not have that model. They have fragments: a fee schedule in one practice-management system, a PDF in an email thread, a payer portal login nobody remembers, and a renewal amendment asking them to sign without a defensible answer to a simple question: what does this payer actually pay us?

That is the problem category most software pages skip. They start at remittance review. But if your contracted rate table is wrong, incomplete, or not versioned by effective date, every “underpayment” workflow is partly guessing. In that environment, payer contract management software is not just a detection category. It is an attempt to build the rate model that makes detection possible in the first place.

The question an owner actually gets asked

The trigger is usually a renewal or escalator amendment. A payer sends a new term sheet. Someone asks whether the increase is acceptable. The owner, who is often also the person handling contracting, needs one number: what are we really getting paid today, by code and location, under the current agreement?

If the group has gone through acquisitions, the honest answer is often: we do not know. One location may still be billing under a predecessor TIN. Another may have inherited a plan contract that was never fully located in executed form. A third may be using a default fee schedule in the PM system that was copied forward years ago and no longer matches the actual agreement. The renewal discussion then becomes an anecdote contest instead of a pricing decision.

Why a group is not a small hospital

The software pitch sounds clean because the buyer is assumed to be a single entity with one system and one fee schedule. That is not the reality for a multi-location physician, dental, or specialty group with 3 to 45 locations and 20 to 150 billing providers.

These groups often have:

• multiple tax IDs, because acquisition history created separate entities;
• multiple practice-management systems, because rollups rarely standardize on day one;
• 40 to 80 active payer contracts across commercial, Medicare Advantage, Medicaid managed care, and direct employer arrangements;
• rate variation by location, by TIN, or by facility setting;
• missing executed agreements, especially for older inherited contracts;
• one person “handling contracting,” who is usually expected to know the answer from memory.

That structure is exactly why a single payer fee schedule field inside the PM system is not enough. It may be useful as a billing convenience. It is not a contract system of record.

What expected payment actually requires

Expected reimbursement calculation is not “charge minus one rate.” It is a rules engine built on contract terms, claim context, and version history. At minimum, you need to know:

• which contract applies to which TIN and location;
• which effective date was in force on the date of service;
• whether the contract is fee schedule based, percentage of charge, or a hybrid;
• how modifiers affect payment;
• whether bilateral surgery or multiple-procedure reduction applies;
• whether bundling, carve-outs, or lesser-of language changes the allowed amount;
• whether the payer pays different rates for the same CPT in different locations.

Example: suppose CPT 27447 at Location A under Payer X has a contracted rate of $1,200, effective January 1, 2024. The contract includes a 50% reduction for the second procedure, a 25% modifier reduction for -59 in some contexts, and “lesser of billed charges or fee schedule” language. On a claim with two units, one primary procedure and one reduced second procedure, the expected payment is not just $1,200 + $600. If the billed charge is below the fee schedule at one location but not another, the allowed amount can be capped by the lesser-of clause. If the date of service is January 2025 and the contract renewed with a new rate on July 1, 2024, using the old fee schedule in the PM system will overstate expected reimbursement and create false underpayment noise.

That is the engineering problem. One static table cannot represent it. You need versioned rates, contract logic, and location-aware mapping.

Where the data lives, and why none of it is sufficient alone

Most groups have pieces of the truth distributed across five places:

• 835 remittances tell you what was actually paid and adjusted.
• 837 claims tell you what was submitted, with which CPTs, modifiers, and charges.
• PM fee-schedule tables usually contain a single assumed rate, not the real contract logic.
• Executed PDFs and amendments contain the legal terms, if you can find them.
• Payer portals and Transparency in Coverage machine-readable files can provide market context and, in some cases, clues about negotiated rates in the market.

Each source is incomplete. The 835 does not tell you what the contract said. The contract PDF does not tell you whether the right rate was loaded. The PM table rarely preserves history. The transparency file does not tell you your specific rate. The only defensible answer comes from combining them into a dated rate model tied to TIN and location.

Worked example: how a single fee-schedule field gets it wrong

Assume Payer Y contracts with the same specialty group at two locations:

• Location A, TIN 11-1111111: CPT 99213 pays $95.
• Location B, TIN 22-2222222: CPT 99213 pays $110 because the contract was renegotiated after acquisition.

Now add one modifier and one timing issue:

• On June 15, 2024, Location B billed 99213-25.
• The contract says modifier -25 is payable at 100% for established patient office visits.
• On January 1, 2025, a renewal reduced the rate to $103, but the PM system was never updated.

If the PM system stores one payer fee schedule of $95 or even $110, it will misprice at least one location. If it does not version by date of service, it will also misprice claims before and after renewal. If it does not know which TIN rendered the service, it will apply the wrong contract entirely. If it does not model modifier logic, it will miss the difference between a clean 99213 and a 99213-25. That is how groups end up arguing about “underpayments” that are really data-model failures.

The four failure modes that make the problem silent

Most leakage in this category does not show up as a loud denial. It disappears quietly.

• Zero-balance underpayments: the claim is closed, the remittance shows a zero patient balance, and nobody flags that the payer paid less than the contract.
• Lapsed escalators: the contract called for annual increases, but no one loaded the new rate or chased the amendment.
• Wrong TIN billing: a location is billing under the wrong entity, so the expected contract is wrong even when the code is right.
• Unloaded renewal rates: the payer changed the rate at renewal, but the PM system kept the old table and the group never reconciled the delta.

These are not just recovery problems. They are contract performance problems. If you cannot measure actual realized rate by payer, CPT, location, and date, you cannot know whether the contract is performing or whether the group is absorbing avoidable leakage.

Recovery versus performance

Workflow	What it gives you	What it misses
Recovery	Cash from specific claims; appeal letters; short-term collections	Whether the underlying rate model is correct; whether the contract is good; whether the issue repeats elsewhere
Performance	Realized rate by payer, CPT, location, and contract version; renewal leverage; termination decisions; payer mix insight	Some claim-by-claim cash unless paired with a recovery workflow

A recovery workflow asks, “Can we get this claim paid correctly?” A performance model asks, “Is this payer actually producing the margin we thought it was, and should we renew at all?” For an owner signing an escalator amendment, the second question matters more.

Build versus buy, stated plainly

Not every layer should be bought. The cleanest answer is usually this:

• Buy the detection engine, appeal workflow, and benchmarking if you have relatively standard structure and clean contract data.
• Own the rate model, the TIN-and-location map, the contract inventory, and the effective-date history.
• Build the performance layer when your structure is non-standard enough that a vendor’s assumptions will be wrong more often than they are right.

The threshold is simple: if your group has multiple TINs, inherited contracts with missing PDFs, location-specific rates, and more than one PM system, a generic product will usually detect only after the model is already clean. That is too late. In those environments, the valuable asset is not the alert; it is the contract database that makes the alert meaningful.

What owning it looks like in practice

Owned well, this looks like an operations layer, not a spreadsheet. It starts at acquisition close. The seller should be asked for executed payer agreements, amendments, fee schedules, rate sheets, and any payer correspondence that changed reimbursement. If a contract cannot be found, the group should reconstruct it from remits, portal downloads, and historical claim behavior, then mark the confidence level clearly instead of pretending certainty.

Then the group needs a structured map from location to TIN to contract, with rates versioned by effective date. A recurring job compares expected payment against 835s, surfaces exceptions, and routes only meaningful variances to humans. That is the same general shape as the reporting and business-operations layer Better built across Apex Dental Partners, a dental group that has grown past 45 practices: reconcile data across locations and systems that were never designed to agree, and turn it into numbers an owner can act on. See the Apex case study and our healthcare work.

How Transparency in Coverage changes the negotiation

Two developments changed the economics of this problem. First, Transparency in Coverage machine-readable files made it easier to see what a payer pays other providers for the same code in the same market. Second, LLM-based contract extraction made it far cheaper to abstract agreements at scale. Together, they change the renewal dynamic. The payer can no longer rely on the group not knowing the market. But the group only benefits if its own rate model is clean enough to compare apples to apples.

Without that model, transparency data becomes interesting but not actionable. With it, the renewal is no longer an assertion contest. It becomes a data question.

FAQ

What is a contracted rate in medical billing?

The contracted rate is the amount a payer has agreed to pay for a service under the provider’s contract, subject to the contract’s rules, effective dates, and claim-specific adjustments.

Contracted rate versus allowed amount: what is the difference?

The contracted rate is the agreed payment basis. The allowed amount is the actual amount a payer recognizes for the claim after applying contract terms, modifier logic, bundling, reductions, and any lesser-of language. In some contracts they are the same; in many they are not.

What is underpayment in medical billing?

Underpayment is when the payer pays less than what the contract says should have been paid for that claim, given the correct code, location, date of service, and contract terms.

What is a zero-balance underpayment?

A zero-balance underpayment is an underpaid claim that closes with no patient responsibility remaining, so the revenue cycle may never flag it unless the group compares expected payment to actual payment.

Which scenario indicates underpayment?

A payer reimburses a claim below the contracted rate after the correct modifiers, date of service, and location-specific contract are applied. A second common scenario is when the payer pays a renewed claim using an expired fee schedule.

Do we need payer contract management software if our billing company already checks payments?

If your billing company is only comparing remittances to a static fee schedule, it may catch some recovery opportunities but still miss contract performance issues. If your structure is non-standard, you need a trustworthy rate model first. Software can help, but only after the contract data is modeled correctly.

The core issue is simple: if you do not know what the payer agreed to pay, you cannot reliably tell whether it paid you less. For a multi-location group, the job before renewal is not to chase every remittance. It is to build the rate model that makes the conversation about money real.