COB Claims Testing: How to Generate Coordination of Benefits Scenarios
COB claims are the most commonly undertested scenario in healthcare EDI — and the most common source of go-live failures. Here is how to generate and test the full COB matrix before you go live.
Why COB is always undertested
Coordination of Benefits claims are complex to construct correctly — and in most test environments, nearly impossible to test thoroughly. A COB 837 requires a different SBR loop structure, additional OI (Other Insurance) loops, and MOA segments that reference the primary payer's adjudication. The secondary 835 needs to reference the primary payment amount using OA-23 adjustment reason codes.
To test COB end to end, you need a member with dual coverage, a primary 837, a primary 835 with the adjudication results, and then a secondary 837 built from those results — all with consistent member IDs, provider NPIs, and ICN references across every transaction.
Hand-building that chain takes hours. So most teams test it once with a single scenario and hope it works. It usually doesn't.
The X12 segments that define COB claims
The seven COB scenarios you must test
Synthibase generates COB 837 claims from a member registry where each member can have primary and secondary coverage — the OI loops, MOA segments, and CAS adjustments are all built correctly from the same member record. Start a free trial →