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.

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.

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.

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 its remittance and looks exactly like an error. The remittance says 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, 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.