You Cannot Detect an Underpayment You Cannot Price

Payer contract management software has become a popular search term for a reason: provider groups know money is leaking, but many cannot yet prove where, why, or by how much. The problem is not first detection. The problem is pricing.

If you operate a multi-location physician, dental, or specialty group that grew by acquisition, you probably have several tax IDs, several practice-management systems, inherited payer agreements in various states of completeness, and at least one person who “handles contracting” without a reliable source of truth. In that environment, the question is not “is this claim underpaid?” It is “what should this claim have paid, under which contract, at which location, on that date of service?”

Until you can answer that, every underpayment tool is downstream of a bigger gap. You can chase zero-balance transactions all day and still miss silent leakage from outdated fee schedules, expired escalators, and contract terms nobody can reconstruct after two acquisitions and a system migration.

Why the category exists now

Two things changed. First, Transparency in Coverage machine-readable files made payer pricing more visible. For the first time, a group can compare what a payer says it pays other providers for the same code in the same market. That does not solve contract performance, but it changes renewal conversations from “we think we’re underpaid” to “here is the market signal and here is our realized rate.”

Second, LLM-based contract extraction made it dramatically cheaper to turn a scanned agreement into structured terms. That is why so many vendors relabeled themselves as “AI-native” in 2025 and 2026. Useful, yes. Sufficient, no. Extraction only matters if the underlying rate model is trustworthy.

This is the core distinction most pages in this SERP skip: detection is easy compared with pricing. If the rate table is wrong, incomplete, dated incorrectly, or mapped to the wrong TIN or location, every “underpayment” result is suspect.

The real problem after acquisition: no one has the whole contract picture

After an acquisition, groups rarely inherit a clean contract library. They inherit fragments: credentialing files, payer portal screenshots, old amendments, PDF scans, maybe a schedule attached to a settlement agreement, maybe nothing. The practice-management system often stores only one fee schedule per payer, treating it as the truth even when different locations were billing under different negotiated rates.

That creates four failure modes:

• Executed agreements cannot be found.
• Different locations are mapped to the same payer rate when they should not be.
• Effective dates are ignored, so old rates are applied to current claims or vice versa.
• Amendments and escalators lapse unnoticed because nobody is versioning the contract history.

What should you request at acquisition close? Do not stop at “payer contracts.” Ask for the executed agreement for every payer, every amendment, every fee schedule, every side letter, and every notice of change. Ask for a payer roster by TIN and by location. Ask for the last 12 months of 835s, the current fee schedules in use, and any internal pricing workbooks the seller used to negotiate or audit reimbursement. If the seller cannot produce an executed contract, document that gap explicitly and preserve the evidence trail: portal downloads, remits, rate sheets, emails, and historic claims patterns.

If no executed agreement exists, that does not mean the rate is unknowable. It means you have to reconstruct it from the strongest available evidence and label the confidence level. In practice, that often means combining remittance data, claims history, payer portal files, and whatever version of the schedule the group actually billed against.

Map location to TIN to contract before you price anything

A reliable model starts with identity. In acquired groups, the same payer may behave differently by TIN, entity, location, or even specialty carve-out. If you cannot map location to TIN to contract, you are not ready to calculate underpayments.

Build a simple hierarchy:

• Location
• Billing entity / TIN
• Payer
• Plan or product
• Contract version
• Effective date range

That hierarchy needs to support location-level variation. A payer may have one agreement for a flagship site, another for a newly acquired office, and a separate carve-out for a specialty service line. The same CPT code can price differently depending on which location rendered the service and which contract version was active on that date.

This is why a one-fee-schedule-per-payer approach fails. It collapses complexity into a flat table and then asks staff to believe the output. If you want a model you can defend in front of a payer, a partner, or your own banker, you need date-aware, location-aware, contract-aware logic.

Expected payment is an engineering problem, not a data-entry problem

