How to find underpayments hiding in your remittance data

A denial announces itself. It comes with a code, a reason, and a place in a work queue. An underpayment does none of that. The payer paid, the claim closed, and everyone moved on. The only way to know the payment was short is to compare it against what the contract says it should have been, line by line, and almost nobody does that for every claim.

That is why underpayments are the quietest leak in the revenue cycle. Not the biggest in every practice, but reliably the least examined.

The comparison, in principle

The idea is simple. For every paid claim, you need three things: what the payer allowed and paid, what your contract says the allowed amount should be for that procedure with that payer, and the difference between them.

In principle, that is a spreadsheet exercise. Pull your remittance data, pull your fee schedules, match on payer and procedure code, and subtract.

Why it is harder in practice

Anyone who has actually tried this knows where it breaks down.

The contract is not one number. The allowed amount can depend on the procedure code, the modifier, the place of service, the locality, and the effective dates of the rate. A comparison that matches only on payer and CPT will flag correct payments as short and miss real shortfalls, and after a few dozen false alarms, whoever was doing the comparison stops trusting it.

Payment rules complicate the raw numbers. Multiple procedure reductions, modifier-based payment adjustments, and bundling rules all produce payments that are below the face rate on purpose. A naive comparison calls these underpayments. They are not, and separating them from the real shortfalls is where most manual efforts die.

The fee schedules on file drift. Contracts renew, rates change, amendments arrive, and the version loaded into the practice management system quietly falls behind the version the payer is actually adjudicating against. When that happens, the comparison is wrong at the source.

And the volume is relentless. Even a modest practice generates too many remittance lines for a person to check each one. So the checking, where it happens at all, happens on the big claims, and the small shortfalls accumulate unexamined, which is the same math that builds the write-off pile.

A practical way to start manually

If you want to test the water without any tooling, do a narrow slice honestly rather than a broad slice badly.

Pick one payer and your five highest-volume procedure codes with that payer. Confirm the current contracted rates for those codes directly from the contract document, not from what is loaded in your system. Pull ninety days of remittances for those codes and compare the allowed amounts against the contract, keeping modifiers and place of service in view. Set a tolerance so you are not chasing pennies, and look at what remains.

Two outcomes are common. Either the payments check out, which is genuinely good news and worth knowing, or a pattern appears, and it is almost never random. Underpayments cluster: a specific payer on a specific code from a specific date forward. That clustering is what makes them findable, and it usually traces back to something identifiable, like a rate that changed on one side but not the other.

Where automation earns its keep

The manual slice tells you whether a problem exists. It cannot tell you the size of it, because the size lives in the volume you cannot check by hand.

This is the part that genuinely needs a system: resolving every paid claim against the specific contract line that governs it, with the modifier, place of service, and effective dates respected, applying tolerance so noise stays out, and separating payments that are low for a legitimate rule-based reason from payments that are simply short. Done that way, the output is not a suspicion. It is a list of verified shortfalls, each carrying its contract basis, ready to be pursued with the reference in hand.

That verification step matters more than the detection step. A payer review request that says the payment feels low goes nowhere. One that cites the contract line, the effective dates, and the exact difference is a different conversation.

This is one of the core things Prexisio does. Contracts come in during setup, every placed claim gets resolved against its governing rate, and the shortfalls we pursue are the verified ones, with the basis shown. Where a payment turns out to be correct under a payment rule, we say that too, because a recovery effort that chases correct payments burns the credibility that the real shortfalls need.

The uncomfortable truth about underpayments is that not looking is a decision. The contract rate is the price you negotiated. The only question is whether anyone is checking that you are being paid it.