The Revenue You Already Earned (and Never Collected)

June 2026 · Healthcare

Here's an uncomfortable thought experiment for any revenue cycle leader. When a payer underpays a claim — pays it, just at less than the contracted rate — what in your current process catches it? A denial generates a reason code, a letter, a work-queue item; someone is assigned to it. A silent underpayment generates none of that. The claim posts as paid. The remittance looks clean. The dashboard shows the encounter closed. The only way to know you were shorted is to compare what was actually paid against what the contract says should have been paid, line by line, across every payer agreement you hold.

Nobody does that by hand, because nobody can. A mid-sized system processes millions of service lines a year against dozens of contracts, each with its own fee schedule, amendments, and quirks. Which is exactly why systematic underpayments persist — and why the organizations that have built contract-aware detection treat it as one of the higher-return projects in the revenue cycle. The money was earned. It was even paid, sort of. It just wasn't paid in full, and nothing in the workflow was looking.

A data engineering problem wearing a billing costume

Underpayment recovery is the most data-engineering-shaped opportunity in the revenue cycle, and naming it that way is the first step to doing it well. The "AI" here is not a chatbot. It's two unglamorous capabilities pointed at each other: document extraction on the contract side, and variance detection on the payment side.

The payment side starts with the 835 electronic remittance. The standard is consistent in spec and maddeningly inconsistent in practice — every payer has its own formatting habits, companion-guide rules, and delimiters — so the real work is normalizing all of it into a single internal schema, then matching each remittance back to the originating claim through the patient and payer control numbers, service dates, and the claim- and service-level segments that carry the adjustment reasons. The contract side means digitizing messy, amendment-riddled payer agreements and fee schedules into machine-readable expected-rate logic at the level reimbursement actually varies: the procedure code, the modifier, the site of service. Then you difference the two — expected versus actual — continuously, and route the gaps to a recovery worklist with the contract language and the remittance detail already attached.

That's the whole engine. It is plumbing, and the value lives in how well the plumbing is built, not in any conversational layer on top. A leader who understands that buys the right thing; a leader who's been sold a "revenue AI assistant" usually doesn't.

Why it's invisible, and how big it gets

The defining feature of an underpayment is that it throws no error. A denial is loud; an underpayment is silent by construction. When a payer quietly revises a proprietary fee schedule, you often don't find out until a variance report flags the drift — if you have one. Until then, every claim under that schedule pays a little light, and the encounters all show as resolved.

Per claim, the shortfall is usually small — by various estimates a few percent of billed line items come in under contract, often by a few tens of dollars each. That smallness is precisely why it survives: no individual gap is worth a human chasing. But multiplied across hundreds of thousands of lines and dozens of payers, the aggregate is material. Revenue integrity sources commonly put underpayment leakage in the range of 1–3% of net patient revenue, with higher estimates at the extremes. On a system doing hundreds of millions in net revenue, even the low end of that range is real money disappearing without a trace, year after year. And it compounds in the worst way — a silent rate change that nobody catches keeps underpaying every applicable claim until someone notices.

Make it concrete. Suppose a payer quietly trims its allowed amount on a common imaging code by twelve dollars, and you run that code four thousand times a year under that contract. That's $48,000 — on a single code, with a single payer — that no human will ever flag, because every one of those claims posts as paid and closed. Now multiply by the hundreds of codes and dozens of contracts a real organization carries. The leak isn't one big hole you'd trip over; it's ten thousand pinholes, each individually too small to chase by hand. That's exactly the shape of problem software is good at and people are not.

The asymmetry you're up against

It helps to understand why this leak is so durable: the two sides of the transaction are not equally equipped. Payers have invested heavily in payment integrity — it's common for a large payer to run several specialized payment-integrity vendors at once, each looking for reasons a claim should be paid less, paid later, or not at all. That's a sophisticated, well-funded analytical operation pointed squarely at your reimbursement. Providers, historically, have had nothing symmetric pointed back. The result is an information asymmetry as lopsided as any in the revenue cycle: one side knows precisely how every claim was adjudicated against its own rules, and the other side mostly knows whether a check showed up.