Once the contract inventory exists, the next step is not “load rates.” The next step is expected-payment modelling. That is an engineering problem because real reimbursement is governed by rules, not just fee amounts.

Your model needs to account for:

• Multiple-procedure reduction
• Modifier logic
• Bilateral adjustments
• Bundling edits
• Carve-outs and exceptions
• Lesser-of language
• Per diem, case rate, and percentage-of-charge terms
• Effective-date versioning

For example, if a claim from 2024 is priced using a 2025 rate table, your analysis is wrong even if the contract itself is correct. If a modifier should increase reimbursement and your model ignores it, the “underpayment” may actually be your model missing the rule. If a payer contract says the lesser of billed charges or fee schedule applies, your expected payment logic must implement that language, not flatten it into a single schedule number.

This is where most groups discover the difference between a spreadsheet and a model. A spreadsheet can store rates. A model can price claims.

Underpayment recovery is not the same as contract performance

Many teams confuse chasing individual claims with understanding contract performance. They are related, but they are not the same job.

Underpayment recovery asks: was this claim paid correctly? Contract performance asks: what are we actually realizing per CPT, payer, and location over time, and how does that compare to what we agreed to?

Why does that distinction matter? Because a group can win dozens of small appeals and still be losing on renewal economics. If you do not know realized rate by CPT and site of service, you cannot walk into a renewal or an escalator amendment with evidence. You will have anecdotes, not leverage.

Better data changes the conversation. Instead of saying, “we think reimbursement is bad,” you can say, “for this payer, at this location, on these high-volume codes, our realized rate is below the contracted schedule and trending worse after the last amendment.” That is a contract performance argument, not just a recovery queue.

What to buy, what to own

Buy the detection engine if your rate data is already clean, standardized, and consistently mapped. In that case, software that compares remits to a known schedule can save time quickly.

Build the rate-and-performance layer when your structure is non-standard enough that no vendor will model it correctly. That usually means:

• multiple TINs with overlapping payer relationships
• several practice-management systems
• location-specific contract variation
• missing or partial executed agreements
• acquisitions where inherited rates were never formally normalized

The build-versus-buy answer is not philosophical. It is structural. If the contract source of truth is unstable, buying a detection tool first just automates confusion. Own the contract inventory, the mapping model, the versioning logic, and the historical rate library. Then buy detection where it will actually work.

That is the point at which payer contract management software becomes valuable: after the group has a rate model it can trust. Before that, the software category is solving the wrong layer.

How to get from unknown pricing to defensible numbers

If you are the owner or operator trying to get control of payer economics, the sequence matters:

• Inventory every contract and amendment. Include acquisition-close document requests, portal files, rate sheets, and legacy agreements.
• Map location to TIN to payer relationship. Do not assume one payer equals one schedule.
• Version rates by effective date. A claim should price against the contract in force on the date of service.
• Model your top 50 codes first. Focus on the codes that drive most volume and margin.
• Include contract logic, not just rates. Reduction rules, modifiers, bundling, carve-outs, and lesser-of clauses matter.
• Reconcile to 835s. Only then can you separate pricing errors from posting noise and true underpayment.

That sequence gives you something most groups do not have: a rate model you can defend. Once you have it, you can quantify leakage, prioritize appeals, and negotiate renewals from evidence instead of memory.

What Better has seen in multi-location healthcare operations

The recurring engineering problem is not unique to payer economics: it is reconciling data across locations and systems that were never designed to agree. Better has built the reporting and business-operations layer across Apex Dental Partners, a dental group that has grown past 45 practices, where the practical challenge is turning fragmented operational data into numbers an owner can act on. That same discipline applies here: if the source systems do not agree, the first job is to build the layer that makes them comparable. See more on our work in healthcare.

Bottom line

You cannot detect an underpayment you cannot price. For a group that has grown by acquisition, the first priority is not software selection; it is building a dated, location-aware, contract-aware rate model from incomplete history. Once that exists, detection, recovery, and renewal strategy all become materially stronger.