Why Your Biller Cannot See What Your Data Says

The Queue Is the Job

Your biller is almost certainly good at their job. If you have had the same one for years and you trust them, that instinct is probably right, and nothing in this post is an argument against it.

The argument is narrower and it is structural. A biller works a queue. A queue is a list of open items sorted by age or by dollar value, and it exists to be emptied. That is what it is for, that is how the work is assigned, and that is how the performance is measured. Claims worked per day. Days in AR. Percentage of the worklist cleared by Friday.

Every one of those measures rewards moving through the list. None of them rewards stopping in the middle of it to ask whether item thirty-one looks like items four, nine and twenty-two.

That is not a flaw in the biller. It is the definition of the role. A queue that gets read instead of emptied is a queue that grows, and a growing queue is the one failure mode that everybody in a practice notices immediately.

What a Day Actually Looks Like

It is worth being concrete about the view, because the abstraction hides the whole problem.

A biller opens the day with a worklist. Somewhere on the desk is the electronic remittance advice from yesterday's payer files, a set of claims that paid, a set that did not, and a set that paid differently than expected. There is a practice management screen with one claim on it. There is a payer portal open in a second tab. There is frequently a phone on hold.

The unit of attention is one claim. Everything on the screen is scoped to that claim: this patient, this date of service, this payer, this remittance code, this dollar amount. The biller reads it, works out what happened, and does one of four things. Corrects and resubmits. Writes an appeal. Bills the patient. Adjusts it off.

Then the next item. Forty to a hundred times a day depending on the practice.

Here is what that view contains, in full: the claim in front of them, the account it belongs to, and whatever history is attached to that one account.

Here is what it excludes. It excludes the other claims worked that morning, because they are closed and gone. It excludes the same denial from the same payer in March, because March is not on the screen and there is no reason it would be. It excludes every claim that paid correctly, which is the majority, and which is also where underpayments hide. It excludes every other payer, because the remit being read came from one payer and the next one will come from a different file entirely.

The view is correct. It is exactly what is needed to resolve one claim. It is also, by construction, one row at a time, and you cannot see a distribution one row at a time.

Two Jobs, Not One Job Done Badly

The reason this persists is that claim-level work and pattern-level work look like the same job and are not. They have different inputs, different outputs and different definitions of done.

Read the last row. Claim-level work fails loudly. If the queue backs up, everybody knows within two weeks, because the cash slows down and somebody asks. Pattern-level work fails silently, because a job nobody has been assigned produces no visible symptom when it is not done. It simply never happens, and the practice has no experience of the alternative to compare it to.

That asymmetry is why this survives in practices that are otherwise well run. The loud failure gets attention and resources. The silent one gets neither, not because anyone decided against it, but because there is nothing to decide about.

In-House or Outsourced, the View Is Identical

Practice owners often reach for this problem as a staffing question. If the patterns are not being found, get a better biller. If the biller is already good, outsource it to a company with more capacity.

Neither one changes the view, and it is worth being precise about why.

An outsourced biller works the same queue. They log into your practice management system, or into their own with your data in it, and they see one claim at a time in exactly the same shape. The screen is the same screen. The remittance file is the same file.

They are measured on the same metrics you would use. Clean claim rate, days in AR, collection percentage. Every one of those is a throughput measure. A billing company optimising hard against them is being a good vendor, and none of those numbers has a pattern in it.

Their scale runs the wrong direction. A billing company with two hundred practices does have an aggregate view, and it is aggregated across clients rather than across your payers over time. Knowing that a code denies frequently in general is a different fact from knowing that one payer started denying it for you in month four. The second one is the actionable one and it is invisible at their scale, because your practice is one thin slice of their volume.

The reporting they send you is per-claim by construction. A monthly billing report is a summary of activity: claims submitted, claims paid, AR by bucket, top denial reasons by count. Useful, honest, and still a roll-up of individual transactions rather than an analysis of the relationships between them.

None of that is an argument against outsourcing. Outsourced billing solves capacity, continuity and coverage, and those are real problems. It is an argument that changing who works the queue does not change what the queue shows, because the constraint is in the reporting layer rather than in the person.

The Reports That Exist, and What Each One Collapses

