What Happens to Your Revenue When Systems Change

Whether your lab is switching billing platforms, getting acquired by a private equity group, or consolidating systems after a merger, one thing is consistent: data that lived cleanly in one system rarely arrives cleanly in another.

The translation between systems, through HL7 feeds, data exports, mapping configurations, and integration logic, is where revenue goes quietly missing. Not all at once. Gradually, in ways that look like normal operational noise until someone goes looking for the pattern.

Here's what that actually looks like.

The Migration Looks Successful, But Something Is Off

Most system migrations are declared successful when the technical work is done. Data moved. Systems are live. Claims are going out.

What doesn't get checked, at least not systematically, is whether the data that moved is behaving correctly on the other side.

The billing team is focused on keeping up with daily volume in the new system. IT is moving on to the next project. Meanwhile, the revenue problems that were introduced during migration are quietly compounding in the background.

By the time anyone notices that something is wrong, months of claims have processed through a broken configuration.

What Goes Wrong — And How

These are the most common ways revenue disappears during and after a system migration. None of them are obvious in the moment. Most of them don't appear on standard reports.

Payor lists don't match; claims go to the wrong place

Every billing system maintains its own payor list: insurance companies, plan IDs, payer codes. When you migrate, that list has to be translated from the old system's format to the new one.

If the mapping is incomplete, claims get routed to the wrong payor. A Medicare Advantage plan gets billed as straight Medicare. A specific commercial plan gets billed under a parent company's generic code. Claims reject, get denied, or get paid at the wrong rate, and the billing team works them as individual denials with no indication that they all trace back to the same mapping gap.

Patient insurance doesn't translate correctly

Patient insurance records are among the most complex data to migrate. Plan codes, group numbers, subscriber IDs, coordination of benefits sequences; all of it has to map correctly from the old system to the new one.

When it doesn't, patients get billed for balances their insurance should have covered. Or claims go to a secondary payor before the primary has adjudicated. Or coordination of benefits is reversed, and the wrong plan gets billed first. The patient calls confused. The billing team investigates individual accounts. No one sees the systemic pattern underneath.

Fee schedules don't carry over correctly

Contracted rates — what each payor has agreed to pay for each test — live inside the billing system as fee schedules. When migrating, those schedules have to be rebuilt or imported into the new system exactly.

If they don't come over correctly, the system can't accurately calculate what it should have been paid versus what it received. Underpayments go undetected because there's no accurate baseline to compare against. The billing team posts what comes in and moves on because the system isn't telling them anything is wrong.

Diagnosis and procedure code mappings break

ICD-10 diagnosis codes and CPT procedure codes have to move cleanly between systems. When they don't — when codes get truncated, reformatted, or lose required characters like decimal points during transmission — claims reject at the payor.

The rejections look like coding errors. Billing staff correct and resubmit individually, not realizing that every affected claim traces back to the same configuration error in the new system's HL7 output.

Accounts that were active arrive flagged as closed

During a data migration, account statuses — open, pending, closed, uncollectible — have to translate correctly. If the status mapping is off, accounts that should be in active follow-up arrive in the new system marked as closed or written off.

No one follows up on them. They age. The patients never receive statements. The balances never get collected. And because the accounts show as closed, they don't appear in AR aging reports; they've already left the AR entirely.

Ordering provider information gets lost or corrupted

Lab claims require accurate ordering provider information: NPI numbers, practice addresses, referring physician details. When this data doesn't migrate cleanly, claims can reject for missing or invalid provider information, or get routed incorrectly based on wrong address data. In some cases, provider credentialing mismatches mean claims process under the wrong provider entirely, creating billing compliance exposure on top of the revenue loss.

Remittance posting logic doesn't transfer

Every billing system has configuration rules for how it posts remittances: how it applies payments, handles adjustments, clears denial codes, and triggers follow-up. Those rules don't automatically transfer to a new system. If the new system's posting logic doesn't match the old system's behavior, payments get applied incorrectly, adjustments post to the wrong buckets, and denial codes that should trigger work queues get auto-cleared instead. The financial data looks clean on the surface. The revenue it represents is gone.

Why These Problems Are So Hard to See

Every one of these issues has the same characteristic: it looks like normal operational activity from inside the billing system.

Claims are going out. Payments are coming in. Denials are being worked. The reports show activity.

What the reports don't show is whether the claims went to the right payor, whether the payments match contracted rates, whether the denials share a common root cause, or whether accounts that left AR should still be in it.

Standard reports are built to show what happened. They're not built to show what should have happened or to surface the gap between the two. That gap is where the revenue goes.

What Finding It Actually Looks Like

Revenue recovery work after a system migration isn't about re-doing the migration. It's about comparing what the new system is doing against what it should be doing, systematically, across systems, at the data level.

That means:

• Pulling payor data from both systems and reconciling it field by field — verifying that every plan code, group number, and routing rule translated correctly.
• Comparing patient insurance records in the new system against source data — identifying where coordination of benefits reversed, where plan codes didn't map, where patients are being billed for balances they don't owe.
• Building a payment comparison against contracted fee schedules — identifying payors whose reimbursements have drifted below contracted rates since the migration.
• Analyzing rejection and denial patterns by source — looking for the pattern that reveals a systematic configuration error underneath them.
• Pulling closed and written-off accounts and cross-referencing them against source data — finding the accounts that shouldn't have closed and getting them back into active follow-up.

None of this shows up in standard reporting. All of it requires working across systems simultaneously, not just inside the new one.

This Is Also What PE Acquisitions Create

Private equity firms that acquire laboratories and consolidate them onto a portfolio billing system face every one of these risks, often amplified, because the migration is happening faster, across more systems, with less institutional knowledge of the acquired lab's configurations.

The acquired lab's billing team knows their old system. The portfolio system's team knows their system. Nobody knows the gap between them. That gap is exactly where the revenue goes missing and exactly where this work finds it.