Insights › Diagnostics labs
Diagnostics labs
The lab billing problem that looks like a staffing problem
Most billing software assumes one visit, one bill. A lab requisition does not behave that way, and the gap shows up as a backlog that gets blamed on staffing.
By The CercaLabs team · Published September 18, 2026 · 5 minute read
In a lot of lab billing offices, the morning starts the same way. Export, sort, reconcile, then begin working claims. Nobody thinks this is strange. It is just what the morning is.
The usual read is that the team is understaffed, and the usual fix is two more billers.
Look at what is actually being reconciled, though, and the answer is often that one order produced several things the billing system treats as separate events, and somebody has to reassemble them by hand before a claim can go out.
That is not a staffing problem. That is a shape problem, and it does not go away when you hire.
Most revenue cycle software was built for a visit, not an order
A hospital or clinic encounter is contained. One patient, one visit, one date of service, one bill. The data has a natural boundary, and general-purpose billing software assumes that boundary exists because it usually does.
A requisition does not have that shape. One order can produce multiple accessions, specimens collected at different times, result dates that do not line up, and several billable components under different codes. Add-on tests arrive after the requisition has already left the ordering office. Reflex tests get triggered by a result rather than a person.
None of that is exotic. It is ordinary lab operations. But if the system expects one encounter to map to one claim, every one of those becomes an exception a human reconciles by hand.
Lab-specific billing platforms were built to close exactly this gap, and they handle a requisition far better than a practice or hospital system does. The mismatch still shows up wherever the order crosses from one system to another: the LIS to billing, billing to the payer, and anything that arrives after the claim has gone out. For outreach labs and smaller independents billing through general-purpose software, it shows up everywhere.
The symptom never looks like software
This is why it goes unfixed for years. The mismatch shows up as behavior, and behavior looks like a people problem.
Billers working spreadsheets before they touch a claim. Requisition data does not map cleanly to claim structure, so it gets exported and reassembled manually.
A backlog that grows with volume no matter who you add. The reconciliation step scales linearly with orders. Headcount buys time rather than throughput.
Add-on and reflex testing that bills late or not at all. The original claim already went out and there is no clean path for a charge that arrives afterward.
New test codes that take weeks to bill correctly. The test menu and the billing configuration are maintained by different teams on different clocks.
Every one of those is a handoff failure between two systems that are each working correctly on their own terms. That is worth sitting with, because it means nobody on either side is doing anything wrong.
Three questions that tell you whether this is you
None of these need a project. You can get rough answers in an afternoon and rough is fine.
How many touches does an average claim take before submission? Not the hard ones, the average one. If the answer involves a spreadsheet, the reconciliation work is structural rather than occasional.
What happens to a charge that arrives after the claim goes out? If the honest answer is that somebody notices it or they do not, you have a revenue leak with no owner.
Who updates billing configuration when the test menu changes, and how do they find out? If they hear about it eventually, that lag is already showing up in your denial rate.
Write the numbers down even if they are estimates. A program without a baseline cannot be defended at budget time, and that is how good work quietly loses funding.
What not to do about it
Re-platforming is almost never the right first move. It is expensive, it is slow, and moving to a new system introduces a mapping problem of its own while the old one is still being worked.
Building a custom billing system is worse. The usual failure is maintenance rather than design: the person who built it leaves, and nobody else can safely change it.
The cheaper intervention is usually to fix how requisition data maps to claim structure inside the system you already have, and to give the post-submission charge path a named owner. That is configuration and process work, and where the repetitive steps remain, automation that sits on top of your existing billing system rather than replacing it. It is unglamorous and it is where most of the recoverable time actually sits.
Where none of this applies to you
If your test menu is small and stable, your volume is modest, and add-on ordering is rare, the software you have will probably serve you fine. The mismatch only gets expensive at volume and variety, and plenty of labs never reach either.
And if your billers are not exporting anything, you do not have this problem. Go look before you assume you do.
The honest limit is that fixing this does not feel like much while it is happening. You are not buying anything, there is no launch, and the win shows up as a morning that got shorter. That is a hard thing to get funded, which is exactly why it stays broken in so many places.
*If you want a written read on where your requisition-to-claim mapping is costing you, that is what a teardown produces.*