Underpayments and Overpayments

Most revenue-cycle failures come with a signal attached. A denial arrives with a reason code on a claim that did not pay. A rejection arrives in an acknowledgment report. An aging claim shows up in a bucket that grows. Each one gives somebody something to notice.

Variances give nobody anything. A claim underpaid by a third still pays, still posts, still closes its balance, and still appears in reporting as collected. An overpayment is even more thoroughly disguised: it arrives as extra cash. Nothing in the ordinary operation of a billing office is designed to be suspicious of money that showed up.

An underpayment is a claim paid at less than the contracted rate. The critical distinction is from the thing it most resembles — and it resembles it closely, because both are a gap between what was billed and what arrived. Finding one is where this article ends; contract-based underpayment recovery covers what it takes to get the money back, and why that is markedly harder in this direction than in the other.

Which means detection is a data problem before it is a billing one. Finding underpayments requires holding the contracted rates in a form that can be compared against each payment, systematically. A practice without that reference is not failing to catch underpayments — it has no mechanism by which catching one would be possible, except by accident. Run at the moment of posting, that comparison becomes a check on the size of each contractual adjustment before the account closes — validating the contractual adjustment against the loaded contract — so a payment allowed below the contract is held for review while the account is still open. And even with the reference, an underpayment that has already closed to a zero balance — often because the shortfall itself was cleared with an adjustment — falls off every worklist, since nothing is owed; catching that one is its own discipline, a zero-balance review of the accounts that look done.

An overpayment is an amount received beyond what was owed. It can come from a duplicate payment, a payer's own processing error, two plans both paying as primary, a patient paying more than their final share, or a claim later adjusted downward.

It surfaces as a credit balance — an account showing more received than owed. And a credit balance is genuinely difficult to prioritize, because every incentive runs the wrong way: the cash has already landed, nothing is outstanding, no patient is calling, and no payer is chasing. It is the only item in the revenue cycle where doing nothing feels like a positive balance.

What is safe to say operationally is that credit balances need a review process rather than a queue that gets worked when someone notices — because nothing about a credit balance will ever make someone notice. Once one is confirmed, resolving it is its own procedure: refunding a credit balance to the payer or patient whose money it is, never writing it off.

A payer that identifies its own overpayment may not ask for a check. It may recoup — recovering the amount by withholding it from a later payment. The money comes back out of the next remittance, against a completely different set of claims.

This is worth expecting, because it produces a deposit that does not match the claims on the remittance and looks exactly like an error. The recovery is not attached to any of those claims; it is reported separately, at the provider level, and the payment total the remittance states is the claim payments less that recovery. So the claims add up to one figure, the bank shows a smaller one, and both are correct — the difference was taken back against an older claim. Posting has to reflect the payment and the offset — recording the recovery against the older claim it belongs to rather than the current ones it arrived with, which is what Posting a Payer Offset is about — and a team that does not know recoupment is a normal payer behavior will spend real time investigating a discrepancy that is working as designed.

Both variances distort the numbers the practice uses to judge itself, and they distort them in the direction of reassurance.

An underpaid claim counts as collected. It contributes to the net collection rate as a success and closes out of days in A/R on schedule. A practice with a systematic underpayment problem does not see a metric decline — it sees perfectly respectable metrics, computed from payments that were each quietly short. An overpayment does the reverse, inflating collections with money that will have to go back.