Closing that gap is the real point of underpayment detection. It isn't adversarialism for its own sake — it's being able to hold a payer to the contract you both signed, with evidence, the same way the payer holds you to its policies. Capital is flowing in exactly this direction; investors have been funding provider-side payer-intelligence platforms precisely because the asymmetry is so large and the tooling to close it is finally mature. For a mid-market organization that can't staff a payment-integrity department of its own, a well-built detection pipeline is how you get the analytical firepower of a much larger system without the headcount — which is, not coincidentally, the same argument that makes most worthwhile mid-market AI projects worth doing.

Why it pairs with denials work

Denials management and underpayment recovery are two halves of a single revenue-leakage program, and they share most of their infrastructure. Both depend on clean remittance ingestion. Both produce dollar-denominated dashboards a CFO can read. Both make their business case from your own historical data rather than a vendor's projection. The practical implication is sequencing: once you've built the 835 normalization and the reporting layer for denials, underpayment detection is largely an incremental addition — you're already ingesting the data; you're adding the contract comparison on top.

That's why I usually recommend treating them as one initiative with two outputs rather than two competing projects fighting for budget. The denials side gets attention because it's visible and painful; the underpayment side is where a surprising amount of the quiet money turns out to be. Build the pipe once, and you catch both the loud leaks and the silent ones.

Part of a bigger leak

Underpayments are one of three leaks that share a cause and a cure. Alongside them sit denials — the loud, coded losses that at least announce themselves — and the quietest category of all: missed charges and undercoding, services that were delivered but never billed, or billed at a lower level than the documentation would support. Organizations without a formal revenue-integrity discipline commonly lose somewhere in the range of 3–8% of net collectible revenue across all three combined. Treating them as one program rather than three competing projects is both cheaper and more effective, because they run on the same rails: remittance ingestion, charge and claim data, contract terms, and a reporting layer that speaks in dollars.

The strategic framing for a CFO is that you're not buying three point solutions; you're building one revenue-integrity capability that happens to plug three different leaks. And the timing favors it. U.S. health spending has crossed $5 trillion, hospitals are its single largest category, and consolidation keeps stacking more contracts and more payer complexity onto the same finance teams. Every merger adds fee schedules to reconcile and amendments to track; every year of "we'll get to revenue integrity eventually" is another year of pinholes compounding. The organizations that build the capability now are the ones that will walk into the next wave of contracts already knowing, to the dollar, what they're owed.

The leverage you didn't know you had

There's a second payoff that doesn't show up in the recovery total, and it may matter more over time. Once you can quantify variance by payer, by procedure code, and by month, you change your posture at contract renegotiation. Today, most provider organizations walk into a renewal with anecdotes and a general sense that one payer is harder to collect from than another. Imagine instead arriving with the actual numbers: this payer underpaid these codes by this dollar amount over the last twelve months, here's the adjudication timeliness against the contractual service levels, here's how their effective rates compare to your other agreements.

That shift — from episodic, impression-driven negotiation to continuous, evidence-grounded negotiation — is becoming the norm among sophisticated revenue cycle teams, and it's a durable advantage. The same data set that recovers yesterday's underpayments quietly improves tomorrow's contract terms. You stop arguing from suspicion and start arguing from your own ledger.

Keep it honest

A word of discipline, because this space attracts inflated claims. The vendor case studies promising tens of millions recovered are real engagements, but they're self-reported, drawn from large systems, and chosen to impress. Don't build your business case on someone else's headline. Build it on a retrospective audit of your own data: take twelve months of remittances against your top five payer contracts and run the comparison. The findings — whatever they are — fund and right-size everything that follows.

If the audit comes back clean, you've bought genuine assurance, and that's worth knowing too. In my experience it rarely comes back clean, because the conditions that create silent underpayments — proprietary fee schedules, frequent amendments, and a workflow with no detector pointed at them — are nearly universal. Either way, you've spent a contained amount to replace a guess with a number.

This program is judged in recovered dollars, not saved hours, which is exactly why it tends to survive the budget scrutiny that kills vaguer AI initiatives. It's also why it's a good fit for an organization that's skeptical of AI hype: there's no model making a clinical or coverage judgment, no black box to defend to compliance — just a careful comparison of what you were owed against what you were paid, run continuously, on data you already have. The revenue is already yours. The work is going and getting it.