A pended claim isn’t a stuck claim or a broken one — it’s a claim that hit a decision point the rules engine can’t resolve alone, so it gets set aside with a reason attached and routed to a queue for a person to finish. Every claim runs the same sequence (eligibility, benefit matching, pricing, cost-sharing, edit checks); a claim that clears all of it auto-adjudicates, and one that doesn’t pends.
Common reasons a claim pends
- Missing or mismatched prior authorization — the service needed one and it isn’t on file, or doesn’t match what was billed.
- Eligibility ambiguity — coverage on the date of service isn’t clearly confirmed, often during an enrollment or termination transition.
- No pricing match — the code or provider isn’t on a fee schedule and needs a usual-and-customary determination or manual pricing.
- Suspected duplicate — the same service appears to have arrived twice, commonly once via EDI from the provider and once through a member portal upload.
- Coordination of benefits — another plan may be primary and that has to be confirmed first.
- An edit flag — an unusual billed amount, an incomplete provider record, or a code combination that needs a second look.
The adjudicator queue
Once a claim pends, the reason code travels with it — an adjudicator opening the claim should see why it stopped, not just that it stopped, so they’re not re-diagnosing the claim from the beginning. Queues are typically worked by reason type or aging, since a missing-auth pend and a suspected-duplicate pend call for different research and different people to resolve them.
The operational cost of a high pend rate
Pends aren’t free, and the cost scales close to linearly with volume. Say a TPA’s book runs 500 pended claims a week, and each one takes an adjudicator 10 minutes to research and resolve — confirm eligibility, check the auth system, verify the duplicate, whatever the reason code calls for. That’s:
500 claims × 10 minutes = 5,000 minutes ≈ 83 hours a week — more than two full-time adjudicators, just to clear that week’s pends, before counting the pends that arrive tomorrow.
Push the average handling time to 15 minutes, or the pend count to 800 a week, and the staffing math moves fast in the wrong direction. That’s before counting the downstream cost: slower turnaround against prompt-pay deadlines, providers who stop trusting your payment timeline, and members calling about a claim that’s been sitting for two weeks with no visible status.
Why this matters beyond headcount
The lever isn’t lowering your standards for what gets auto-adjudicated — it’s reducing how often claims land in the queue for avoidable reasons in the first place: complete and current fee schedules, real-time eligibility instead of a batch feed, authorization data that’s actually synced with the plan. None of that is a number a vendor can promise you in the abstract, since it depends entirely on your plan design and claim mix. What a platform can control is what happens once a claim does pend — whether your adjudicators get full context immediately or have to go hunting for it. Claimaro’s adjudication engine attaches the pend reason and the relevant claim history to every queued item, which is the difference that actually shows up in adjudicator throughput for a TPA running a high-volume book.