If you run finance for a health system, you've probably built a "Medicare revenue" number you were confident in — and then watched it disagree with itself six months later. No one made an error. Two perfectly reasonable ways of measuring the same thing were quietly capturing different outcomes.
Here's why that should get your attention: the same gap that muddies your internal reporting is one of the first things a lender's diligence team finds when they look at your receivables; and when they can't tell who's actually paying a claim, they don't guess in your favor. They discount it. Real Medicare-derived cash flow gets priced as low-confidence commercial revenue, and you borrow against less than you actually have.
It's one of the most common, and most under-diagnosed, data problems we see in a provider's receivables book. It has nothing to do with sloppy accounting. It's structural, it's specific to Medicare Advantage, and once you know what to look for, it's a five-minute check.
The number that didn't reconcile
Picture a health system whose billing system reports Medicare at roughly 16% of claim volume. Pull the same period from the remittance side — what actually got paid, and under what payer code — and the story changes: some of that "Medicare" volume paid at rates and terms that look nothing like Medicare, and a chunk of clearly Medicare-adjacent revenue never appears under a Medicare code at all. Counted properly, the true Medicare-derived share was materially higher than the billing system's 16%; several points of real Medicare cash flow that had been sitting in the commercial bucket.
Nobody mis-keyed anything. The two sides of the revenue cycle are answering two different questions, and Medicare Advantage is exactly where the questions diverge.
The mechanics: two codes that are supposed to agree, and don't
Every claim has two lives in the data. On the way out, the 837 claim submission carries a payer-type field (SBR09) that says who the biller thinks they're billing. On the way back, the 835 remittance carries its own payer code (CLP06) that says who actually adjudicated and paid.
For Traditional Medicare, these two fields tell the same story, every time. For Medicare Advantage, they frequently don't. An MA plan is often filed under a commercial or managed-care payer type — because that's how the biller's system is configured, or how the clearinghouse maps it — while the remittance comes back stamped with a Medicare code, or the reverse. Same claim, same plan, two classifications depending on which half of the transaction you're looking at. Build your "Medicare %" off the claim side alone, and MA volume that pays under a Medicare code gets bucketed as commercial. Build it off the remittance side alone, and you get a different, equally partial picture. Neither is wrong. Neither is complete on its own.
And the plan name won't save you. The obvious instinct is to just check the payer name: surely "Medicare Advantage" plans say so somewhere. They usually don't, in any way a billing system can act on. MA products are routinely branded to sound like Medicare — names built around "Medicare Advantage," "Medicare Assure," "Medicare Value" — while running through ordinary commercial adjudication codes on the back end. A name match is worth running once as a sanity check; it will confirm the wrong classification about as often as the right one. It is not a substitute for code-based classification, and treating it as one just moves the error somewhere harder to spot.
The failure mode that's worse than misclassification
There's a second-order version of this that does more damage than a claim landing in the wrong bucket: a claim and its own remittance landing under two names that never link up in your reporting at all.
This shows up most with dual-eligible and special-needs products, where the claim-side brand is product-specific ("[Plan] Dual Complete," a MyCare- or DSNP-style label) but the remittance comes back under the payer's generic plan name. The billed volume is real. The paid volume is real. But if your reporting joins on payer name rather than payer code, the two never meet — and the revenue looks like it evaporated, when it just changed names between the front and back of the cycle.
What this actually costs you
In front of a lender, an auditor, or your own board, this isn't a rounding error:
- Understated collateral value. Real Medicare-derived cash flow gets bucketed as low-confidence commercial and discounted accordingly in your borrowing base.
- Distorted yield and denial metrics. MA claims misclassified as commercial drag down or inflate figures that are supposed to represent Medicare performance specifically.
- An unclear payer of record — a lender's actual nightmare. A secured lender isn't pricing an average recovery rate; it's underwriting the enforceability of a claim against a specific obligor, on specific terms and priority. When a receivable's claim-side and remit-side identities disagree, the lender can no longer say with confidence which payer relationship — and which contractual terms — govern that dollar. Not because you don't know who's paying, but because your data can't demonstrate it cleanly. Underwriters treat that ambiguity the way they treat any collateral they can't verify: they discount it, exclude it from the eligible base, or price the whole facility more conservatively.
- A credibility problem, not just a numbers problem. If a lender's diligence team finds this before you disclose it, the conversation shifts from "here's our receivables story" to "why didn't you catch this."
The five-minute check
If you own the data, you can find this today. You don't need a project — you need one query:
- Pull two fields for the same period: the claim-side payer type (SBR09 on the 837) and the remit-side payer code (CLP06 on the 835), joined at the claim level.
- Flag every claim where the two disagree: especially anything filed commercial that paid under a Medicare code, or the reverse.
- Separately, join your claim-side and remit-side volume on payer name and look for billed volume with no matching remit, or vice versa. That's your dual-eligible / SNP name-mismatch leakage.
- Total both. The dollars in those two buckets are the size of your reconciliation gap — and roughly the amount a careful lender is currently discounting or excluding.
If that number is bigger than you're comfortable defending in a diligence meeting, it's worth fixing before someone else finds it.
What to do about it, for good
- Classify by remittance code, not claim code, when the question is "how much did Medicare pay." The 835 is the ground truth for what happened financially; the 837 is a statement of intent.
- Build a payer-name-to-code crosswalk — and re-audit it. New MA products, rebrands, and plan consolidations break these mappings quietly and often. Don't assume it's static.
- Ask which side of the cycle any "Medicare %" figure comes from before you repeat it. If your team can't answer in one sentence, the number isn't ready to go in front of a lender.
- Reconcile claim-side and remit-side volume as its own step — not as an afterthought once the two disagree.
A receivables book where every dollar traces to one unambiguous payer of record is the difference between a lender pricing your facility and a lender walking away from it. Everything above is how you get there.
*This is exactly the reconciliation gap our diligence process is built to surface early — before it becomes a cash flow surprise. If you're preparing a receivables book for financing, or you just ran the five-minute check and didn't like the number — we'll give the book a second set of eyes and show you how it holds up before an underwriter does.*