October 13, 2026

Article Summary: Skyler Young, Vice President of Data Mining and Technology at Penstock, argues that faster AI-assisted pre-payment review does not reduce a health plan’s need for post-payment auditing. Pre-pay enforces the rules a plan already has, inside contractual and regulatory turnaround windows. Post-payment claims analysis is where new overpayment concepts originate, and where plans find out whether existing controls worked, including cases where authorization and validation requirements were in place and claims paid anyway.
"Move it upstream" isn’t a new idea in payment integrity. Health plans have wanted to prevent overpayments rather than chase them for as long as there have been overpayments to chase. What's new is that it finally sounds achievable. AI has made real-time review fast enough to handle more at the moment of payment, which makes an old wish look practical. So, it's being sold as the next stage of maturity: fix the claim before it's submitted and judge the program by how little recovery work is left.
Faster review is real progress. But speed isn’t the real constraint. Knowing what to look for is, and that knowledge doesn't come from better tools at the front end. It comes from claims that already paid.
Why Prevention in Payment Integrity Starts With Post-Pay
Every plan that has said "we could have prevented that one" is describing the same sequence. A claim paid. Somebody audited it. The finding traced back to a documentation requirement that was never clearly stated, an authorization workflow that didn't connect to the payment decision, or a contract term the adjudication logic read differently than the contract manager did. Only then was it obvious that a clearer requirement up front would have stopped it.
That's not an argument for doing less post-pay. That's post-pay working. You can't write the rule until you understand the pattern, and you don't understand the pattern until you've watched it play out in paid claims.
Provider Abrasion Is a Quality Problem, Not a Timing Problem
None of this defends how post-pay is often practiced. Reviews run by people who don't understand the contract they're auditing against, findings on timelines nobody defended, vendors touching the same account with no coordination. Those complaints are earned. But notice what's wrong in each case. The problem isn't that the review happened after payment. It's that it was shallow, undefended, or uncoordinated. Moving that work earlier doesn’t fix that.
Pre-Pay Executes What You Know. Post-Pay Finds What You Don't.
Pre-pay is built for consistency and control. Once a pattern is defined, a duplicate, a procedure-to-diagnosis mismatch, a carve-out that shouldn't have applied, pre-pay enforces it across millions of claims without fatigue. That's the right home for anything you already understand.
But pre-pay only acts on the rules it's been given, inside a window shaped by contractual and regulatory turnaround clocks. When the data, logic, and connection to the final payment decision don't line up in time, the claim pays anyway.
Better models raise the ceiling on both sides of this. They make pre-pay faster at applying what a plan already knows, and post-pay far more powerful at finding what it doesn't. What they don't change is where new knowledge comes from: a model surfaces patterns present in the data you point it at, and the data showing how a claim actually resolved is paid claims data.
In one recent analysis of a high-volume Medicaid service category, every control you'd want was in place: authorization requirements, state-supported validation, system indicators confirming that services matched what was approved and delivered. On paper, buttoned up. Then one market's payment volume looked nothing like the others. The service was billed in small, time-based units, so nothing looked dramatic at the claim level, but across thousands of claims the exposure was real, and some appeared to show mismatches tied to the validation process while still paying.
The control existed. Paid claims suggested it wasn't working the way the plan believed. The plan wasn't missing a rule. It was missing proof that its rules were holding. It's why CMS still reports tens of billions in improper payments annually despite decades of front-end investment.
How Post-Pay Audits Become R&D for Payment Accuracy
The most useful way to think about post-pay isn't as a collections department. It's as research and development for payment accuracy. A strong program doesn't stop at here's what was overpaid. It asks why the claim paid at all. Did the control fail, or was it never designed for this scenario? Is this a one-off, or a pattern for a pre-pay edit?
That's the loop. It matters because billing patterns, provider behavior, state requirements, and adjudication configurations keep moving. What your edits caught last year isn't what's happening now, and no amount of processing speed fixes an edit nobody knew to write.
A Better Measure of Payment Integrity Maturity
Prevention isn't a destination you reach by relocating work earlier. It's the output of a feedback loop, and the loop only turns if something feeds it. A strong payment integrity program does four things:
- Audits against the actual contract. Findings that hold up don't generate the appeal cycles that make payment integrity feel adversarial between health plans and providers.
- Defines scopes and stages. Multiple vendors on one account isn't a reason to consolidate. It's a reason to assign specific domains to specific teams with defined timelines.
- Routes by complexity. Routine issues belong in a pre-pay edit. Data mining, contract interpretation, and pattern discovery belong with people who do that work specifically.
- Closes the loop on every finding. A recovery that doesn't change an edit or a policy is one you'll make again next year, same provider, same reason.
For a health plan CFO, the question isn't whether controls exist. Almost every plan has them. The better question is whether paid claims prove those controls are working, and whether anyone is still looking.


