X12 837D CLM Segment Guide: Fields, Format, and Testing Gotchas
CLM looks identical on paper whether the claim is medical or dental — same segment ID, same composite structure. But a dental practice management system feeding CLM05 with a medical place-of-service code, or a claim submitter identifier scheme borrowed wholesale from a professional billing pipeline, produces a claim that parses fine and still gets kicked back for review because nothing about it reads as dental.
CLM (Claim Information) is the core segment of an X12 837D dental claim — it carries the same submitter identifier, total charge amount, and facility/frequency composite as its 837P counterpart, but the values populating those fields differ because dental claims almost always originate from a dental office setting rather than a physician's office or facility, and tooth-level detail lives elsewhere in the claim rather than in CLM itself.
The elements that actually matter in practice
Example
Composite 11:B:1 breaks down as facility code 11 (office), frequency qualifier B, frequency code 1 (original claim) — the same office-based location code that dominates dental submissions, unlike 837P where facility codes vary more widely by specialty. Synthetic claim data.
Where this trips people up
Teams that stand up 837D by cloning an existing 837P mapping often leave CLM05-1 pointing at whatever facility code table the medical pipeline used, which can default to a code that doesn't match a dental office setting. The segment still validates syntactically, but it reads as inconsistent with the rest of the claim — a dental procedure code set (from the SV3 segments) paired with a facility code that implies something else — and that mismatch is a common trigger for payer front-end edits to pull the claim for manual review instead of auto-adjudicating it.