Operations
What Does This Payer Actually Pay Us?
Quick Answer
Payer contract management software works only when a group first builds a dated, location-aware model of what each payer should pay by CPT code, TIN, and effective date. The software then compares paid claims against that expected reimbursement to surface underpayments and renewal problems. Groups that grew through acquisitions usually need to own the rate model and buy the detection and workflow tooling around it.
If you cannot say what a payer actually pays you, you cannot tell whether the next renewal is good, bad, or just different. That is the real problem behind payer contract management software for multi-location groups. Before any detection tool can flag an underpayment, you need a dated, location-aware model of your contracted rates.
That model is often missing after acquisitions. One practice management system may hold one fee schedule per payer, but your group may bill under several TINs, with inherited contracts, location-specific rates, and years of amendments nobody has loaded correctly. In that situation, the usual remittance checks only detect a small slice of the problem. The bigger issue is that nobody knows the expected reimbursement calculation to compare against.
Our practical answer is to build the rate model first, then use software to compare paid claims to that model. Otherwise you are asking a tool to find underpayments in data that is already ambiguous.
Why the Renewal Question Becomes Impossible to Answer
It usually starts with a simple request, when a payer sends a renewal, an escalator amendment, or a new rate sheet. Someone asks, “Is this good?” The honest answer is that the group does not know, because it cannot reconstruct the current contract performance by location.
We see that uncertainty often in groups that grew by acquisition. One location may still be paid under an old agreement. Another may have the same payer but a different tax ID. A third may have a contract PDF in an email thread, but no one knows if it was ever executed, effective, or loaded into the billing system.
Once that happens, negotiations turn into anecdote. The owner hears that a payer “usually underpays” or that “this contract is okay,” but those statements are not measurable. A renewal should be judged against the contracted rate vs allowed amount for each major code, at each location, under the correct effective date. If you cannot do that, you are negotiating blind.
Why a Multi-Location Group Is Not a Small Hospital
Hospitals often have centralized contracting and a smaller number of billing structures. A multi-location physician or specialty group usually has the opposite problem, with many payer contracts, multiple TINs, multiple practice management systems, and a mix of commercial, Medicare Advantage, Medicaid managed care, and employer arrangements.
We see four common gaps in that structure:
- The executed agreement is missing, especially after an acquisition.
- The rate varies by location, but the system assumes one fee schedule is truth.
- The effective date history is incomplete, so old claims get priced with current rates.
- The billing team can see remittances, but not the contractual logic behind them.
This is why payer contract management for physician groups is different from simple remittance review. The work is not only to see if a claim paid low. The work is to know what the claim should have paid, given the specific payer, location, TIN, code, modifier, and date of service.
What Expected Payment Actually Requires
Expected reimbursement calculation is not a single fee schedule field. It is a rules engine, even if you never call it that. At minimum, it has to handle effective dates, modifiers, bilateral services, multiple-procedure reduction, bundling edits, carve-outs, and lesser-of language.
Here is a simple illustrative example. Suppose a payer contract says:
- CPT 99213 pays $95 at Location A and $105 at Location B.
- Modifier 25 pays the full amount when properly supported.
- Multiple-procedure reduction applies at 50 percent to the second procedure in the same session.
- If the billed charge is lower than the contract amount, the payer owes the lesser of charge or contracted rate.
Now imagine two claims:
- Claim 1 has Location A billing 99213 with no modifier, so expected payment is $95.
- Claim 2 has Location B billing 99213 with modifier 25 and another procedure in the same encounter. Expected payment may be $105 for 99213, but the second service may be reduced, depending on the contract and claim edits.
If your practice management system stores only one fee schedule rate for 99213, it can easily misprice one of those claims. If it stores Location A’s rate as the universal rate, then Location B looks overpaid or underpaid when it is neither. The same happens when a rate changed on January 1 but the system never loaded the new version, so a claim from March is judged against a December rate.
That is why we say payer contract management software alone does not solve the problem. The software can only compare actual payment to the expected payment you define. If the expected payment model is wrong, the output is wrong in a more polished way.
Where the Data Lives and What Each Source Can Tell You
Most groups have pieces of the answer spread across five places:
- 835 remittance advice tells you what the payer paid, adjusted, or denied.
- 837 claim file tells you what was billed, including modifiers and service details.
- Practice management fee schedule often stores a single contracted rate per payer, sometimes with limited versioning.
- Executed contract PDFs and amendments define the legal rate, but are often incomplete or scattered.
- Transparency in Coverage machine-readable files can show negotiated rates in the market, which helps with benchmarking and renewal discussions, but they do not replace your own contract history.
Our key point is that none of these sources, by itself, gives you trusted payer contract performance by location. The 835 shows cash. The 837 shows intent. The contract shows terms. The Transparency in Coverage files can help you ask better questions at renewal, but they are not a substitute for your own contract model. The Transparency in Coverage rule requires health plans to disclose negotiated in-network rates, and the HIPAA remittance advice standard is what shapes the 835 you receive.
The Four Failure Modes That Make Underpayments Go Quiet
1. Zero-Balance Underpayments
Many underpayments never become a visible balance. The payer pays less than expected, the contract adjustment posts, and the account closes. If nobody compares the payment to the correct contracted rate, the loss disappears into normal billing activity. This is why zero balance underpayments are so dangerous, and why we look for them first. They do not look broken.
2. Lapsed Escalators
Some contracts step up annually. If the escalator does not get loaded, the group keeps accepting last year’s rate. A renewal may even preserve the escalator in writing, but the billing system still uses the old amount.
3. Wrong TIN, Wrong Contract
After acquisitions, the same location may bill under a new or old tax ID depending on the date of service or payer setup. If the mapping between location and TIN is wrong, the group may compare the payment to the wrong contract entirely.
4. Rate Changes at Renewal That Were Never Versioned
A payer may add a new amendment, but the team may only overwrite the fee schedule instead of preserving history. Then a 2024 date of service gets judged against a 2026 rate, or the reverse. Without effective-date versioning, underpayment in medical billing becomes hard to prove and easy to misclassify.
Recovery Is Not the Same as Performance
We find it helps to separate two different jobs. Recovery asks, “Which specific claims were paid incorrectly, and can we get the money back?” Performance asks, “What is this payer actually yielding across locations, and should we renew, renegotiate, or exit?”
Those are related, but they are not the same workflow.
| What you want | Recovery workflow | Performance model |
|---|---|---|
| Cash from specific claims | Yes | Sometimes |
| Defensible renewal position | No | Yes |
| Realized rate by CPT, payer, and location | Partial | Yes |
| View of contract leakage across the network | Limited | Yes |
| Appeal and follow-up queue | Yes | Sometimes |
| Termination or payer-mix decisions | No | Yes |
In practice, a recovery tool can help you collect money that has already been missed. But if you do not have a reliable contract performance model, you still cannot tell if the payer is worth keeping on the current terms. That matters more than many operators expect, because the renewal decision is often larger than the recovery sum. We cover the denial side in which location caused a denial.
What to Buy and What to Own in Payer Contract Management Software
We find the build-versus-buy question becomes clearer once you separate detection from the rate model.
Buy the parts that are easier to standardize:
- Claim-level underpayment detection.
- Benchmarking against external payer rates, where available.
- Appeal workflow and work queues.
- Reporting that helps staff pursue recoveries faster.
Own the parts that reflect your organization’s messiness and history:
- The contract inventory.
- The map from location to TIN to payer contract.
- The effective-date history for each rate.
- The logic for how your contracts handle modifiers, reductions, carve-outs, and lesser-of language.
- The ability to model your top 50 codes accurately enough to guide renewal decisions.
The threshold for building is not “we want custom software.” It is “our structure is non-standard enough that a vendor cannot model it correctly without treating our contracts as a special case.” If you have one TIN, one PM system, and clean fee schedules, a vendor may be enough. If you have several acquisitions and inherited agreements, you usually need a rate-and-performance layer you control.
That does not mean building everything from scratch. It means owning the part that defines truth for your business and buying the part that flags exceptions and routes work.
What Owning It Looks Like in Practice
Our operational sequence is straightforward, even if the data work is not:
- Inventory every payer contract, including amendments, term dates, and missing executed copies.
- At acquisition close, require the seller to hand over contracts, payer portals, fee schedules, and a list of payer-TIN-location relationships.
- Map every location to the TIN and contract that should apply on a given date of service.
- Version rates by effective date instead of overwriting them.
- Model your top CPT codes first, because that is where the biggest revenue exposure usually sits.
- Reconcile expected payment against 835s to find real underpayments and silent leakage.
- Push exceptions into a human work queue for review, appeal, or contract cleanup.
This is the same general shape as the reporting and business-operations layer we built across Apex Dental Partners, a dental group that has grown past 45 practices. The recurring problem there is not just collecting data. It is reconciling data across locations and systems that were never designed to agree, then turning it into numbers an owner can act on. That is the kind of work we take on in healthcare software development.
How to Start Without Overbuilding
If you are the owner-operator who has to sign the next renewal, start with the minimum model that gives you an answer you can defend. For the top payers and top 50 codes, you want to know the contracted rate by location, the effective date, and the main contract rules that change payment. That alone is enough to tell if a renewal is moving you in the right direction.
We would then ask three questions before buying or building anything:
- Can this system keep historical rates by effective date?
- Can it distinguish payer, TIN, and location, or does it collapse them into one fee schedule?
- Can it calculate expected reimbursement from the actual claim, or only compare remittance to a stored rate?
If the answer to those questions is no, payer contract management software may still help with detection, but it will not solve the core contract-management problem. The groups that get the most value are the ones that first make their own rate truth legible, then use software to keep it honest. We cover the billing side in reconciling medical billing against your practice software. If you want help building that rate layer, we do this work at Better Software.
Frequently Asked Questions
What Is a Contracted Rate in Medical Billing?
We define a contracted rate as the amount a payer agreed to pay for a covered service under a contract. It can vary by CPT code, location, TIN, effective date, and contract language such as modifier rules or carve-outs, so we always record those fields with it.
What Is the Difference Between a Contracted Rate and an Allowed Amount?
The contracted rate is the negotiated amount. The allowed amount is what the payer recognizes for the claim, which may be lower after modifiers, reductions, bundling, or lesser-of rules apply. We compare both against what was paid, because the gap between them often explains a low remittance.
What Is Underpayment in Medical Billing?
Underpayment happens when a payer pays less than the contract says it should, after the correct rules are applied to the correct claim and date of service. We only call it underpayment once we have confirmed the rate, the TIN, and the effective date behind the expected amount.
Which Scenario Indicates Underpayment?
We look for a paid claim where the remittance amount is lower than the expected payment for that payer, code, location, and effective date, with no valid contractual reason for the difference. A low payment alone is not enough. The expected amount has to be defensible first.
Do We Need Payer Contract Management Software If Our Billing Company Already Checks Payments?
Maybe, but only if the billing company can show you the underlying rate model and the effective-date history. We see many billing workflows catch individual claim problems. Fewer can tell you if the contract itself performs well across locations, which is the question that matters at renewal.
About the author
Better Software Team
Product and engineering team
Better Software Team is the product and engineering team at Better Software. We build custom software for established businesses in healthcare, energy and finance.