X12 835 SVC Segment Guide: Fields, Format, and Testing Gotchas
The SVC segment is where a remittance advice actually says what a payer decided about a single line of a claim: what was billed, what was paid, and how many units it covered. If your test data generator gets SVC wrong, every downstream reconciliation report inherits the error.
SVC (Service Payment Information) is a loop-level segment in the X12 835 that reports payment detail for one service line: the procedure billed, the charge submitted, the amount the payer actually paid, the revenue code when applicable, units paid, and — when the payer substituted a different procedure code than what was billed — the original code and units in SVC06 and SVC07.
The elements that actually matter in practice
Example
A synthetic office-visit line: billed as 99213 with a modifier 25 at $125, but the payer downcoded it to 99212 and paid $100 for 1 unit — SVC06 preserves the original 99212 code the provider actually submitted before the downcode.
Where this trips people up
Teams frequently assume SVC02 minus SVC03 always equals the sum of the CAS adjustment amounts that follow the SVC segment, then build reconciliation logic on that assumption. It usually does — but not when a downcode changes the allowed amount basis, or when multiple CAS segments at different levels touch the same dollars. Test data generators need to produce cases where SVC03 plus every associated CAS amount does not cleanly foot to SVC02, so reconciliation code has to handle the mismatch instead of silently swallowing it. The other common miss is skipping SVC06/SVC07 entirely in test fixtures — if your synthetic data never includes a downcoded or bundled line, your parser's handling of that composite never gets exercised until it breaks in production.