X12 837D SBR Segment Guide: Fields, Format, and Testing Gotchas

Jul 28, 2026 · 6 min read

SBR works the same way in dental claims as it does everywhere else in X12, but dental coverage is far more likely to sit on a completely separate plan from a patient's medical insurance — so a coordination-of-benefits test suite built around the assumption that primary and secondary payers share a subscriber ID structure will miss real dental COB scenarios entirely.

Quick answer

SBR (Subscriber Information) is a repeatable X12 837D segment, one occurrence per payer, that establishes the payer's payment sequence, the patient's relationship to the subscriber, the group or policy number, and the dental plan type for that payer.

The elements that actually matter in practice

SBR01 →

Payer Responsibility Sequence Number Code — P/S/T — primary, secondary, or tertiary payer for this dental claim

SBR02 →

Individual Relationship Code — how the patient relates to the subscriber — self, spouse, child, etc.

SBR03

Reference Identification — the group or policy number tied to the dental coverage, often different from the same subscriber's medical group number

SBR04

Name — the dental plan or program name, free text

SBR09 →

Claim Filing Indicator Code — the type of payer being billed — commercial dental, dental HMO, Medicaid dental, and so on

Example

Synthetic example Generated by Synthibase

SBR*P*19*GRP-DNT7731*BRIGHTSMILE DENTAL PLAN*****CI*

SBR01 = P marks this payer as primary, SBR02 = 19 marks the patient as the subscriber's child, and SBR09 = CI marks the plan as commercial dental insurance. Synthetic claim data.

Where this trips people up

Because a subscriber's dental plan and medical plan frequently come from two different insurers entirely — even when the same employer sponsors both — test data that borrows subscriber and group identifiers from an 837P medical fixture and drops them into an 837D SBR loop unmodified produces a claim that looks structurally fine but references coverage that doesn't actually exist on the dental payer's side. Build dental SBR loops from dental-specific group and plan data, not repurposed medical fixtures.

→

What is X12 837P? Complete Format and Field Guide

→

How to Write EDI Test Cases That Actually Catch Go-Live Failures

Generate synthetic dental COB scenarios automatically

Synthibase generates synthetic 837D claims with correctly sequenced SBR loops and dental-specific plan data across primary, secondary, and tertiary payers — no PHI, no borrowed medical fixtures.

Start free trial →

This page is written independently by Synthibase for testing and informational purposes. It is not an official publication of HL7 International or X12/Washington Publishing Company, and is not a substitute for reviewing the official standard or your trading partner's companion guide. See our Terms of Service for full legal terms.