835 inbound — parsing CLP, SVC, CAS, AMT

Outcome

The inbound 835 file (Electronic Remittance Advice) is parsed cleanly, every CLP loop maps to a known claim, every CAS row is decoded, every AMT amount is captured, and the structured result is ready for the posting flow.

Prerequisites

Scope	What it lets you do
edi.transaction.read	View transactions
edi.remittance.read	Inspect parsed 835 detail

A trading partner with 835 inbound capability (2.4 — Capabilities).

835 anatomy

Source: packages/x12/src/inbound/remittance-835.ts. Implementation convention: 005010X221A1.

ISA → GS → ST*835 → BPR (payment info)
TRN (trace number — payer's unique check / EFT reference)
DTM*405 (production date)
N1*PR (payer name)
N3 / N4 / PER / REF (payer address & contact)
N1*PE (payee name — typically our billing entity)
N3 / N4 / REF (payee address & TIN)
[LX] (one or more provider segments per ERA)
  Loop 2100 — Claim Payment
    CLP (claim payment info — billed, paid, status)
    CAS (claim-level adjustments, repeat as needed)
    NM1*QC (patient)
    [NM1*82] (rendering provider)
    [NM1*TT] (crossover carrier — for COB)
    REF (claim identifiers)
    DTM (claim dates — service period, claim received)
    [AMT] (claim-level amounts — F2 allowed, AU coverage, EAF underpaid)
    Loop 2110 — Service Payment Info
      SVC (service code, billed, paid, units)
      DTM*472 (service date)
      CAS (line-level adjustments)
      [REF] (line identifiers)
      [AMT] (line-level amounts — B6 allowed, KH deductible)
PLB (provider-level adjustments — accumulator changes outside any claim)
SE → GE → IEA

BPR — payment info

Read BPR first to know what the file is paying:

Element	Common values	Meaning
BPR01	I Information Only, H Notification Only, C Payment Accompanies, D Payment Only, U Split Payment, X Handling Party's Option	Transaction handling.
BPR02	(amount)	Payment amount.
BPR03	C Credit, D Debit	Credit / debit indicator.
BPR04	ACH ACH, BOP Financial Institution Option, CHK Check, FWT Federal Wire, NON Non-payment Data	Payment method.
BPR05	(when ACH)	ACH transaction code (CCP corporate credit, CTX corporate trade exchange).
BPR16	(effective date)	When the payment lands.

BPR01 = H files carry no money — they are pure remittance / denial information. The platform handles them identically except no AR reconciliation is run.

CLP — claim payment

CLP is one row per claim being paid (or denied) on this ERA. Every field matters:

Element	Meaning
CLP01	Patient control number — echoes our outbound CLM01. The primary key for matching.
CLP02	Claim status code: 1 Processed Primary, 2 Secondary, 3 Tertiary, 4 Denied, 19 Reversal, 22 Reversal of Previous Payment, 23 Not Our Claim — Forwarded
CLP03	Total billed (claim total).
CLP04	Total paid.
CLP05	Patient responsibility.
CLP06	Claim filing indicator code (MA Medicare Part A, MB Medicare Part B, MC Medicaid, 12 PPO, …).
CLP07	Payer claim control number — the payer's tracking ID. Save this for status inquiries.
CLP08	Facility type code (POS).
CLP09	Claim frequency code.
CLP10	Diagnosis-related group (DRG) code.
CLP11	DRG quantity.
CLP12	DRG percentage.

CLP02 = 4 (denied) requires special handling — see 6.2 — Splitting PR / CO / PI.

CAS — adjustments

CAS carries adjustments. Each CAS segment can hold up to 6 adjustments as triplets of (reason, amount, quantity):

CAS*CO*45*100.00**253*5.00~

Position	Value	Meaning
CAS01	CO	Group code
CAS02	45	Reason code (CARC)
CAS03	100.00	Amount
CAS04	(empty)	Quantity
CAS05	253	Reason code (next adjustment)
CAS06	5.00	Amount

Group codes: CO (contractual), PR (patient resp), PI (payer initiated), OA (other), CR (correction / reversal).

CAS appears at both the claim level (loop 2100) and the line level (loop 2110). When both are present, line-level CAS is typically the specific adjustment per line; claim-level CAS captures cross-line adjustments (e.g. interest, capitation reductions).

The full CARC list is large; the most common are documented at 8.3 — CARC/RARC quick-reference — though that page focuses on STC; for CAS reason codes consult the published adjustment-code list.

SVC — service line payment

One SVC per claim line, inside loop 2110.

SVC*HC:99213:HQ*100.00*80.00**1~

Element	Meaning
SVC01	Composite — code qualifier + procedure + modifiers. HC = HCPCS, WK = Advisory Codes (state-specific).
SVC02	Submitted charge for this line.
SVC03	Paid amount for this line.
SVC04	(Revenue code, for institutional).
SVC05	Units paid.
SVC06	(Composite — original procedure when the payer downcoded).
SVC07	Units submitted.

When SVC03 < SVC02 and there is no CAS on the line, the payer is silently rejecting part of the charge — flag for investigation.

AMT — supplemental amounts

AMT segments capture amounts not represented by the line / claim totals.

Qualifier	Meaning
AU	Coverage amount (allowed by patient's plan).
B6	Allowed amount (line level).
D8	Discount amount.
EAF	Amount owed by the patient.
F2	Patient amount paid.
F3	Per-day limit amount.
F4	Patient amount paid (alternative).
F5	Patient amount paid (yet another).
KH	Deductible amount.
T	Tax amount.

AMT*B6 (allowed amount) per service line is what drives the contracted-rate reconciliation — see 6.2.

PLB — provider-level adjustment

PLB rows carry adjustments outside any single claim — interest, take- backs, withholdings.

PLB*1234567890*20260131*WO:CLAIM12345*-50.00~

Element	Meaning
PLB01	Provider ID.
PLB02	Fiscal period date.
PLB03+	Adjustment identifier composite + amount.

Common adjustment qualifiers (PLB03:1):

Code	Meaning
WO	Overpayment recovery
FB	Forwarding balance
IR	Internal revenue
J1	Non-reimbursable
L6	Interest owed
WU	Unspecified recovery

A negative amount means the payer is taking money back; a positive amount means they are adding to the payment. The reconciliation flow applies PLB to the AR before claim-level posting.

Steps

The full flow is automated; operator awareness is for diagnosis only.

1. Inbound 835 file arrives via the partner's transport.

2. parseRemittance835() produces a structured ParsedRemittance object with every CLP / CAS / SVC / AMT / PLB.

3. The transaction record appears at /transactions with tx_type = 835. Click in for the segment trace and a Parsed view.

4. The response-processor dispatches the parsed remittance to the rcm-core posting flow — covered in 6.2 — Posting & thresholds.

Validation

Check	Expected
Inbound transaction has tx_type = 835	Yes.
Parsed view shows totals matching BPR02	Yes.
Every CLP01 matches an outbound claim's CLM01	Most should — exceptions become unmatched in the posting flow.
Sum of CLP04 + sum of PLB adjustments = BPR02	Yes — that's the file balance.

Troubleshooting

Symptom	Cause	Fix
Parse fails with "missing CLP"	Header-only ERA (BPR01 = H) with no claims	Expected for some informational files; no action.
CLP01 does not match any claim	Payer sent ERA for a claim from another tenant; or our submission used a different patient control number	Check claim history; if truly orphan, escalate to partner.
CAS triplets misaligned	Some payers emit fewer than 3 fields per triplet	Parser handles short triplets; if you see it produce wrong amounts, file an issue with the raw 835.
SVC03 < SVC02 with no CAS	Silent partial pay	Treat as a denied portion; create a denial record manually with OA-23 or contact payer.

Next

6.2 — Posting & thresholds