Technical / EDI

How to Read an 835 File: Segments, Loops and Balancing

An 835 is an X12 file organized as an envelope (ISA/GS/ST), a financial header (BPR) and reassociation trace (TRN), payer and payee loops (N1), then a claim payment loop (CLP) with service lines (SVC) and adjustments (CAS) carrying CARC/RARC codes, and finally provider-level adjustments (PLB). Reading it means following that hierarchy and confirming it balances.

If you have ever opened a raw 835 and seen a wall of segments separated by tildes, this is the map. The 835 is hierarchical: an envelope wraps a financial header, which wraps payer and payee identification, which wraps a loop per claim, which wraps a loop per service line. Knowing the key segments tells you exactly how each claim was paid and why, and lets you verify the file balances before it posts.

The envelope: ISA, GS, ST

Every X12 file opens with an interchange header (ISA) and functional group header (GS), and each transaction set inside starts with ST (with ST01 = 835). These carry sender and receiver IDs, control numbers and dates. You rarely need them for posting, but they are how the file is routed and acknowledged.

BPR and TRN: the money and the trace

BPR is the financial information segment: the total payment amount, the payment method (ACH, check, or non-payment for a zero-dollar remit), and the EFT effective date and banking details. TRN is the reassociation trace number - the value that ties this remittance to the actual EFT deposit or check, so you can match the 835 to the money that landed in the bank. Reassociation failures are a common posting headache, and TRN is how you solve them.

N1 loops: payer and payee

Two N1 loops identify the parties: the payer (loop 1000A) and the payee (loop 1000B), each with names and identifiers such as the payer ID and the provider's NPI or TIN. This is how the posting engine knows which payer's remittance it is working and which provider it belongs to.

CLP: the claim payment loop

The CLP segment opens the loop for one claim. Its key elements are the patient control number (CLP01, which matches the claim number you sent on your 837), the claim status code (CLP02), the total submitted charge (CLP03), the amount paid (CLP04), the patient responsibility (CLP05), and the payer's own claim control number (CLP07). That payer claim control number is what you cite on a corrected claim or an appeal, so it matters.

CAS: adjustments and group codes

CAS is where the money that was not paid is explained. Each CAS carries an adjustment group code, then up to six triplets of reason code, amount and quantity. The group codes are the first thing to read: CO (contractual obligations, the write-off you accept), PR (patient responsibility, what moves to the patient), OA (other adjustment), and PI (payer-initiated reductions). The reason code in each triplet is the CARC that says specifically why.

SVC: the service line loop

Under each claim, SVC segments carry the line-level detail: the procedure code, the line charge and the line paid amount, and units. Service lines can have their own CAS adjustments, so a claim can be partly paid and partly denied at the line level. Matching SVC lines back to the service lines on your original claim is what makes line-level posting accurate.

CARC and RARC: reason and remark

The CARC (claim adjustment reason code) in the CAS triplets tells you why an amount was adjusted or denied. RARC (remittance advice remark codes), carried in LQ segments and the MOA/MIA segments, add supplementary explanation. Together they are the starting point for denial management and for spotting underpayments against your fee schedule.

PLB: provider-level adjustments

PLB is the segment that trips people up. It carries adjustments that are not tied to a single claim: prior-period overpayment recoupments and offsets, interest, capitation payments, and forwarding balances. Because a PLB can move money independently of the claims listed, you cannot balance an 835 to the bank deposit without accounting for it.

Balancing an 835

A correct 835 balances at three levels. Each service line: line charge equals line paid plus line adjustments. Each claim: CLP charge equals paid plus all CAS adjustments plus patient responsibility. And the whole transaction: the BPR payment amount equals the sum of claim payments minus (or plus) the PLB provider-level adjustments. If any level does not tie out, the file has a problem and should be held rather than posted.

How MedXFlow AI agents handle this

MedXFlow's AI agents work directly with the EDI transactions behind this - 270/271, 837, 835, 276/277 and 278 - and fall back to payer-portal automation where a transaction is not supported, so the workflow runs whatever channel each payer uses.

Related resources

• See MedXFlow Payment Posting
• Claims submission (837)