Anyone who’s spent time around a health plan, a TPA, or a clearinghouse has heard the numbers thrown around like shorthand — “the 837 didn’t map right,” “check the 835 for the CARC code,” “did the 834 file post?” They’re X12 EDI transaction sets, the standardized electronic formats the healthcare industry uses to move enrollment, claims, and payment data between plan sponsors, payers, providers, and clearinghouses. Once you know what each one carries, the shorthand stops being noise.
Here’s the easiest way to hold it in your head: 834 is who’s covered. 837 is what happened. 835 is what we paid. Three different transactions, three different directions, three different jobs.
834 — who’s covered
The 834 (Benefit Enrollment and Maintenance) transaction flows from a plan sponsor — an employer, an association, a healthshare — to the payer or TPA administering the plan. It carries adds, changes, and terminations of coverage: a new hire enrolling, a dependent being added after a marriage, a termination when someone leaves. In plain terms, the 834 is the file that keeps the payer’s eligibility system in sync with who the sponsor actually says is covered, and when their coverage starts and stops.
This matters more than it sounds like it should. Every claim that comes in later gets checked against eligibility on the date of service — and that eligibility record exists because an 834 (or a manual equivalent) put it there. A stale or unprocessed 834 file is one of the most common root causes behind “why did this claim deny for no coverage” tickets. The 834 is upstream of almost everything else on this list.
837 — what happened
The 837 (Health Care Claim) transaction is the one most people mean when they say “the claim file.” It flows from a provider to a payer, and it comes in three variants depending on the type of care:
- 837P — professional claims. The electronic equivalent of the CMS-1500 form: office visits, specialist care, most outpatient professional services.
- 837I — institutional claims. The electronic equivalent of the UB-04 form: hospital stays, facility charges, inpatient and much outpatient facility billing.
- 837D — dental claims.
The 837 carries the actual detail of the encounter — who was seen, by whom, what procedure and diagnosis codes apply, what was billed. It’s the transaction that kicks off adjudication: eligibility check, benefit matching, pricing, cost-sharing, all the way through to a pay/deny/pend decision. Everything downstream in claims processing starts with an 837 landing in the system.
835 — what we paid
The 835 (Health Care Claim Payment/Advice), more commonly called the electronic remittance advice (ERA), flows the other direction — from payer back to provider. It’s the answer to the 837: what was paid, what was denied, and why, using standardized CARC (Claim Adjustment Reason Codes) and RARC (Remittance Advice Remark Codes) to spell out the reason for every adjustment. Before ERAs, this information arrived as a paper remittance a provider’s billing staff had to key in by hand. The 835 turns that into a structured file a practice management system can post automatically — which is exactly why payers that don’t generate clean 835s create real friction for the providers billing them.
The supporting cast: eligibility and status checks
Two more transaction pairs round out the day-to-day EDI traffic:
- 270/271 — the eligibility inquiry and response. A provider sends a 270 asking “is this patient covered, and for what?” before or at the time of service; the payer answers with a 271. This is what powers real-time eligibility checks instead of a phone call to verify benefits.
- 276/277 — the claim status request and response. A provider sends a 276 asking “where’s my claim?”; the payer answers with a 277. This is the EDI version of what used to be a hold-music phone call to a claims department.
The acknowledgments nobody talks about — until something breaks
Every one of these transactions needs to be confirmed as received and technically valid before anyone trusts what’s in it. That’s the job of the 999 (the current functional/implementation acknowledgment) and its predecessor 997, which confirm a file was received and passed structural validation. One level below that, the TA1 is the interchange acknowledgment — confirming the raw envelope of the file arrived intact, before anyone even checks what’s inside it. When an 837 batch seems to vanish into a payer’s system with no claims showing up, the 999/997/TA1 chain is usually the first place to look — it tells you whether the file was rejected before adjudication ever got a chance to see it.
How it all moves
In practice, none of these transactions usually travel directly between a provider’s system and a payer’s system. They route through a clearinghouse — a intermediary that validates formatting, translates between different provider and payer system requirements, and forwards clean transactions on. A clearinghouse relationship is less optional infrastructure and more just how the pipes work in this industry; a claims platform that doesn’t handle EDI natively is asking you to bolt on a separate clearinghouse contract and middleware layer just to receive claims in the first place.
Why this is worth understanding even if you’re not the one building the mappings
If you run a self-funded plan, a healthshare, or a TPA, you don’t need to hand-code an X12 parser to benefit from knowing this map. It tells you what to ask a vendor: does eligibility flow in automatically via 834, or does someone retype it? Does claim intake happen via 837, or does staff key paper claims by hand? Does the payer generate clean 835s so your providers get paid without a phone call? Those questions are really asking whether the platform speaks the industry’s native language or whether you’re the translation layer.
Claimaro handles 837 claim intake, 835 remittance generation, and eligibility transactions natively, with clearinghouse connectivity built into the platform rather than sold as a separate module — see how it fits into the full adjudication engine. And if you’re pricing out what it takes to run claims administration end to end, including the EDI and clearinghouse piece, here’s the full software stack a TPA needs.
