Biller lag, measured properly
There is no button for this report. That is most of why nobody has it.
Every practice management system will tell you what was billed. Most will tell you what was delivered. Almost none will tell you what has been converted into a billable charge and is sitting there, unsubmitted, getting older by the day.
Which is a shame, because it is the single most actionable number in the revenue cycle.
Why the system does not give it to you
Because “unbilled” is not a status. It is the absence of one.
A charge exists. A claim does not exist yet. The system is not tracking a thing; it is tracking the gap between two things, and reporting tools are generally built to count records rather than count their absence.
So the report has to be built by subtraction: every converted charge, minus every charge that appears on a submitted claim, aged by the date of conversion.
Building it
You need three fields and one join.
From the charge side: charge ID, date of service, date converted, agreed amount.
From the claim side: charge ID, submission date.
Left join the claims onto the charges. Every row with no submission date is unbilled. Age it by date converted — not date of service, which conflates this stage with the previous one — and bucket it.
That is the whole report. It runs in a spreadsheet if it has to.
The one trap: make sure “submitted” means submitted to the payer, not marked ready in a queue. Some systems set a status when a claim is assembled and a different one when it actually leaves, and the gap between the two is precisely the thing you are trying to measure.
Reading it
Illustrative arithmetic, not a client engagement.
The first bucket is normal. The second is tolerable. The third is drag. The fourth is the finding.
A hundred and forty-two charges over ten days old is not a throughput problem — a throughput problem would spread evenly. A pile in the oldest bucket means something is stuck: a payer whose enrolment lapsed, an authorization the biller is waiting on, a client with a coverage question, a batch that failed and nobody noticed.
Which is the useful thing about this report. It does not just measure speed. It sorts the queue into “moving” and “stuck,” and the stuck pile almost always has two or three causes rather than a hundred and forty-two.
The target
Two business days from conversion to submission, at 95 percent, is achievable. It is not exotic and it does not require new software. It requires a daily queue rather than a weekly one, and it requires someone to own the stuck pile.
It is worth being honest that plenty of practices never get there, and not because the biller is bad. Two days assumes the authorization is clean, the enrolment is current, and the note is signed — which loops back to stages 02 and 04. A biller cannot submit a claim for a session against an expired authorization. That is not a lag, it is a blockage, and it belongs to somebody else.
So measure the lag, then split it: how much is queue, how much is blocked. The queue part is a cadence problem. The blocked part is an upstream problem wearing a billing costume.
Pulling it without making it awkward
The point of building this yourself is not distrust. It is that a performance number sourced from the party being measured is not a control, whatever the relationship.
It also removes the most common failure mode of these conversations, which is arguing about the report instead of the problem. If both sides are looking at the same query against the same data, the conversation is about the hundred and forty-two stuck charges, which is a conversation everybody wants to have.
Run it weekly. It takes ten minutes once the query exists. Send it to the biller as a working list, not as a scorecard.
Five checks you can run this week
1. Build the query once and save it. Charges with no submission date, aged by conversion date. Everything after this is free.
2. Check what “submitted” means in your system. Assembled and transmitted are different statuses in most platforms, and only one of them is real.
3. Read the oldest bucket by reason, not by count. Group the stuck pile by payer and by client. Two or three causes will explain most of it.
4. Split queue from blocked. Anything waiting on an authorization, an enrolment or an unsigned note is not the biller’s lag. Route it to whoever owns it.
5. Multiply the total unbilled by nothing at all. This is not lost revenue — it is delayed revenue, and calling it a loss will cost you credibility the first time someone checks. It is working capital, and that is a strong enough argument on its own.
The number to actually track
Converted and unbilled, aged by conversion date, in dollars, with a two-day target.
Split it into queue and blocked. A claim waiting on an authorization, an enrolment or an unsigned note is not your biller’s lag.
Do not report the unbilled total as lost revenue. It is delayed revenue, and calling it a loss costs you credibility the first time somebody checks.
Where this sits
This is the fifth of eight stages where ABA revenue leaves, and the last one you can fix without a payer on the phone. Everything downstream needs somebody outside your building to act.
This is the last report in the cycle that measures only your own building.
A Leak Map Assessment measures all eight — the reservoir, authorization burn, cancellations, session conversion, conversion to billed, clean claims, rate integrity and recoupments. A claims audit is a different instrument. It starts once a session has been converted and billed, and reconciles the back half of the cycle to cash.
Aimline closes the books, oversees the revenue cycle, and sits in the CFO seat for ABA practices. We run claims audits scoped to a payer book, and Leak Map Assessments that measure the full cycle — three weeks, $7,500 fixed. Either one gives us a verified number to run oversight against, and the report is yours whether or not you engage us to fix what it finds.
