Operations

You Can’t Detect Underpayment Until You Can Price It

By Better Software · Wed Sep 16 2026 · 8 min read

The real problem is not detection

Most pages on payer contract management software start too late. They assume you already know the contracted rate and just need to compare it to the remittance. That works in a single-site practice with one payer file, one tax ID, and one stable fee schedule.

It breaks the moment a provider group grows by acquisition.

After two or three deals, a multi-location physician, dental, or specialty group is usually living with multiple TINs, multiple practice-management systems, inherited payer agreements, and a billing team that can see payments but cannot reliably answer the basic question: what did this payer actually pay us, per CPT, per location, against what we agreed?

If you cannot price the claim correctly, you cannot detect an underpayment. What looks like a “zero-balance transaction” may be a silent underpayment, a misapplied modifier rule, a stale fee schedule, or a contract that was never loaded correctly after an acquisition. The issue is not simply reconciliation. It is contract truth.

Why this is happening now

Two market changes made this problem more visible and more solvable.

First, Transparency in Coverage machine-readable files let provider groups see what payers are paying other providers for the same codes in the same market. That does not solve your internal pricing problem, but it changes the negotiation dynamic. A renewal is no longer just a payer assertion contest.

Second, LLM-based contract extraction reduced the cost of abstracting payer agreements from an analyst-week to minutes. That is why the category relaunched itself in 2025 and 2026 as “AI-native.” The extraction got cheaper. The hard part did not disappear. It just moved.

The hard part is building a rate model you can defend.

What acquisition breaks

In a de novo group, a payer contract usually maps to one business structure. In an acquired group, that assumption is wrong from day one.

You inherit:

executed agreements that are missing, incomplete, or stored in someone’s email
different fee schedules for different TINs under the same payer
location-specific rates or carve-ins created during prior negotiations
older contract language still governing dates of service that span several amendments
PM systems that store one “truth” per payer, even when the group has several truths

The practice-management system is rarely the source of truth. It usually stores a single fee schedule and treats it as universal. That is not a contract model. It is a simplification that breaks as soon as the business acquires another office.

So the first question is not “what are we being underpaid on?” It is “what rate should have applied to this date of service at this location under this TIN, under the contract version in force?”

1) Start with the contract inventory, not the claims

If you are acquiring a group, the contract inventory should be part of close diligence, not a post-close cleanup project.

At minimum, request:

all executed payer agreements and amendments
fee schedules by payer, product line, TIN, and location if applicable
delegated credentialing or participation exhibits
term sheets, side letters, and renewal notices
any correspondence that changed rates outside the original agreement
a list of active payers by location and rendering/billing TIN

When nobody has the executed agreement, treat the contract as unverified until proven otherwise. Do not rely on a payer portal screenshot or a stale fee schedule in the PM system as evidence of the actual contract. You need the document trail, the effective dates, and the rate logic.

If the seller cannot produce it, your model should mark that contract as incomplete and assign a recovery status: known, assumed, or unknown. Unknown is a legitimate answer. False precision is not.

2) Map location to TIN to contract

Most groups fail here because they think of “the payer contract” as a single object. In reality, the contract is a relationship between payer, product, TIN, location, and date of service.

Your model should be able to answer:

Which location billed the claim?
Which TIN submitted it?
Which rendering provider was on it?
Which payer product was active?
Which contract version was in force on that date of service?

Without that mapping, your system may apply the right rate to the wrong entity. That creates false underpayments, false recoveries, and bad renewal decisions.

This is the point where many groups discover that they need a rate-and-performance layer above their PM system. The PM system handles transactions. It does not handle contract lineage.

3) Model expected payment like an engineering problem

Once you have the inventory and the contract mapping, the next step is not simple spreadsheet work. It is expected-payment modeling.

For the top 50 codes that drive most of your revenue, your model should account for:

multiple procedure reduction rules
modifier effects
bilateral adjustments
bundling and inclusive-code logic
carve-outs for specific services or sites
lesser-of language tied to billed charges, fee schedules, or allowed amounts
effective-date versioning so a 2024 date of service prices against the 2024 contract, not the 2026 renewal

This is where most “underpayment detection” tools stop being enough. They can flag a variance between expected and actual payment only if the expected payment is already modeled correctly. In an acquired group, that model has to reflect contract history, not just current state.

Pricing a claim is not a clerical task. It is an engineering problem with rules, exceptions, and time-based versions.

4) Separate underpayment recovery from contract performance

Underpayment recovery and contract performance are related, but they are not the same thing.

Underpayment recovery is the tactical chase: individual claims, remits, appeals, and payer calls. It matters, but it is usually reactive.

Contract performance is the strategic view: your realized rate by CPT, payer, and location over time, compared with the contracted rate you believe should have applied. That tells you whether the contract is performing, whether payment variance is systemic, and whether a renewal should be negotiated from evidence rather than anecdotes.

Owners often ask for a list of “the biggest underpayments.” That is a symptom report. A better question is: what is our realized rate on our top codes by payer and location, and where are we leaking margin?

That answer changes the conversation. It turns renewal from “we feel this payer is low” into “for these 18 codes at these 6 locations, our realized rate has diverged from the contract by X% since the last amendment.”

That is the difference between chasing money and understanding payer economics.

What to buy, what to own

The build-versus-buy question is straightforward if you separate detection from model integrity.

Buy the detection engine if:

your contract structure is standard
you have clean, complete rate data
one payer contract maps cleanly to one fee schedule
your locations do not materially vary by rate

In that setup, a vendor can compare remits to expected amounts efficiently.

Build or own the rate-and-performance layer if:

you have multiple TINs or legacy entities
contract versions overlap by effective date
some agreements are missing or partially documented
location-specific rates exist
you need to normalize several PM systems into one contract truth

That is the more common case after acquisition. In a non-standard structure, buying detection alone is not enough because the vendor will still ask you for the rate model you do not yet have.

The right architecture is usually layered: own the contract inventory, mapping, versioning, and realized-rate model; buy the workflow and alerting where it is repetitive.

What the owner should ask before signing another renewal

Before you sign an escalator amendment or renewal, ask four questions:

What contract version applies to each location and TIN today?
What is our realized rate on the top codes under that contract?
Where are we seeing variance between expected and actual payment?
What evidence do we have if the payer says the current rate is already in place?

If you cannot answer those, you are negotiating from weakness. The payer may have better data than you do, and without a dated, location-aware model, you have little leverage.

How Better has seen this problem in practice

This is not a theoretical software problem. It is the recurring engineering problem in healthcare groups that grow through acquisition: data exists, but it does not agree across locations and systems that were never designed to reconcile.

At Apex Dental Partners, a dental group that has grown past 45 practices, Better built the reporting and business-operations layer that turns fragmented operational data into numbers an owner can act on. The underlying challenge is the same one payer-contract workflows run into: reconciling location-level truth across multiple systems, then making it usable for decision-making.

You can read more about that work here and see our broader healthcare experience here.

Closing thought

Underpayment detection is valuable, but only after pricing is trustworthy. For a multi-location group built through acquisition, the first job is not to find the variance. It is to create a dated, location-aware contract model that can explain the variance when you do.