X12 835 CAS Segment Guide: Fields, Format, and Testing Gotchas
CLP tells you what got paid. SVC tells you which line it was paid on. CAS is the segment that finally tells you why the number is lower than what was billed — and it is the segment nearly every auto-posting failure traces back to, because it can repeat, stack at different levels, and carry adjustment reasons a mapping table never learned to handle.
CAS (Claims Adjustment) is a repeatable segment in the X12 835 that reports one specific adjustment applied to a claim or service line. Each iteration groups three elements together: a group code that says who is responsible for the adjustment, a reason code that says why the adjustment happened, and a dollar amount. A single claim or line can carry several CAS segments, and a single CAS segment can carry up to six reason/amount pairs beyond the first.
The elements that actually matter in practice
Example
A synthetic contractual adjustment: group code CO (contractual obligation), reason code 45 (charge exceeds the fee schedule), $80.00 written off. Synthetic remittance data.
Where this trips people up
Test suites tend to generate one CAS segment per line with one reason/amount pair and call it done, because that is the shape that appears in the first few sample files anyone gets their hands on. Production remittances routinely stack two or three CAS segments on the same line — a contractual write-off, a patient coinsurance amount, and a third-party adjustment all landing on the same procedure — and a single CAS can itself carry multiple reason codes if the payer is explaining more than one thing at once. A posting engine that assumes exactly one CAS per line, or reads only the first reason/amount pair inside a CAS, will quietly drop dollars that never make it into the patient balance or the write-off bucket, and the file still looks perfectly valid.