Reading an 835 remittance line by line

The 835 Health Care Claim Payment and Advice is where the payer tells you exactly what it did and why. Most practices never look at one directly, because the billing system posts it automatically and shows a summary. That works until a payment does not reconcile, and then the ability to read the raw transaction is the difference between an answer and a guess.

The shape of the document

An 835 nests four levels deep, and understanding the nesting is most of the battle:

1. The interchange and functional group, which identify sender, receiver and version.
2. The financial information: one payment, its total amount, its method and its trace number.
3. One or more claim payment loops, each covering a single claim you submitted.
4. Inside each claim, one service payment loop per service line.

The single most useful habit is to check that the levels reconcile upward. Every service line adjustment should roll into the claim, and every claim payment should roll into the financial total. When it does not, the discrepancy is almost always at a level nobody looked at.

The payment header

The BPR segment carries the total paid, the payment method and the effective date. The TRN segment carries the trace number, and it is the field that matters most operationally: it is what ties the electronic remittance to the deposit that shows up in the bank account. If a deposit cannot be matched to a remittance, the trace number is where you start.

The claim level

The CLP segment opens each claim loop and carries six things worth reading every time:

Status code 22 deserves particular attention. It is a reversal, meaning the payer is taking back a previous payment, usually to replace it with a corrected one. If your posting logic treats a reversal as an ordinary payment, the ledger will double count and the error can sit undetected for months.

The service line

The SVC segment gives the procedure code, the charged amount, the paid amount and the units. Beneath it, CAS segments explain every dollar of the difference, and this is where the real information lives.

Each CAS carries a group code and one or more reason codes. The group code determines who absorbs the amount, and getting it wrong is the most consequential posting error in the revenue cycle:

• CO, contractual obligation: your write-off under the contract. The patient cannot be billed.
• PR, patient responsibility: deductible, copay or coinsurance. This transfers to the patient.
• OA, other adjustment: usually coordination of benefits, pointing at a secondary payer.
• PI, payer initiated reduction: the payer's own decision, often appealable.

Charged equals paid plus every CAS amount on the line. If that equation does not balance, something was not posted.

Remark codes

LQ segments carry Remittance Advice Remark Codes, which qualify the reason codes above them. A CARC of 16 with a RARC of N286 is a specific, actionable instruction. A CARC of 16 alone is close to useless. Any posting process that discards remark codes is throwing away the part of the message that tells you what to do next.

Why posting automatically is not the same as posting blindly

Automatic posting is correct and worth doing. What it should never do is collapse detail. Keep the group code, the reason code and the remark code on every ledger entry. The moment they are summarized into a single adjustment amount, you lose the ability to answer the two questions that actually matter: why was this reduced, and can we appeal it?

Practices that preserve that detail can rank denials by dollars, find underpayments against contracted rates, and prove what a payer said on a date. Practices that do not are left reading a number and trying to remember.