Underpayment Detection Starts With Contract Truth

The first mistake I see in revenue cycle teams is embarrassingly consistent: they build denial workqueues with surgical precision, then leave underpayments to a spreadsheet and a hunch. That is backwards. Denials are loud. Underpayments are quiet. They slip through because the claim got adjudicated, a check arrived, and nobody asked whether the paid amount actually matched the contract.

I have seen this in live RCM workflows more than once, including AST delivery work where the operational friction was not the math but the contract interpretation. The payer EFT was technically “correct” according to the remittance, and still wrong according to the agreement. The gap was buried in a modifier rule that someone remembered from a contract call but nobody had encoded anywhere. That is the failure mode: institutional memory works until one person leaves.

Contract modeling is not about making contracts pretty. It is about making them queryable. If your finance team cannot ask, “Was this line underpaid by the rule that applies to this CPT under this location and modifier combination?” then you do not have contract modeling. You have document storage.

That sounds obvious until you try to operationalize it. The actual work is ugly. A commercial payer may reimburse differently for the same service depending on place of service, rendering provider type, modifier 25 usage, and whether a code is bundled into another reimbursable line. Then you add fee schedule changes, renewals, retroactive amendments, and the one-off exceptions buried in addenda. Most teams capture the headline rate and call it done. That is where leakage hides.

How I model underpayment logic at AST

At AST, I do not start with dashboards. I start with contract objects and claim objects that can actually be compared. The workflow is simple to describe and annoyingly specific to build. We map the agreement into discrete payer rules, then align those rules to adjudicated claims and remits. That lets us separate true underpayment from expected variance, contractual carve-outs, coding errors, and clean-claim failures that were paid differently because the claim itself was wrong.

In practice, that means I care about five things before I care about a dashboard:

• Whether the contract structure is modeled by payer, plan, effective date, and amendment history.
• Whether line-level rules are separated from claim-level rules.
• Whether modifiers, units, and place-of-service are first-class fields, not comments.
• Whether outliers can be explained by payer policy, not just flagged as variance.
• Whether every detected underpayment points back to the exact rule path that generated the expectation.

If one of those is missing, the finance team will not use the output. They will export it, cross-check it in Excel, and quietly rebuild the analysis by hand. I have watched that happen. It is not a software problem only; it is a trust problem. The engine has to earn its place inside the workflow.

One friction point that catches teams off guard: sometimes the underpayment is real, but the root cause is not payer behavior. It is your own claim setup. A claim may have been paid off the wrong fee schedule because eligibility was stale, the rendering provider taxonomy was missing, or the claim hit a clearinghouse edit that changed the downstream adjudication pattern. If your analytics do not reconcile the claim lifecycle end to end, you will chase the payer when the issue started upstream.

That is why I treat underpayment detection as a revenue integrity problem, not a collections problem. Collections asks whether money arrived. Integrity asks whether the money that arrived matches the agreement and the clinical event that produced the bill. Those are different questions, and the second one is the one that protects margin.

What a useful contract model actually contains

When I build this logic, I split the model into layers that mirror the way payers pay and deny. Here is the structure that holds up in real workflows:

1. Normalize the contract hierarchy Store payer, plan, line of business, employer group if relevant, effective dates, and amendment history. Without versioning, every historical comparison becomes unreliable.
2. Define payment rules at the right grain Separate claim-level rules from line-level reimbursements, then add code-specific exceptions and bundling logic where the contract actually states them.
3. Map operational fields Bring in CPT, HCPCS, ICD-10, modifiers, POS, units, charges, denial codes, authorization status, and rendering/provider identity. If it affects payment, it belongs in the model.
4. Calculate expected payment deterministically Do not bury rule application inside a black-box score. Show the rate, the adjustment, the carve-out, and the source rule that produced the expectation.
5. Compare expected vs paid vs recoverable Some variances are not actionable. The model should distinguish underpayment from write-off, patient responsibility, contractual limitation, and rebillable errors.
6. Create a worklist with proof Every flagged line needs the contract path, the remittance evidence, and the follow-up action. People do not work variances; they work cases.

That last point is the part teams usually skip. Analytics without a follow-up path becomes a report nobody owns. I want the system to tell an analyst exactly what to do next: rebill, appeal, request reconsideration, or write off as contractually correct. The model should shorten the decision, not just surface the issue.

That comparison is the real tradeoff. Spreadsheets feel flexible because they accept anything. They are also why teams spend half a close cycle arguing about which version of the contract was current when the claim hit. A rule-based model is stricter up front and faster forever after.

AST’s practical sequence for revenue cycle teams

If you want to stand this up this quarter, I would do it in this order:

1. Pick one payer and one service family Do not boil the ocean. Choose a payer with enough volume to matter and enough rule complexity to prove the design.
2. Inventory the contract versions Gather the signed agreement, amendments, fee schedules, and any operational notes that changed adjudication behavior over time.
3. Normalize codes and claim fields Build the mapping for CPT, HCPCS, ICD-10, modifiers, POS, and units so the model can reason at the same grain as adjudication.
4. Write the payment rules explicitly Capture what is reimbursable, what is bundled, what is excluded, and how exceptions are handled. No generic notes, no tribal knowledge.
5. Reconcile a historical sample Run past claims through the model and compare expected payment to actual remit. Use mismatches to find missing rules, not to blame the payer immediately.
6. Route only actionable cases Send clean underpayments to follow-up and suppress noise that is not collectible.

That sequencing matters because teams often start with the easiest visualization and only later discover the data they needed was never captured. I would rather build a narrow but defensible model than a broad one that cannot explain itself under audit or in a payer dispute.

This is also where analytics and operations have to stop fighting each other. Revenue cycle leaders want visibility. Analysts want defensible logic. Billing teams want fewer false alarms. The only way all three agree is when the model mirrors the contract and the claim lifecycle closely enough that the output feels obvious when it is right.

When the work gets more sophisticated, we usually fold the same logic into systems that already touch claims and eligibility. That is where a platform like Medexa becomes relevant because the documentation, coding, and claim assembly layers all affect whether an underpayment is real or self-inflicted. If those upstream signals are clean, the underpayment model stops wasting time on preventable variance.

What I would measure first

• Contract coverage by active payer and service line.
• Percent of rules with named source clauses.
• Variance cases ranked by recoverable value, not just raw mismatch count.
• Time from remit posting to variance review.
• Share of flagged cases that turn out to be non-actionable.

I am skeptical of any underpayment program that starts by bragging about volume. Volume of flags is not value. The right measure is whether the team recovers money that was actually owed and can prove it without a three-hour internal debate. That only happens when contract truth, claim truth, and remit truth are modeled together.

At AST, we have seen the difference that discipline makes in real delivery work. In our own integrations, the painful part was never getting a report to run. It was getting the contract logic specific enough that operations could trust the case list and finance could stand behind the numbers. That is the line between analytics theater and revenue protection.

If you are still running underpayment review as a monthly cleanup exercise, you are leaving money in the cracks between your contract and your adjudication logic. Close that gap, and the work becomes smaller, faster, and far less political.