Validating Contractual Adjustments

A remittance reports several numbers against each paid line, and most of them the practice can only accept. What the plan paid depends on where the patient stands against a deductible and a coinsurance share that the practice does not administer and cannot fully verify. What the patient owes is the plan's determination of that same status. But the contractual adjustment is different in kind, because its correct value is not the payer's private business — it is fixed by the agreement the two sides signed, and the practice holds its own copy of the rate.

That checkability follows from how a remittance is built. A compliant electronic remittance advice must balance: the billed charge equals what the plan paid, plus what it assigned to the patient, plus the adjustments it reported — the entire gap between the charge and the payment has to be accounted for by coded adjustments, or the transaction does not balance. In an ordinary paid claim that makes the arithmetic exact: the allowed amount is what the plan paid plus the patient's share, and the contractual adjustment is the billed charge reduced to that allowed amount. So checking the contractual adjustment and checking the allowed amount are the same act — and the allowed amount is a predetermined fee-schedule figure the practice can look up. The arithmetic of that split is set out in From Billed Charge to Collected Dollar; the point here is only that it leaves the contractual adjustment as the single line with a knowable right answer.

The reason an oversized adjustment posts without objection is that the remittance says, in code, that it is legitimate — and it is telling the truth about the only thing the code covers. Every reduction the payer makes carries a group code naming the general category of the adjustment, and a contractual-obligation code marks an amount as one the contract or a regulation required, generally the provider's to absorb and not billed to the patient. Federal Medicare guidance is explicit on both halves of that: the group code identifies the category of an adjustment, and a contractual-obligation amount is generally a provider write-off.

What the code does not do — what no group or reason code does — is certify that the amount was the amount the contract required. It answers a question about liability: is this the provider's to absorb, or the patient's to pay? It is silent on magnitude. There is no code that means "the plan allowed less than the contract," so a payment that came in short does not arrive labelled as short; it arrives labelled contractual, because the part of it that is genuinely contractual is real and the excess rides in beside it under the same code.

This is why validating the adjustment is a different job from the one Contractual Adjustment vs. Write-Off describes. That article uses the group code to answer the category question — is this the contract executing, or a discretionary write-off the practice chose — and its whole discipline is recording which. It takes the contractual amount as assigned by the payer and correct on its face. Validation starts one step later: granting that the amount is contractual, is it the right amount? An adjustment can pass the category check cleanly — it truly is the provider's obligation, not a patient charge — and still be too large. Reading the group and reason codes themselves belongs to Reading a Denial; here the code is only ever telling you the category, never the correctness.

An electronic remittance is built to be posted automatically, and where it can be, it should be — matching a structured remittance to structured claims is faster and more consistent than a person keying it, and federal guidance describes the ERA as something that enables a provider to auto-post payments to its receivables. The engine reads the payment and the coded adjustments off the transaction and books them against the accounts. What it books is what was transmitted.

And that is the gap. The posting engine does not hold the contract. It knows the billed charge and it knows the adjustment the payer reported, and those two are internally consistent — they balance, which is all the engine is positioned to confirm. It has no independent figure for what the contract should have allowed, so it cannot notice that a contractual adjustment is larger than the agreement requires. It applies the number, closes the balance, and moves on, doing at machine speed exactly what a person posting the remittance at face value would do: trusting the one figure that most deserves an independent check.

The check has a definite shape. The practice holds the applicable rates — the loaded fee schedule or contracted amounts for that payer and plan. For each paid line it re-derives the expected allowed amount from those rates, computes the expected contractual adjustment as the billed charge reduced to that expected allowed amount, and compares it to the adjustment the remittance actually reported. Where the reported adjustment is larger than the expected one, the plan allowed below the contract, and the difference is a concealed underpayment — a real shortfall wearing a contractual code. The contractual variance calculator runs that comparison for a single claim: the expected allowed amount from your own rates against what the payer actually allowed, per line and in total.

The critical word is external. Re-reading the remittance more carefully will never surface the problem, because the remittance is internally consistent by construction — it balances, and a short payment balances exactly as neatly as a correct one. The only thing that can disagree with what the payer decided is a figure computed outside the payer's own numbers, and the contract is that figure. This is the same limit Underpayments and Overpayments draws for variances in general — the signal has to come from outside the transaction — applied to the moment of posting. It is also the standard expected-payment discipline of the wider revenue cycle: load the contract's terms in a form that can be compared against each payment, compute what the payer should have paid, and let the variance surface itself rather than waiting to notice it.

Everything above is one comparison — the reported contractual adjustment against the one the contract implies — and the value of running it at posting is timing. At posting the account is still open, the remittance is in hand, the claim is fresh, and the window to recover a shortfall is at its widest. Catch the variance here and it is a line held for review before it ever closes; miss it and the account balances to zero, drops off every worklist, and takes the shortfall with it.

That is the exact case a zero-balance review exists to recover — the retrospective pass over accounts that already closed, re-deriving from the contract what a posting-time check would have caught earlier. The two run the identical comparison and differ only in when: this one is the proactive catch at posting, the zero-balance review is the safety net for what posting-time validation missed or for the accounts posted before it was in place. A practice ideally runs both, and for the same reason — because between the group code that certifies only the category and the accounts receivable that closes on the amount, nothing else in the ordinary flow ever asks whether the contractual amount was right.