If you’ve ever wondered what actually happens between a doctor’s visit and the bill your plan pays, the answer is a single word: adjudication. Claims adjudication is the process a health plan, healthshare, or TPA uses to decide whether a submitted medical claim gets paid, denied, or sent back for more information — and how much. It’s the operational core of any organization that pays medical bills, and it runs on the same basic sequence no matter who’s running it or what software they’re using.

Here’s that sequence, start to finish.

1. Intake

A claim has to arrive before anything can happen to it. Most claims come in as an EDI 837 — the electronic claim transaction a provider’s billing system sends through a clearinghouse — in one of a few flavors: 837P for a professional claim (the CMS-1500 form world — office visits, specialist care), 837I for institutional claims (the UB-04 world — hospital stays, facility charges), and 837D for dental. Some claims still arrive through a member portal, where a patient uploads a bill directly, and a shrinking number still show up on paper. However it arrives, intake is where the claim gets a record and a place in the queue.

2. Eligibility verification

Before anything else, the plan has to confirm the member was actually covered on the date of service — not today, not when they enrolled, but the specific day the care happened. A lapsed policy, a coverage gap, or a dependent aged off the plan all get caught here. This is also where a real-time eligibility check (the EDI 270/271 transaction pair, if you want the formal name) either confirms coverage instantly or flags it for a manual look.

3. Benefit and plan matching

Once eligibility is confirmed, the claim gets matched to the member’s specific benefit plan — because “covered” isn’t one setting, it’s a whole plan design. Is this service covered at all under this member’s plan? Does it need prior authorization? Does it fall under a specific benefit category with its own rules? This step determines which set of pricing and cost-sharing logic applies to everything that follows.

4. Pricing

Now the claim gets a price. Most plans price against a fee schedule — a pre-negotiated or plan-defined rate for that specific procedure code. When a code or provider isn’t on the fee schedule, plans typically fall back to a usual-and-customary (UCR) rate, benchmarked against what’s typical for that service in that geography. Network participation can also affect which rate applies. Pricing is where “what was billed” and “what the plan actually owes” start to diverge — often significantly.

5. Cost-sharing

With a price set, the plan applies the member’s cost-sharing terms: deductible (the amount the member pays before the plan starts sharing costs), coinsurance (the percentage split after the deductible is met), copay (a flat amount for certain services), and the out-of-pocket maximum (the ceiling past which the member stops paying anything). Getting this math right — and getting it right in the right order — is most of what a claims adjudication engine actually does.

6. Accumulator updates

Every claim that touches cost-sharing moves the needle on the member’s running totals: how much of the deductible is satisfied, how close they are to their out-of-pocket max, and — for healthshares — how they’re tracking against an annual sharing limit. These accumulators need to update as claims process, not in an overnight batch, because the very next claim that comes in for that member has to price against the current balance, not yesterday’s.

7. Duplicate and edit checks

Before a claim gets a final decision, it’s checked against what’s already in the system. The most common real-world case: the same visit arrives twice — once from the provider through EDI, once from the member through the portal — with small variations that make it look like two different claims at a glance. Catching that before payment is one of the most direct ways adjudication software earns its keep.

8. The decision: pay, deny, or pend

Everything above feeds into a decision. If a claim clears eligibility, is a covered benefit, prices cleanly, and doesn’t trip any edits, it can be auto-adjudicated — processed straight through with no human touch. If something needs judgment — a missing authorization, an eligibility mismatch, a suspected duplicate, an unusual price — it gets pended into a queue for a human adjudicator, with the reason attached so they’re not starting from scratch. The mix of auto vs. pended claims depends entirely on plan design and claim complexity; there’s no universal benchmark that means much across different books of business.

9. Remittance and explanation of benefits

Once a claim is decided, two documents come out the other end. The provider gets an 835 — the electronic remittance advice, which tells them what was paid, what was denied, and why, using standardized adjustment codes. The member gets an EOB (explanation of benefits) — the human-readable version, showing what was billed, what the plan covered, and what they owe.

Why this matters beyond the mechanics

For a self-funded employer plan, a healthshare, or a TPA, adjudication isn’t a back-office function — it’s the product. Get eligibility wrong and you pay for coverage that didn’t exist. Get accumulators wrong and members are billed incorrectly for months before anyone notices. Get duplicate detection wrong and the same claim pays twice. Every step in this chain is a place where an error becomes real money, a compliance problem, or a member calling angry about their bill.

That’s also why the tooling matters. A platform where eligibility, benefits, pricing, cost-sharing, and accumulators are one connected system — updating in real time as claims process — behaves very differently from a claims payer stitched together with five other vendors and a nightly batch job in between. See how Claimaro’s adjudication engine handles the full sequence, from intake through EOB, in one platform.