The EDI 837, Decoded: A Claim Is Not an Invoice With a Diagnosis Code

An 837 · Claim is the healthcare request for payment: it tells a payer who provided care, who received it, what was done, why it was medically necessary, and what amount is being claimed — in a structure strict enough that a single mismatched loop can reject the whole claim before a human ever sees it. It is not a medical version of an invoice. It is an adjudication input.

I run SignalEDI. This series has walked the healthcare chain in order: the 270 · Eligibility Inquiry / 271 · Eligibility Response that checks coverage before care, and the 276 · Claim Status Inquiry / 277 · Claim Status Response that answers "whatever happened to that claim?" Today's document is the one between them in the workflow — the claim itself. The 835 · Healthcare Benefit Payment / Remittance Advice that explains the payment after adjudication is its closing counterpart.

What is an 837 · Claim, and what are its three forms?

The 837 comes in three forms for three kinds of care. The 837P is the professional claim, used by physicians and other individual practitioners — the electronic successor to the paper CMS-1500. The 837I is the institutional claim, used by hospitals and facilities — the successor to the UB-04. The 837D is the dental claim. The forms share a common X12 skeleton, but the data each one carries reflects a different billing reality: a professional claim is organized around a rendering provider and procedures, an institutional claim around a facility stay, types of bill, and revenue codes.

That distinction matters at build time. Teams that model "a claim" as one generic form discover late that institutional billing needs structures the professional form does not use, and that a payer's companion guide will specify — often differently per payer — which form, loops, and situational elements it actually requires.

How is an 837 actually structured?

An 837 is built in loops, and the loops carry the meaning. At the top are the submitter and receiver — who sent the file and which payer or clearinghouse it is for. Then comes the billing provider loop, the subscriber loop (the person whose coverage is being billed, who may or may not be the patient), and, when the patient is a dependent, a separate patient loop. Only after that hierarchy is established does the claim loop itself begin, carrying the claim total, the dates of service, and the diagnosis codes — and inside it, one service-line loop per procedure, each with its own code, charge, units, and pointers back to the diagnoses that justify it.

The diagnosis pointers are the detail newcomers miss most often. A service line does not merely list a procedure; it points to the specific diagnoses on the claim that make that procedure medically necessary. Adjudication reads those pointers. A perfectly valid procedure code pointed at the wrong diagnosis is a denial with correct codes everywhere — which is why "all the codes were right" and "the claim was denied" are so often both true.

Why do 837 claims get rejected before they are even adjudicated?

Because there are two different gates, and teams routinely confuse them. The first gate is structural and business-rule validation: is the file syntactically valid X12, are the required loops present, do the totals balance, do subscriber identifiers match the payer's enrollment records? Failures here produce rejections — from a clearinghouse or a payer's front end — and the claim never enters adjudication at all. The acknowledgment layers from earlier in this series are how you learn that: a 999 · Implementation Acknowledgment reports structural acceptance, and a 277CA · Claim Acknowledgment reports claim-level acceptance or rejection.

The second gate is adjudication itself, where a structurally accepted claim is priced, checked against benefits and medical policy, and paid, reduced, or denied — with the outcome explained later on the 835 · Healthcare Benefit Payment / Remittance Advice, using standardized adjustment reason codes.

The operational difference is timing and ownership. A rejection is usually your data or your format, fixable today and resubmittable without an appeal. A denial is a payer decision that needs a different response. Workflows that lump both into one "denied" bucket waste appeals on fixable rejections and let filing deadlines expire while they do it.

Where do 837 workflows usually break?

The first break is identity matching. The subscriber name, date of birth, and member ID on the 837 have to match the payer's enrollment record — not the intake form, not the practice management system's shorthand. This is the same matching discipline the 270 · Eligibility Inquiry exists to check before the visit; claims built from unverified demographics inherit every typo as a rejection.

The second break is treating a clearinghouse "accepted" message as payer acceptance. A clearinghouse acceptance means the file passed that clearinghouse's edits and was forwarded. The payer's own front end can still reject it, which is why the 277CA from the payer matters, and why mature workflows track a claim through each acknowledgment layer instead of stopping at the first green checkmark.

The third break is building claims and then losing them. If submission does not create a durable record — the exact claim as sent, its control numbers, and its acknowledgments — then a later 276 · Claim Status Inquiry has nothing reliable to ask about. Capture the claim as transmitted, not a re-rendered summary from the billing screen, because every follow-up transaction has to match what the payer actually received.

Frequently asked questions

Is an 837 the same as an 810 · Invoice?
No. The 810 · Invoice is a commercial invoice for goods and services in supply-chain EDI. The 837 · Claim is a healthcare request for payment that carries clinical justification — diagnoses, procedures, and their pointers — and is adjudicated against a patient's coverage, not paid against a purchase order.

What is the difference between a rejection and a denial on an 837?
A rejection happens before adjudication: the claim failed structural or front-end business edits and never entered the payer's payment system — fix the data and resubmit. A denial is an adjudication decision on an accepted claim, explained on the 835 · Healthcare Benefit Payment / Remittance Advice.

Can one 837 file contain more than one claim?
Yes. One file can carry many claims, organized under billing-provider and subscriber loops, and batch submission is the norm. The discipline is per-claim tracking: each claim needs its own acknowledgment, status, and remittance trail regardless of the batch it rode in.

The pattern across this series holds here too: each EDI document answers exactly one question well. The 837's question is "here is the care that was delivered, here is why, and here is what we are claiming for it — adjudicate this." Building it from verified eligibility data, validating it before it leaves, and tracking every acknowledgment layer is the discipline we build SignalEDI around.

— Chris, founder of SignalEDI