Every practice management system ships with reports. They are not bad reports. They each aggregate over one axis, and in doing so they collapse the other one, which is precisely where the patterns live.

Each of these is a standard report available in most practice management systems. The point is not that any one is deficient. It is that the axis each one collapses is the axis the next question needs, and running all six does not reconstruct the join.

Two things follow from that table.

No report on it aggregates across payers over time at line level. That specific shape, every line for twelve months with payer, code, modifier, billed amount, allowed amount, paid amount and remittance code together in one place, is the shape every pattern question needs, and it is the one shape nothing produces.

Running more of them does not help. Six reports each missing a different dimension do not add up to one report with all of them. You cannot join a PDF of aging buckets to a PDF of denial counts, because the underlying rows were already summed away before either report was printed.

The Data Is Standardised. The View Is Not.

This is the part that surprises people, and it is the reason the problem is solvable rather than inherent.

The raw material is already uniform. Under HIPAA's transaction standards, professional claims go out as an X12 837P and payments come back as an X12 835 remittance advice. The adjustment reasons on that remittance are drawn from standard code lists: Claim Adjustment Reason Codes and Remittance Advice Remark Codes, maintained under X12 and published by the Washington Publishing Company, revised on a published schedule three times a year.

So the denial your biller read this morning arrived in a machine-readable file, in a national standard format, carrying a code from a national list. Every practice in the country receives the same structure.

What is not standardised is the layer above it. Nothing in the chain is obligated to keep those files in a queryable form, join them across payers, or compare the paid amount on a line against what your contract said that line was worth. Practice management systems store the result and discard the shape. Clearinghouses report on the handoff and stop at adjudication. The standard ends at the wire.

That gap is worth stating plainly, because it explains why the problem is so widespread and so invisible at the same time. The data exists, in a standard format, in your possession, and no product in the stack turns it into the view.

What a Biller Would Need, and Why It Is a Week

Suppose you asked your biller a genuine pattern question tomorrow. Something specific: which payer and code combination cost us the most last year, counting both outright denials and lines that paid below contract.

This is what answering it actually requires.

1. Step 1
   A line-level export covering twelve months
   Not a summary and not claim level. Every line with date of service, payer, plan, CPT, modifiers, diagnosis, billed, allowed, paid, adjustment amount and every remittance code attached. Many systems will only export claim level from the standard reporting menu, and getting line level means a support ticket, a custom report, or pulling the remittance files directly.
2. Step 2
   Your contracted rate for every payer and every code
   This lives in the participation agreements, in fee schedules attached as PDFs, and in whatever spreadsheet somebody built the last time rates were negotiated. It is the single hardest input to assemble and nothing works without it, because without it you cannot tell an underpayment from a correct payment.
3. Step 3
   Filing limits per payer, and what each is measured from
   Needed to separate claims that were lost from claims that are still recoverable. Different sources per payer type, and secondaries are measured from the primary remittance rather than the date of service.
4. Step 4
   Remittance codes normalised across payers
   Payers use the standard code sets differently and pair them with different remark codes. Grouping raw codes into categories that mean the same thing is judgement work, not a lookup, and getting it wrong merges two distinct problems into one meaningless bucket.
5. Step 5
   A tool that can actually pivot it
   Twelve months of line level data for a small practice runs to tens of thousands of rows. That is past what a spreadsheet handles comfortably once you start joining contracted rates onto it, and well past what anyone wants to do by hand.
6. Step 6
   Uninterrupted time to look at the result
   The analysis is the short part. Building it is most of the work, and the first pass usually reveals that one of the five inputs above was wrong and has to be rebuilt.

Add that up honestly and it is the better part of a week, most of it spent on assembly rather than analysis. Nobody in a small practice has that week. The biller certainly does not, because the queue does not pause while they take it, and a queue that pauses for five days is a cash flow problem that shows up in the next deposit.

So the question gets asked, gets a reasonable partial answer from memory, and does not get answered. That is not avoidance. It is a correct allocation of the time available.

