Where Revenue Leaks When You Hand Billing to a Vendor
Five revenue-cycle blind spots that left six figures unposted at a founder-led healthcare operator – and the infrastructure that made each one measurable.
$169K
in issued payments that could not post after a billing-platform handoff – with denials buried inside, appeal windows closing
Category
Teardown
Published
September 2026
Read Time
8 min read
Overview
You run a founder-led healthcare services company. Somewhere between three and twenty-five million in revenue. You dispatch clinicians or techs into the field, you bill Medicare and a dozen commercial payers, and at some point you make the decision every operator your size makes: you hand revenue-cycle management to a vendor. A billing company, or your practice-management platform's own RCM service, at two to three percent of collections. They promise a collection rate in the high nineties.
Here is what nobody tells you. A handoff is where the seams show. Not fraud, not incompetence – seams. Payments land where claims aren't. Denials hide in remittances no interface flags. The payer list is assembled from memory. And you have no baseline of your own, so when the vendor promises 98.7%, you have no way to know if that is good.
Below are five revenue-cycle blind spots we found and measured inside one founder-led healthcare operator during exactly this kind of handoff – and the infrastructure built for each one. The numbers are real, and where a result is still pending, we say so.
Blind Spot 1
(the 98.7% you cannot verify)
Blind Spot 1: You never baselined your own collection rate(the 98.7% you cannot verify)
The vendor promised a collection rate of about 98.7%, without saying net or gross. The operator's own trailing net collection was running 87 to 92%. That gap is not rounding. On an illustrative ten million in collections it is roughly seven to twelve points of cash a year, and the operator had no instrument to tell which number was true.
The reason is structural, not careless. A promised "98.7%" is unfalsifiable until the denominator is written down – net versus gross, per-claim versus per-check denials, forecast versus booked. This operator already owned more than seventy percent of the data a vendor KPI needs: 12 of the 16 requested metrics had live data paths. What is missing is recurrence (a snapshot nobody has to remember to run), pinned definitions, and a baseline dated before the handover.
Vendor promise: 98.7%. Actual trailing net collection: 87–92%. Instrument to tell the difference: none.
The Fix
A scorecard the client controls, computed from data the client already captures, with the baseline dated before handover. In one session we stood up eleven revenue-cycle KPIs on the operator's existing dashboard – A/R days, first-pass rejection, net collection against a written 0.987 target line – fed by a weekly PHI-free snapshot job so performance is measured against a pre-activation baseline from day one. First snapshot: $169,190 unposted across 434 remittances, 61.2 A/R days on $363K of A/R, 4.03% first-pass rejection. It also surfaced a payer rejecting 72% of its claims against 0.9% for Medicare – an outlier no one had seen. Vendor accountability starts before the vendor does.
Blind Spot 2
($169K stranded, and growing)
Blind Spot 2: After the migration, the payments can't post($169K stranded, and growing)
When billing moves platforms, remittances for the migrated payers start landing in the new system while the claims are still billed out of the old one. With no matching patient or visit on the new side, the payments have nowhere to post. At this operator: 434 unmatched remittances totaling $169,190, growing toward $215K over the following two weeks.
The money itself was not the urgent part – those payments were already issued and were not going anywhere. The urgent part was buried inside them: denials with appeal windows closing (see Blind Spot 4).
434 remittances, $169,190 issued and unpostable – because the payments arrived where the claims weren't.
The Fix
The recoverable path runs through the systems the client still controls – and the highest-value join key is often sitting in a neutral third party, not in either vendor's platform. Here the clearinghouse's claim ledger held all 29,000-plus claims-as-submitted, carrying the patient control number every payer echoes back on a remittance – a matching spine nobody had connected. We captured four self-service exports first, before access could be cut, then designed a bridge that matches remittances to source claims through that ledger, behind fail-closed guards that make claim submission structurally impossible rather than merely discouraged. Measuring changed the design: an assumed ID link between billing and clinical records had zero overlap, so patient name plus date of service became the real key, at about 98% match. The bridge cleared the billing platform's integration certification. Posting the backlog is still pending the vendor's approval. Quoted by the outgoing vendor for the same bridge: $10K. Paid to the vendor through self-service exports: $0.
Blind Spot 3
(~95 denials nobody could touch)
Blind Spot 3: The denials board is a report, not a worklist(~95 denials nobody could touch)
The operator's dashboard had a denials tab. It grouped denied claims by responsible party and aging bucket and showed dollars-at-risk per slice. It had been built privacy-first: every per-claim identifier was stripped at the server boundary. The unintended result – each row was anonymous. A biller could see "$420, Primary, Medicare, denied, 61–90 days" and had no way to know which claim that was. The board surfaced the problem and hid its handle. At last count it held roughly 95 denied claims no one could action from the screen.
Founder-led service companies are full of read-only boards that look like worklists. This one surfaced a number and withheld the one reference that would let someone do something about it.
95 denied claims on the board. Lookup keys per row to find the claim: zero.
The Fix
When an internal, authenticated tool needs to be actionable on regulated data, the right standard is minimum-necessary, not zero. Working a denial is a permitted use of patient data by the covered entity's own staff. We kept name and date of birth off the wire and exposed two lookup keys, the claim reference and the patient record number, each click-to-copy so the biller pastes it straight into the billing system. The endpoint was already role-gated. A test proves the patient name never crosses the boundary. Ninety-five unworkable denials became a worklist, and name and date of birth stayed at zero.
Blind Spot 4
(5 codes, not an infinite list)
Blind Spot 4: The denial filter you asked for cannot exist(5 codes, not an infinite list)
Inside those unmatched remittances were denials with closing appeal windows, and the platform's remittance console has no denial filter – nothing flags a remittance as a denial. The obvious build was a denial-detection tool. The obvious way to build it was to ask the billing specialist for the list of denial codes.
The list does not exist and cannot exist. Asked directly: "That's why I can't pinpoint a denial code – there's just so many. And some are new, some are not." A blocklist built from remembered examples silently drops every code no one named, and every code introduced afterward. A missed denial looks exactly like no denial – the failure is invisible.
Denial codes: unbounded, evolving, unknowable. Approval codes: five, closed, confirmed by the person who does the work.
The Fix
Invert the filter. The approval codes are a small, closed set – five, covering contractual adjustment, sequestration, deductible, coinsurance, and copay. Allowlist those five; surface everything else for review. A code nobody has seen before lands in the queue instead of vanishing – the failure direction is now toward too much review rather than silent loss. The design came out of one 35-minute conversation with the billing specialist, before a line of the tool was written: it also revealed that 80% of the payer surface was already being reconciled by hand, so v1 scoped to the single payer that wasn't. The cheapest revenue-cycle infrastructure is the interview you have before you build.
Blind Spot 5
(55 remembered vs 89 real)
Blind Spot 5: The payer list nobody has(55 remembered vs 89 real)
Mid-migration, the new workflow platform sent a standard onboarding template: list every insurance company you work with, one row each, no duplicates. No single system held that list. Payer knowledge was scattered across a legacy system being decommissioned, a departing biller's A/R exports, a clearinghouse claim history, a half-validated new billing platform, a second clearinghouse's enrollment list, and a hand-typed intake spreadsheet. The default path – someone types up the payers they can remember – freezes "payer not found" friction into the new system on day one.
Payers on the intake sheet: ~55. Payers the six sources held, deduplicated: 89.
The Fix
The fix is mechanical, not heroic. Enumerate every system that ever touched a payer, extract distinct values with volumes, let the curated-but-stale source supply the rich fields (addresses, IDs) while transaction history supplies completeness, and encode exclusions as explicit rules (a payer list is not a customer list). A deterministic script merged six sources into an 89-payer master and flagged seven data-quality issues along the way, among them one plan filed under three different electronic IDs and an enrollment gap on a federal plan. The onboarding template became the forcing function for a data-quality audit the business needed anyway.
The revenue-cycle handoff, measured
No collection-rate baseline
Vendor-promised 98.7% vs actual 87–92%; 11 KPIs now live against a written target
Stranded remittances
$169,190 across 434 payments, unpostable – bridge certified, posting pending vendor approval
Denials board with no handle
~95 denials unworkable, now a worklist; name and date of birth still withheld
A denial filter that can't exist
Allowlist 5 approval codes instead of an unbounded blocklist
No payer master
~55 on the intake sheet, 89 evidence-backed payers, 7 data-quality flags
Total surfaced
Six figures unposted or at risk, now visible and measured
The Pattern
These leaks share three properties:
Measure before you trust the vendor. The instinct is to wait for the new provider's reports. The leverage is a scorecard the client controls, computed from data the client already owns, with the baseline dated before handover. A promised number is unfalsifiable until you write down the denominator.
The recoverable path runs through the systems you still control. When a vendor transition breaks mid-flight, the highest-value join key is often in a neutral third party, not in either vendor's platform. Capture those self-service exports first – when access can be revoked on someone else's schedule, hoarding raw data is step zero, not an optimization.
A board that surfaces a problem but not its handle is a report, not a tool. Founder-led companies are full of read-only dashboards that look like worklists. Actionability on regulated data is minimum-necessary, not zero.
Build the failure toward too-much-review, never toward silent loss. You cannot enumerate what goes wrong; you can often enumerate what goes right. Allowlist the small closed set and surface the rest.
The cheapest infrastructure is the interview before the build. One 35-minute conversation with the person who does the work killed the obvious design and replaced it with a much smaller one.
Takeaway
None of these five gaps came from a careless team. The stranded remittances came from the handoff itself: a clearinghouse change rerouted remittances before the claims moved. The others were already there, or arrived with the new platform – a board built for privacy instead of work, a baseline nobody captured on a schedule, a console with no denial filter, a payer list that lived in memory. A handoff does not create most of these gaps. It exposes them, on someone else's schedule.
That is the whole argument for installing the measurement before you install the vendor. A founder-led healthcare operator does not need a bigger billing department. It needs a revenue cycle it can see – baselined before the handover, every remittance traceable to a claim, every denial workable. Infrastructure, not effort. That is what we install.
Brian Truax is the founder of Actional, an AI Systems Operator that installs operational infrastructure inside founder-led service companies. Based in Houston.
These patterns exist in your operation