These aren't all the engagements, and they aren't all the kinds of problems this work surfaces. They're a cross-section: payor underpayments, transmission errors, mapping gaps, charge-capture failures, routing misconfigurations, eligibility drift, stale coverage edits, NCCI bundling. The specific failure mode varies. The pattern doesn't: revenue leaking through a layer of the system that nobody is currently watching.
Most revenue problems in labs and healthcare organizations don't announce themselves. They hide inside reporting logic, transmission errors, and system mismatches that billing teams weren't designed to catch. The cases below share a common thread: none of them showed up on standard reports, none of them were on anyone's radar, and all of them were fixed permanently — not patched, not worked around.
$500,000 in Underpayments Completely Invisible in Standard Reports
The Situation
A single payor had been systematically underpaying claims for months. Nothing flagged it. The claims had remits posted, no active errors, and appeared resolved in every operational report the billing team relied on.
The Problem
The billing system was configured to auto-clear a specific denial code (CO16) upon remit posting, a reasonable setting designed to prevent duplicate work. However, this payor was posting CO16 denials without the required remark codes, which meant the system cleared the error, posted a $0 payment, and moved on. The unpaid claims had activity (so they didn't appear on the “no activity” report) and no active errors (so they didn't appear on the error report). They sat in a blind spot that no standard report was designed to catch.
How It Was Found
Built a custom three-condition filter: paid amount = $0.00, no active errors in the error log, and a payment date present (confirming a remit had been posted). That combination — remit posted, errors cleared, nothing paid — identified the exact population of invisible unpaid claims.
The Fix
- Presented findings with a full Excel pivot showing the affected claim population
- Partnered with the vendor to automate resubmission on all impacted claims
- Modified system configuration so CO16 no longer auto-clears without a corresponding remark code for impacted payors
- Added the custom report to the standard monthly audit suite
The Result
$500,000 recovered within 90 days. System logic updated to prevent recurrence.
What This Means For Your Lab
If your billing system uses auto-clearing logic on denial codes, there's a chance unpaid claims are sitting in a similar blind spot right now. Standard reports won't show them. That's exactly the kind of thing a Revenue Recovery Audit is designed to find.
100,000+ Patient Accounts Wrongly Marked Uncollectible From One Mapping Error
The Situation
Patient accounts were being flagged as “bad address / uncollectible” even though the address information existed correctly in the lab information system (LIS). Patients weren't receiving bills. Balances were being written off. No one had connected the dots between what the LIS held and what the billing system was seeing.
The Problem
A transmission mapping error between the LIS and billing system was dropping the second address line (apartment, unit, suite) during the HL7-style handoff. Any patient with a multi-line address arrived in the billing system with an incomplete address — triggering the “bad address” flag and removing the account from active collections.
How It Was Found
Exported patient address data from both systems. Compared fields row-by-row in Excel using concatenated address strings (street + city + zip). The pattern was immediate: every affected patient had a second address line in the LIS that was missing in the billing system. Traced to a single excluded field in the transmission mapping: address_line_2.
The Fix
- Built a bulk reconciliation file in Excel formatted for direct upload to the billing system — correcting all affected accounts without manual entry
- Worked with IT to correct the LIS transmission logic permanently going forward
- Coordinated with operations to prioritize correction of the oldest unbilled accounts first
The Result
100,000+ patient accounts moved from “uncollectible” to active billing follow-up. Permanent fix implemented. The mapping error no longer occurs.
What This Means For Your Lab
Mapping errors between LIS and billing systems are more common than most labs realize — and they're almost never visible in standard reporting. If your write-off rates have been climbing or your “bad address” flags seem high, the root cause may be in the transmission, not the data.
200,000+ Claims Rejected Due to a Hidden Formatting Error in HL7 Transmission
The Situation
Claims were being rejected at unusually high rates across multiple clients. The rejections looked like normal denials; nothing pointed to a systemic cause. The issue had persisted for several months before anyone asked why.
The Problem
One EMR vendor's HL7 configuration was stripping decimal points from diagnosis codes during transmission. Codes like E11.65 were arriving as E1165, invalid codes that payors rejected on receipt. Because the rejections appeared as standard denials, they were being worked individually by billing staff with no one recognizing the pattern.
How It Was Found
Sampled rejected claims and traced them back to their source EMRs. Compared raw HL7 outputs from three different EMR vendors against the billing system's final claim files. Isolated the problem to one specific vendor and one specific HL7 segment version. Quantified impact using Excel pivot tables by EMR, week, and diagnosis code format.
The Fix
- Worked with IT at the affected EMR to correct HL7 transmission logic for future claims
- Partnered with the vendor to identify already-submitted claims needing correction
- Coordinated with operations to resubmit corrected claims in a manageable workflow
- Documented a remediation plan for similar HL7 issues in the future
The Result
Future claims from that EMR now transmit with correct diagnosis code formatting. Clean claim rate improved approximately 10%. 200,000+ affected claims identified and remediated.
What This Means For Your Lab
If you work with multiple EMR vendors or ordering systems, each one is a potential point of transmission failure, and HL7 errors rarely look like HL7 errors from the billing side. They look like denials. A systematic review of rejection patterns by source can surface these issues before they compound.
Thousands of Patients Incorrectly Billed Because Hundreds of Facilities Identified the Same Insurers Differently
The Situation
A national laboratory worked with hundreds of ordering facilities — urgent care clinics and physician offices across the country — each using their own EMR system. More than a dozen different EMR platforms were sending orders into a single lab information system, which then transmitted claims to one central billing platform. On the surface, the workflow appeared functional. Orders were coming in. Claims were going out. Yet thousands of patients were receiving bills for balances their insurance should have covered, and the billing team was fielding a growing volume of confused, frustrated patient calls.
The Problem
Every EMR system identifies insurance payors differently. A single insurance company might have a different HL7 payor code in each of the dozen-plus EMR systems sending orders to the lab. Some of those codes mapped correctly into the billing platform. Others didn't map at all, or mapped to the wrong payor entirely. When a payor code didn't translate correctly through the LIS to the billing platform, the patient's insurance never made it into the claim. The claim either went out without insurance, generating a patient bill for a balance that should have gone to the insurer, or it went to the wrong payor entirely, resulting in a denial and again leaving the patient responsible for a balance they didn't owe. With hundreds of ordering facilities and more than a dozen EMR systems all using their own payor identification logic, the number of mapping gaps was substantial and invisible to standard reporting, because each individual system appeared to be functioning correctly on its own.
How It Was Found
The problem required looking across systems simultaneously rather than inside any one of them. Patient accounts with unexpected balances were traced back through the billing platform to the LIS transmission, then back further to the originating EMR and ordering facility. The pattern that emerged: the same insurance company carried different HL7 codes depending on which EMR sent the order. A systematic audit of payor codes across all ordering sources cross-referenced against the billing platform's payor list identified every instance where an incoming HL7 code either didn't exist in the billing platform's mapping table or mapped to the wrong payor.
The Fix
- Built a comprehensive payor mapping reconciliation across all ordering sources, documenting every HL7 payor code in use across every EMR and verifying its correct translation into the billing platform
- Added missing mappings, corrected wrong ones, and aligned every variation of the same insurer across EMRs to the correct billing platform payor
- Worked with the technical team to implement the corrected mapping logic at the LIS level so all future transmissions from every ordering facility route correctly
The Result
Thousands of patient accounts that had been incorrectly billed were identified and corrected. Patients whose insurance hadn't transmitted correctly stopped receiving erroneous statements. Claims that had been going to the wrong payor, or going out without insurance entirely, began routing correctly. The fix was permanent: the corrected mapping logic applied to all future orders from all ordering facilities, regardless of which EMR system they used.
What This Means For Your Lab
Any lab that receives orders from multiple ordering facilities, especially facilities using different EMR systems, is exposed to this exact risk. The more ordering sources you have, the more payor codes are in play, and the more opportunities exist for a mapping gap to send a patient a bill they don't owe or route a claim to the wrong insurer. This is especially common after acquisitions or expansions, when new ordering facilities are onboarded quickly without a systematic audit of how their EMR identifies payors relative to your billing platform.
New Test Codes Generating Orders But No Claims Because They Were Never Linked to a CPT
The Situation
A lab launched several new assays. Orders flowed in from ordering facilities, results were resulted on time, and operations considered the launch successful. Volume on the new tests climbed steadily. The billing impact, however, never showed up in revenue.
The Problem
The new test codes existed in the LIS and the lab could order, perform, and result them, but in the billing system, they had no corresponding CPT mapping. With no billable code attached, the orders never produced a claim. They didn't reject. They didn't error. They simply never reached the billing queue, because as far as the billing system was concerned there was nothing to bill.
How It Was Found
Compared resulted-test volume in the LIS against claim volume in the billing system, broken out by test code. Several test codes appeared in the LIS with substantial volume and zero corresponding claims. Tracing those codes through the system revealed that none of them had been added to the billing system's test-to-CPT mapping table when the assays went live.
The Fix
- Built the missing CPT mappings for every affected test code, with payor-specific rules where required
- Identified every historical resulted order missing a claim and pushed eligible volume back through billing within timely filing windows
- Added a recurring reconciliation report that compares resulted tests in the LIS against billed claims by test code, so any future gap surfaces in days rather than months
The Result
Months of unbilled volume on the new assays were recovered where timely filing allowed. Going forward, every new test code goes live with a verified CPT mapping and appears in the reconciliation report on day one.
What This Means For Your Lab
Any time a lab adds a new assay, splits a panel, retires an old code, or onboards orders from a new EMR, there's an opportunity for orders to outrun the billing system's mapping. If volume in operations is climbing but the corresponding revenue line isn't, the gap is rarely in collections; it's usually in charge capture.
Claims Routed Through the Wrong Submission Service for Months
The Situation
A subset of payors had been quietly underperforming for months. Clean claim rate looked fine in the billing system. Submissions were going out on schedule. Yet payments from those payors had slowed, and follow-up calls kept ending in “we have no record of that claim.”
The Problem
A configuration change, made during a routine clearinghouse update. had redirected a subset of payors through the wrong submission path. Claims left the billing system marked as submitted, but the receiving clearinghouse rejected them at the gateway with errors that never made it back into the billing system as denials. From inside the billing system, those claims looked submitted and active. From the payor's perspective, they had never arrived.
How It Was Found
Pulled raw 277CA acknowledgments and clearinghouse-level rejection reports and compared them against the billing system's submitted-claims log. The mismatch was immediate: a defined slice of payors had hundreds of claims marked submitted internally with no corresponding accepted record at the clearinghouse. Cross-referencing those claims against the routing configuration isolated the misrouted payor group.
The Fix
- Corrected the submission routing for every affected payor at the clearinghouse configuration level
- Identified the full population of claims silently rejected at the gateway and resubmitted those still inside timely filing
- Added clearinghouse-level acknowledgment reconciliation to the standard monthly audit, so submitted ≠ accepted gaps surface as part of routine monitoring
The Result
Reimbursement from the affected payor group returned to expected levels within one cycle. The misrouted claims that were still inside timely filing were paid. The gateway-level rejections that had been invisible in the billing system are now part of standard reporting.
What This Means For Your Lab
“Submitted” inside a billing system isn't the same as “accepted” at the clearinghouse, and isn't the same as “received” by the payor. Any time a routing change, clearinghouse switch, or payor enrollment change happens, claims can quietly fail at a layer the billing system never sees. Acknowledgment-level reconciliation is the only way to catch it.
Eligibility Returning the Wrong Plan, and Nobody Saw It Until Patients Called
The Situation
Patient calls were climbing; patients were receiving statements for balances they believed their insurance should have covered. Operationally, eligibility was being checked at order entry. The billing system had insurance information on file. On paper, nothing looked broken.
The Problem
The real-time eligibility integration was selecting the wrong plan when patients had multiple active coverages, defaulting to the most recently returned response rather than evaluating coordination of benefits. Claims were being submitted to the wrong primary, getting denied or paid as secondary, and the resulting balance was shifting to the patient. The eligibility check itself “succeeded.” It just succeeded on the wrong plan.
How It Was Found
Sampled patient accounts with unexpected balances and compared the plan billed in the claim against the patient's actual coverage at date of service, payor by payor. The pattern was consistent: patients with two or more active plans were being billed under the plan that came back last in the eligibility response, regardless of which one was actually primary.
The Fix
- Reworked the eligibility selection logic to evaluate coordination of benefits rather than defaulting to the most recent response
- Identified every account incorrectly billed during the affected period and reprocessed claims to the correct primary
- Added an exception report flagging accounts where the plan billed differs from the plan returned as primary by eligibility, so future drift surfaces immediately
The Result
Patients stopped receiving statements for balances they didn't owe. Claims that had been routed to the wrong primary were reworked to the correct payor. Eligibility now selects coverage based on COB rather than response order.
What This Means For Your Lab
Eligibility integrations are quietly opinionated; every vendor handles multi-coverage situations differently, and the default behavior isn't always correct for how a lab actually bills. If patient complaint volume is creeping up around insurance balances, the issue often isn't the front desk. It's how the eligibility response is being interpreted.
High-Volume Tests Denied as Not Medically Necessary From a Stale LCD Diagnosis List
The Situation
Denials for medical necessity on a panel of high-volume tests had been climbing gradually. Coding looked correct. Ordering providers were using diagnoses that, on their face, supported the testing. The billing team was working denials individually, with no clear pattern.
The Problem
The diagnosis edit list inside the billing system referenced an LCD policy version that had been superseded. Medicare had updated coverage on those tests, adding supported diagnoses and removing others, but the edit table had never been refreshed. Claims with diagnoses that were now valid under the current LCD were still being scrubbed out internally as “not supported,” causing unnecessary denials and delayed claims.
How It Was Found
Pulled the current LCD policy text for the affected tests and compared the supported-diagnosis list against the edit configuration in the billing system. The two no longer matched. A representative sample of denied claims was then mapped against the current LCD, confirming that a meaningful share would have been clean under the live policy.
The Fix
- Refreshed the diagnosis edit configuration to match the current LCD policy for every affected test
- Identified denied claims still inside appeal windows and resubmitted those that were valid under the current policy
- Established a recurring LCD-refresh check tied to MAC bulletin updates so edit tables don't drift behind policy changes
The Result
Medical necessity denials on the affected panel dropped substantially. Recoverable denied claims were appealed and paid. The edit table now stays aligned with the active LCD rather than the version that happened to be loaded at go-live.
What This Means For Your Lab
LCDs change. NCDs change. Payor medical policies change. Edit tables that aren't actively maintained quietly fall behind, and the lab pays for it in denials that look like ordering-provider problems but are actually internal configuration drift.
NCCI Edits Quietly Bundling Reimbursable Tests Into $0 Lines
The Situation
A panel that was commonly ordered together had reimbursement that didn't quite reconcile against the contracted fee schedule. Each individual test paid at expected rates when ordered alone. When ordered together, the panel total came in below what the contract said it should.
The Problem
NCCI procedure-to-procedure edits were bundling one component of the panel into another whenever they appeared on the same claim. The lab was contractually entitled to separate reimbursement on those lines when the appropriate modifier was applied, but the modifier wasn't being added automatically. Individual claim review wasn't catching the suppressed line because it posted at $0 with no denial code.
How It Was Found
Compared expected reimbursement against actual reimbursement at the line level for the affected panel, then cross-referenced against the current NCCI edit pairs. The bundling was correct per the edit table; the missing piece was the modifier logic on the lab's side. A pivot by ordering combination quantified exactly how often the bundling was firing and what it was costing.
The Fix
- Configured automatic modifier application on the affected procedure pairs when documentation supported it
- Worked through the population of historically suppressed lines and rebilled with appropriate modifiers where appeal windows allowed
- Added a recurring line-level expected-vs-actual comparison so future NCCI bundling that suppresses reimbursement surfaces as part of standard review
The Result
Reimbursement on the affected panel returned to the contracted level. Recoverable historical lines were rebilled and paid where timely. The lab's billing logic now applies modifiers proactively rather than relying on per-claim review to catch suppressed lines.
What This Means For Your Lab
NCCI edits don't always look like denials; sometimes they look like a $0 line on an otherwise paid claim. If your contracted fee schedule says one thing and your actual paid totals say another for commonly bundled tests, the difference is often a modifier configuration the billing system never gets prompted to apply.
Every One of These Started the Same Way
Something in the numbers didn't add up. A report looked slightly off. AR was aging without explanation. Write-offs were higher than they should be.
None of these problems were visible on the surface. None of them were being flagged by the billing team, not because anyone was failing, but because standard reports aren't built to find them.
That's what I do. I go looking in the places standard reports don't reach.