I've spent the better part of my career untangling the invisible wiring that connects a health plan's promise to what actually happens when an employee swipes a pharmacy card. And I can tell you this: the rebate pass-through contract everyone's excited about? It's only half the battle. The other half is a silent, slow-motion collision with the technology that runs your benefits every day.
On paper, the deal sounds perfect. No spread. No hidden PBM margin. Every dollar of manufacturer rebate flows back to the plan. The next logical step-the one that finally gets benefits leaders leaning forward-is to push those rebate dollars all the way to the member at the point of sale. Imagine the employee picking up a prescription and paying a cost share based on the drug's net price, not the inflated list price. That vision is real, and a handful of transparent PBMs can actually deliver it. But here's the catch: most benefits administration systems, enrollment portals, and even the claims adjudication engines we've relied on for years were never designed for a world where drug prices are dynamic and rebates materialize in real time.
Before you shake hands on that shiny new contract, let's walk through the three places your own infrastructure will fight you-and what to do about it.
The Adjudication Engine Doesn't Know What "Net Price" Means
In a traditional setup, the claim zips through the PBM's system, the drug gets looked up on a formulary, and the member's cost share is calculated off the list price. A copay is a static number; coinsurance is a percentage of AWP. The rebate, if there is one, materializes months later as a check to the employer. Clean. Simple. Backward.
Now try applying a rebate at the counter. That means the adjudication engine has to pause and calculate a net price on the fly. But manufacturer rebates aren't neat, flat amounts. They're often a percentage of list price that varies with volume tiers, formulary positioning, or market share targets that might not even be finalized until the quarter ends. At 10:07 a.m. when your employee is standing at the pharmacy, the best the system can do is an estimate. So now you need a real-time rebate engine that can look up the drug, guess the net cost, recalculate the member's cost share, and then handle the inevitable true-up when the actual rebate comes in three months later. Most legacy PBM platforms and third-party benefits admin tools I've poked around inside simply aren't wired for this. Their plan design schema expects you to type in "Tier 3: $40 copay" or "20% coinsurance after deductible." It can't process "20% of whatever the net price happens to be this Tuesday."
That's not a contract problem. That's an architecture problem. And unless you ask the right questions during the RFP, you won't discover it until the first wave of claims misfires.
The HSA Hairball Your Claims Accumulator Will Untie Incorrectly
If you're running a high-deductible health plan paired with an HSA, the stakes go from messy to legally troubling. An HDHP can't cover first-dollar benefits before the deductible without losing its qualified status. So when a point-of-sale rebate reduces the member's out-of-pocket cost, the plan has to be careful not to let that reduction erode the amount counting toward the deductible. The IRS gave us a path forward with the copay card safe harbor-the idea that we can apply the full unreduced cost share to the deductible while the member only pays the smaller, net-price amount. That works, but it demands a very specific accumulator logic inside the claims system.
I've seen employers who assumed their PBM had this covered, only to find out six months later that the plan was silently disqualifying itself as an HDHP because the accumulator recorded the lower, post-rebate cost share against the deductible. The member paid $25 but only $25 went toward their out-of-pocket limit, instead of the $40 that should have counted. That's not just a member experience issue; it's a compliance event waiting to happen. And when you layer on the fact that many PBMs now run accumulator adjustment programs that specifically strip out copay card dollars, the system risks confusing your plan-sponsored rebate with a third-party coupon, zeroing out deductible progress entirely unless someone meticulously configures a "source of reduction" flag in the guts of the adjudication code.
The Member Portal Is Showing Yesterday's Prices
Even if you somehow solve the claims and compliance puzzles, there's one more quiet failure point: the decision-support tools your employees use during open enrollment. When someone logs in to compare the HDHP against the PPO, the pharmacy cost estimator is almost certainly pulling static, list-price-based numbers from a file that got loaded once at the start of the year. It has no clue that a particular drug will actually cost them $12 instead of $40 because a rebate will be applied in real time. So the plan that saves them the most money ends up looking more expensive on the screen, and they pick the wrong plan. All your hard-won financial engineering evaporates at the pixel level.
Fixing this requires your PBM to feed real-time net pricing into your benefits enrollment platform, either through an API or a dynamic formulary file that gets refreshed far more often than once a year. A few forward-leaning platforms can do this. Most can't without a custom build. And if your benefits admin vendor shrugs and says "we show what the PBM gives us," you've just become the project manager for an integration nobody budgeted for.
Turn Your RFP Into a Stress Test
So here's where I land: stop treating "rebate pass-through" as a procurement checkbox. Add a new evaluation criterion I call operational pass-through. Demand a live demonstration that walks through the entire lifecycle of a rebate-adjusted claim. And pin the vendor down on these five questions:
- Point-of-sale reality: Will the rebate be applied at the counter, or will it stay a retroactive credit? If at the counter, is the net price an estimate or a guarantee? How do you handle reconciliation differences-especially if a member ends up being owed money or needs to be billed six months later?
- HDHP/HSA compatibility: Show me the exact accumulator logic that applies the full unreduced cost share to the deductible and out-of-pocket maximum, consistent with the copay card safe harbor. Don't just say "we handle it"; walk me through the claim line item by line item.
- Accumulator interaction: How does your system distinguish a plan-sponsored rebate reduction from a manufacturer copay card? Demonstrate that a member's deductible progress won't be accidentally stripped out by your accumulator adjustment program.
- Benefits admin integration: Can you deliver a real-time API or a standard file format that our enrollment platform can consume, so members see accurate net-cost drug estimates during plan selection? How will the EOB and member portal clearly show that a rebate reduced their out-of-pocket amount?
- Reconciliation and auditability: Will you report estimated versus actual rebates at the individual claim level so we can audit for compliance and avoid sending confusing true-up letters to our people?
For many plan sponsors, the pragmatic short move is to let the PBM's own member portal be the primary place where employees see their drug costs, bypassing the legacy benefits admin system for pharmacy display. It's not the unified, all-in-one experience we all want, but it's a bridge while the enrollment platforms catch up.
The industry is slowly waking up to the idea that prescription drug rebates should actually feel like a member benefit, not just a vague downward pressure on next year's premiums. But that future won't be delivered by contract language alone. It will arrive when we stop treating our benefits technology as a quiet record-keeper and start demanding it handle the dynamic, real-time data that true fiduciary responsibility requires. Until then, you might have a beautifully negotiated pass-through deal-and a system that can't keep the promise.