What an EOB is — and what it isn't

An explanation of benefits (EOB) is the statement a health plan sends after it adjudicates a claim. It explains how the claim was processed: who provided care and when, what the provider charged, what the plan agreed to allow, what the plan actually paid, and what portion falls to the patient as deductible, copay, or coinsurance. It also carries claim and member identifiers and the remark or denial codes that explain the payer's decisions.

An EOB is explicitly not a bill. CMS guidance is direct on this point: the EOB is an explanation of how a claim was adjudicated, and patients should compare it against the bill the provider sends. For anyone building claims or payments tooling, that distinction matters — an EOB pipeline is reconstructing the payer's adjudication decision, not an invoice.

Equally important: there is no single nationwide standard EOB format — some states mandate minimum contents (New York Insurance Law §3234, for example) and Medicare Advantage plans follow CMS model templates — but layout, labels, and column order still vary payer to payer. An extraction approach that assumes a standard structure will fail as soon as a payer with a different layout enters the mix.

Why EOBs are hard to parse

Three properties make EOBs harder to parse than more routine financial documents:

Four semantically-adjacent money columns

EOBs revolve around the same four amounts — what the provider billed, what the plan allowed, what the plan paid, and what the patient owes — but because no single nationwide format is mandated, payers swap the names and the order of these columns freely. Two statements can carry identical adjudication data under different headers and different column sequences. A parser that maps columns by position or by a fixed synonym list can silently assign the plan-paid amount to patient responsibility on the next payer's template, and a wrong-but-plausible dollar figure is far more dangerous than a blank one.

Multi-claim, multi-line structure

A single EOB routinely covers multiple claims, each with multiple service lines, plus per-claim and per-statement totals. The line items are variable-length — one statement might carry two service lines, the next forty — and the totals must reconcile against the lines beneath them. Flattened, fixed-field extraction can't represent this; the output needs to preserve the claim → service line hierarchy. Insurance loss run reports pose the same claims-table problem, and Reducto's loss run cookbook shows the sibling pattern: parsing them into clean, structured claims tables.

Per-payer code legends

Adjustment, remark, and denial codes are typically defined in each payer's own legend, usually printed elsewhere on the statement. A code on a service line is meaningless until it's joined to that document's legend — so the extraction has to capture both.

Where traditional approaches fall short

The traditional answer is a template per payer — a maintenance treadmill, since payers redesign layouts on their own schedules and no nationwide standard constrains them, so the template library only ever grows. Rule-based column mapping fares no better: it keys on header text, so a payer that renames or reorders the money columns defeats the synonym list without raising any error — the misread arrives as a plausible number, not a failure. Flattened single-pass extraction likewise cannot represent the claim → service-line hierarchy the printed totals reconcile against. The job requires extraction that identifies each amount by its meaning rather than by its position or its label.

What to extract

The schema that works in practice mirrors the document's own hierarchy: a list of claims, each containing a list of service lines, with statement-level identifiers on top.

Level	Fields
Statement	Payer name, member name and ID, statement date, claim count, statement totals
Claim	Claim number, provider, patient, service date range, claim-level totals, claim status
Service line	Date of service, procedure code and description, amount billed, allowed amount, amount plan paid, patient responsibility (with deductible/copay/coinsurance breakdown where shown), remark codes
Code legend	Each remark/adjustment code with its payer-provided definition

Two design notes carry most of the weight. First, describe the four money fields by meaning, not by expected header text — "the amount the plan agreed to allow for this service, regardless of what the column is labeled" — so extraction generalizes across payer layouts. Second, keep remark codes attached to the service lines they annotate and extract the legend as its own list, so downstream systems can resolve codes without re-reading the document.

Building it with Reducto

The workflow follows the same pattern as Reducto's invoice extraction cookbook — the closest published analog, since invoices share the two hard parts: money columns and variable-length line items.

Parse first. Parsing converts the EOB — scanned or digital — into a faithful structured representation, preserving the tables and reading order that the extraction step depends on. EOBs are healthcare documents, and Reducto's healthcare document parsing cookbook demonstrates this step on exactly that class of input — messy scanned healthcare paperwork parsed into clean, structured text.

Extract with Deep Extract. Define the claims → service-lines schema and run Deep Extract over the repeating levels. This is what handles the variable-length problem: instead of fixed slots, the system identifies the repeating pattern and captures every claim and every service line, however many there are. Nested objects hold related fields together (a claim's identifiers and totals), and descriptive field hints — the "by meaning, not by header" descriptions above — steer money-column mapping across payer templates. Deep Extract is production-proven at this kind of scale — 120M+ fields extracted on documents up to 11k pages, with 99–100% field accuracy in Reducto's July 2026 head-to-head against frontier models and human annotators.

Turn on citations. With citations enabled, every extracted value carries its source page and bounding box. For adjudication data this is not a nice-to-have: when a reviewer needs to confirm a patient-responsibility figure, the citation takes them to the exact spot on the statement.

Split combined files. EOBs often arrive as combined PDFs — a day's mail scanned into one file, or multi-statement payer batches. Split separates these into individual statements before extraction, so each EOB is processed as its own document.

Queue the backfill. For historical archives, batch processing handles volume: submit jobs through the batch queue for a 20% discount on parsing, with a 12-hour completion guarantee — a good fit for backfills where nothing is waiting on same-minute results.

Validating accuracy

Most EOBs come with a built-in audit: the totals. Because most payers print per-claim and per-statement totals alongside the lines, extractions can be checked arithmetically wherever those totals are present — sum the service lines within each claim and compare to the claim totals; sum the claims and compare to the statement totals, for each of the four money columns independently. A mismatch flags exactly which claim and which column to review, and the citation on each value points a human to the precise location on the page. Run the same check per payer when onboarding a new template: if one column reconciles and another doesn't, the mapping — not the arithmetic — is usually the culprit.

Compliance and deployment

EOBs contain protected health information, so the deployment posture matters as much as extraction quality. Reducto supports HIPAA compliance with a BAA on the Growth and Enterprise tiers, and zero data retention is available from Growth up. Details are in the enterprise readiness documentation, and the healthcare industry page covers how healthcare teams run Reducto in production.

FAQ

We receive 835s (ERAs) from some payers — do we need document extraction at all?

Not for those payers. The ERA (X12 835) is the electronic, already-structured version of remittance data — if you receive 835s, use them directly. Document extraction is for the remainder: the payers and plans that still send paper or PDF EOBs, the historical backfiles that predate your EDI connections, and member-submitted statements. Claims operations commonly end up running both paths.

Can this handle a payer we've never processed before?

Yes — that's the point of describing fields by meaning rather than by layout. Because there's no single nationwide standard EOB format, the extraction schema targets what each amount is, and validation (line-vs-total reconciliation plus citations) confirms the mapping held on the new template before the data flows downstream. Reducto has zero-shot Accuracy, meaning it does not use a manual template to process and can process documents it has never seen before.

Does the extracted patient-responsibility amount tell us what to collect?

Treat it as the payer's adjudication statement, not a bill. CMS advises comparing the EOB against the provider's actual bill; the extracted figures are the structured basis for that comparison and for spotting discrepancies — which is exactly why citations on every money value matter.