A claim went out, came back, got fixed, went out again, came back again. By the time it finally paid, it had been submitted 18 times. Eighteen rounds of someone touching it, and every round felt like progress.
It was the same failure repeating.
Rework feels like work
When a claim bounces and you rework it, it feels productive. Someone caught the error, fixed it, resubmitted. That is real effort, and the claim pays in the end, so it looks like the system worked. But reworking a claim 18 times is not 18 wins. It is one unfixed problem caught 18 times. The claim was always going to bounce, because nothing upstream changed to stop it. Each resubmission treated the symptom and left the cause exactly where it was.
This is why a hard-working billing team can grind all day and still watch the same denials come back next month. The effort is real. It is just aimed at the bounce instead of the reason for the bounce.
How one claim becomes eighteen attempts
Walk through how the count climbs. The claim goes out and gets rejected for, say, a missing modifier. A biller pulls it up, adds the modifier, sends it again. It comes back a second time, now flagged for something else the first rejection masked. Fixed and resent. Third rejection, a different edit. Each pass clears one surface error and reveals the next, because nobody ever looked at the claim as a whole and asked what was actually wrong with it. The claim is being corrected one rejection at a time, reactively, with the payer setting the agenda.
Eighteen is just where this particular claim happened to stop, on the pass that finally cleared. Some stop at three, some at twelve. The number is not the point. The point is that every one of those passes was a person spending time, and none of them changed anything about how the next claim like it would go out. The next one starts the same cycle from scratch.
Why the busiest teams stay the most stuck
Here is the cruel part. The harder a team works the denials, the more stuck they can become, because the reworking itself hides the problem. A team that clears its denial queue every day looks like it is winning. The claims pay, the queue empties, the metrics on denials worked look strong. So nobody goes looking for a root cause, because the surface says the system is functioning. The very competence that clears the queue is what keeps anyone from asking why the queue refills the same way every morning.
A team that was worse at reworking might actually surface the problem faster, because the backlog would grow until someone demanded to know why. Good reworking absorbs the pain quietly, day after day, which lets the underlying break survive indefinitely. The reward for working denials well is getting to work the same denials forever.
The cost hides inside the effort
A claim reworked many times still pays eventually, so the loss never shows up as a denial you lost. It shows up in two places that are harder to see. The first is time, the staff hours spent touching the same claim over and over, hours that could have gone to work that does not repeat. The second is delay, the weeks of cash tied up while the claim cycles through rejection after rejection before it finally clears.
That second cost is the one practices almost never count. A claim that takes 18 passes to pay is not just expensive to process. It is slow to convert, and slow cash is money you are financing while you wait. Multiply that delay across every claim that follows the same pattern, and the rework is quietly stretching your whole cash cycle, not just burning staff time. The effort cost you can at least feel, in tired people and full queues. The cash cost is invisible until someone measures how long these claims actually take to land.
How a factory sees a defect
A factory floor does not repair the same defect again and again and call it productivity. A part that keeps failing inspection is a signal that something on the line is wrong, and the answer is to correct the line, not to keep fixing the parts coming off it. Repairing parts is endless. Fixing the line ends it. The whole discipline of quality control is built on the idea that catching a defect is not success, it is evidence of an upstream problem you have not solved yet.
Healthcare reworks claims one at a time and rarely steps back to ask why this kind of claim keeps bouncing in the first place. The denial queue is treated as the work, when it is really the inspection station catching the same defect over and over. Clearing it feels like progress for the same reason fixing a defective part feels like progress. It is real, immediate, and it changes nothing about the next one.
Why the resubmissions follow patterns
The claims that get submitted 18 times are not random, and that is the good news buried in all of it. They follow patterns. A handful of specific, repeatable causes drive most of the rework in any given practice, the same missing fields, the same coding habits, the same intake gaps, showing up again and again. The reason the rework feels endless is that nobody has named those patterns, so each claim looks like its own fresh problem instead of the hundredth instance of a known one.
Name the patterns and the picture changes completely. Most of the rework collapses onto a short list of causes, and each cause has a fix that lives upstream, before the claim ever goes out. Fix it there, and the claims that used to take many passes start clearing on the first one. The denial queue does not get worked faster. It gets smaller, because fewer claims that were going to bounce ever leave the building.
Found, fixed, and held
Found: claims cycling through many resubmissions, with the rework mistaken for productivity.
Fixed: the patterns behind the rework get named and corrected upstream, so the claims that used to bounce go out clean.
Held: the patterns stay watched, so a new source of rework shows up as a signal instead of quietly becoming the next thing the team reworks forever.
What this means for you
You can see this in your own queue without us. Take a sample of claims that took more than a few attempts to pay and ask one question of each: was this a fresh, one-off error, or the same kind of problem you have seen many times before? If most of them are the same handful of issues repeating, you have found the patterns, and the rework you have been treating as the job is really a short list of upstream breaks you can close.
We pulled the patterns apart at one practice, found the few that drove most of the rework, and showed how fixing them upstream stopped the resubmissions and shortened the cash cycle. See the full breakdown here.
Or book 30 minutes, and we will look at which patterns are driving the rework in your own queue. Your numbers, not ours.