The EDI 835, Decoded: Remittance Is How a Claim Becomes Money You Can Post

An 835 · Healthcare Benefit Payment / Remittance Advice is the payer's explanation of what happened to a claim after adjudication: what was paid, what was adjusted, what was denied, and why — claim by claim and line by line, in standardized codes that let a provider post payment automatically instead of reading a paper explanation of benefits. It is the closing document in the healthcare payment chain. Without it, a deposit is just money with no instructions.

I run SignalEDI. This series has walked the healthcare chain in order: the 270 · Eligibility Inquiry / 271 · Eligibility Response that checks coverage before care, the 837 · Claim that requests payment, and the 276 · Claim Status Inquiry / 277 · Claim Status Response that answers "whatever happened to that claim?" Today's document is the answer in money form. The 837 asks. The 835 settles.

What is an 835 · Remittance Advice, and how is it different from an 820?

The 835 explains a healthcare payment. The 820 · Payment Order / Remittance Advice, covered earlier in this series, is the general-purpose payment and remittance transaction used across industries. Healthcare chose its own, more specific version because a claim payment is never just "pay this amount."

A single check or electronic funds transfer can settle dozens or hundreds of claims at once, each paid differently: one in full, one reduced by a contractual adjustment, one split across a deductible and coinsurance, one denied entirely. The 835 carries that breakdown. It pairs, ideally, with the actual funds movement — the money may travel by EFT through the bank, while the 835 travels as the explanation that tells the receiving system how to apply it. When those two arrive out of sync, or only one arrives, posting stops. That separation — money in one channel, explanation in another — is the first operational fact about the 835, and the source of a familiar problem: the bank shows a deposit, the billing system shows nothing to post it against, and the team waits for a remittance file that went somewhere else.

How is an 835 actually structured?

At the top, the 835 identifies the payer, the payee, the payment method, the total paid amount, and the payment trace number that links the remittance to the funds transfer. Then it repeats, claim by claim. Each claim loop carries the claim as the payer adjudicated it: the amount billed, the amount paid on that claim, the patient responsibility, and the adjustments that explain the difference between billed and paid. Inside each claim, service-line loops can repeat the same breakdown per procedure — paid amount, adjustments, and the units and charges as adjudicated.

The adjustments are the language of the document, and they come in two standardized parts. Claim Adjustment Group Codes say whose adjustment it is and what kind: contractual obligation, patient responsibility, payer initiated, and a small set of others. Claim Adjustment Reason Codes — CARCs — say why: deductible amount, coinsurance amount, payment adjusted because the service was not deemed medically necessary, and hundreds more. A third layer, Remittance Advice Remark Codes, adds payer commentary when a reason code alone is not specific enough.

That three-part code system is what makes the 835 machine-postable. A human reads "denied." A system reads group code plus reason code plus remark code, and knows whether to write off the balance, move it to patient responsibility, bill a secondary payer, or queue the claim for correction and resubmission.

Why does the difference between billed and paid matter so much?

Because almost every claim is paid at something other than the billed amount, and the 835 is the only authoritative record of why. A contractual adjustment is not a loss to chase — it is the negotiated discount the provider agreed to, and it should be written off, not billed to the patient. Patient responsibility is the opposite: deductible, coinsurance, and copayment amounts identified in the 835 are exactly what the provider is allowed — and expected — to bill the patient for. Confusing those two categories in either direction is expensive. Bill a patient for a contractual write-off and you have a compliance problem and an angry patient. Write off true patient responsibility and you have quietly donated revenue no one will ever flag, because the books still balance.

Denials live in the same document. A denied claim line appears with zero paid and adjustment codes explaining the decision. That is why the 835, not a status inquiry, is the working document for denial management: it arrives claim by claim, in bulk, in a form a rules engine can triage — fixable coding issues to one queue, authorization issues to another, patient-responsibility transfers straight to statements.

Where do 835 workflows usually break?

The first break is the payment-remittance split described above: funds arrive, the 835 does not, or it arrives at a different enrollment, address, or mailbox than the payment. Teams that do not reconcile trace numbers daily discover the gap weeks later, at month-end close, with a bank balance that will not tie to the billing system.

The second break is treating the 835 as a report instead of data. Practices that print it, post it by hand, and file it lose everything the format was built for: automatic posting, automatic secondary billing, automatic patient-responsibility transfer, and denial queues generated from reason codes. Manual posting also introduces exactly the transcription errors the standardized codes exist to prevent.

The third break is ignoring what the codes are trying to teach. One denial reason code, repeated, is a training or documentation problem. A contractual adjustment that suddenly grows is a payer paying off-contract. The 835 is, accumulated over time, the most honest dataset a provider has about how payers actually behave — but only if someone trends the codes instead of just posting the payments.

Frequently asked questions

Is an 835 the same as an explanation of benefits?
It is the electronic, provider-facing counterpart. An explanation of benefits goes to the patient in plain language. The 835 · Healthcare Benefit Payment / Remittance Advice goes to the provider in standardized, machine-readable codes, designed for automatic posting to a billing system.

What is the difference between the 835 and the 820 · Payment Order / Remittance Advice?
The 820 is the general payment/remittance transaction used across industries. The 835 is healthcare-specific: it is organized around claims and service lines and explains adjudication with healthcare adjustment group codes, reason codes, and remark codes that the 820 does not carry in the same way.

Can an 835 cover more than one claim?
Yes — that is the norm. One 835 routinely explains payment for many claims settled by a single payment, with a claim loop for each and service-line detail inside it. The discipline is reconciliation: total paid across all claim loops must tie to the payment amount at the top, and to the funds that actually arrived.

Each EDI document in this series answers exactly one question well. The 835's question is "here is what we paid, here is what we did not, and here, in codes you can act on, is why." Posting it automatically, reconciling it to the money, and trending its reason codes is the discipline we build SignalEDI around.

— Chris, founder of SignalEDI