In one audit of 47,000 claim lines, the assembly took substantially longer than the analysis did. Most of the effort went into joining contracted rates onto line-level remittance data and normalising remittance codes across payers so that the same underlying reason counted as the same category. Once that existed, the patterns were legible in an afternoon. The difficulty was never the reading. It was the building of a thing that could be read.

What This Is Not

Three conclusions people reach from here, all of which make things worse.

It is not a discipline problem. Working the queue harder produces a cleaner queue and the same patterns, because the pattern is generated upstream and the queue is downstream of it. A practice that responds to this by pushing on throughput gets a tired biller and next quarter's identical report.

It is not a headcount problem. A second biller doubles the rate at which claims are worked one at a time. It does not create the view. Two people looking at one row each is still one row at a time.

It is not a software purchase. No practice management system on the market produces this report, and buying a different one produces a different set of reports with the same axis collapsed. The gap is between the systems rather than inside any one of them, which is exactly why no vendor has closed it.

What it is: a question nobody owns, requiring data nobody has assembled, in a format nobody's software emits.

What Actually Changes It

The fix is not more work. It is a different question, asked on a schedule, by something that is not the queue.

Separate the two jobs explicitly. Pattern work does not belong inside the worklist and will lose to it every time if you put it there. It is a distinct piece of work with its own inputs and its own cadence, quarterly or annually, and it needs to be named as such before it can be assigned.

Assemble the data once, properly. The five inputs above are painful the first time and much cheaper every time after, because contracted rates and filing limits change slowly and the export is repeatable once someone has worked out how to get it.

Judge it by whether categories stop recurring. Not by claims reworked. If the output of pattern work is four hundred more claims in the queue, it has failed at its own job. The output should be a handful of upstream changes: a verification step at check-in, one modifier applied differently, one payer policy escalated, one documentation template corrected.

Protect the biller from the result. This matters more than it sounds. If a pattern analysis lands as a performance critique, the practice loses a good biller and keeps the pattern. The finding is about a process that nobody was positioned to see, and it should be delivered that way, because that is what it is.

The claims still have to be worked one at a time. Somebody has to empty the queue, and that work is real, skilled, and unglamorous. What has been missing is the other job, and it has been missing for structural reasons rather than human ones. Claims that age out of their filing window are one visible symptom of the same gap, which is why timely filing gets its own post rather than a paragraph here.

Common questions

Is this saying our billing company is not doing their job?

No. A billing company that keeps your days in AR low and your clean claim rate high is doing the job it was hired to do, and doing it well is genuinely valuable. Pattern analysis is a different job that was never in the scope, is not what they are measured on, and does not become part of the engagement by implication. The useful move is to ask whether anyone is doing it, not to change vendors.

Does a biller with fifteen years of experience close the gap from memory?

Partly, and it is worth more than people assume. An experienced biller carries real pattern knowledge, and it is the strongest asset a small practice has here. What memory cannot do is quantify. It will tell you that a particular payer has been difficult lately and not what that difficulty was worth in dollars, or which of five difficulties was the expensive one. Ranking requires the data, and the ranking is what determines where to spend effort.

Why does the practice management system not just produce this report?

Because it does not hold all the inputs. Practice management systems store what was billed and what was paid. Your contracted rates live in participation agreements outside the system, and filing limits live in contracts and state manuals. The comparison that finds underpayments needs the contract, which is not a record the system has. That is a data boundary rather than a feature the vendor forgot.

Can we not just run the denial report more often?

Running it more often gives you the same collapsed view at a higher frequency. A denial report counts denials by reason and drops the dollars, the contract comparison and the time series. The most expensive pattern in most practices is not on a denial report at all, because it never denied. It paid, just below contract, quietly, every time.

How would we know if we have this problem without doing the whole analysis?

One diagnostic question usually settles it. Ask whoever handles your billing which payer and code combination cost the practice the most last year, and whether they can put a number on it. If the answer is a confident story without a figure, the view does not exist. That is the expected answer and it is not a mark against them.

Where does this fit against fixing documentation or the front desk?

Upstream of both, in the sense that it tells you which one to fix first. A pattern analysis frequently points backwards to a registration field or a missing note element, and the value is that it names the specific one rather than prompting a general effort to be more careful. Without it you are improving everything a little, which is more expensive and slower than improving one thing decisively.