Coordination of Benefits in EDI: How COB Works in Practice
When a patient has more than one insurance plan, every claim becomes a puzzle. Which payer pays first? How much does the secondary payer owe? How do you submit that information in a way that’s machine-readable and HIPAA-compliant?
The answer is Coordination of Benefits — and in the EDI world, COB has very specific mechanics you need to understand to get claims paid cleanly.
This post walks through how COB works in X12 EDI 837P and 837I transactions: the segments involved, the loops that carry primary payer data, and the real-world mistakes that cause secondary claims to reject.
What Is Coordination of Benefits?
Coordination of Benefits (COB) is the process of determining which insurance plan pays first (primary) and which pays second (secondary) when a patient has dual coverage.
Common COB scenarios include:
- A patient covered by both their own employer’s plan and a spouse’s plan
- A Medicare beneficiary with a Medigap supplemental policy
- A child covered by both parents’ employer plans
- An auto accident patient with health insurance and auto liability coverage
The payer that pays first is the primary payer. The payer that pays after the primary’s adjudication is the secondary payer. In some cases, a patient may have tertiary coverage as well.
Federal regulations — including the Medicare Secondary Payer (MSP) rules — govern which payer is primary in certain situations. Getting this wrong can mean claim denial, overpayment recovery, or compliance risk.
COB and the 837 Claim File
In EDI, COB information is carried within the 837P (Professional) or 837I (Institutional) claim transaction. You do not submit a separate file for secondary claims — you include the primary payer’s adjudication data directly in the 837 transaction sent to the secondary payer.
This means the secondary claim includes:
- The patient’s secondary insurance information (already in the standard 837 subscriber/dependent loops)
- The primary payer’s paid amount, adjusted amounts, and remark codes
- A flag indicating this is a COB claim
Let’s look at exactly how the X12 spec structures this.
Key X12 Loops for COB
Loop 2330 — Other Subscriber / Other Payer Information
The COB data in an 837 lives primarily in Loop 2330, which is the “Other Subscriber Information” section. This loop repeats for each additional payer beyond the one you’re billing.
The loop contains:
- 2330A — Other Subscriber Name (NM1 loop)
- 2330B — Other Payer Name (NM1 loop with payer information)
- 2330C through 2330H — Other Payer provider roles (rendering, referring, facility, etc.)
Within Loop 2330B, the OI segment (Other Insurance Coverage Information) and the MOA segment (Medicare Outpatient Adjudication) carry the critical COB flags.
Segment-Level Walkthrough
SBR — Subscriber Information (Loop 2000B)
Every 837 claim has an SBR segment in the subscriber loop. For COB claims, a second (or third) SBR appears within the claim loop (2320) to identify additional payers.
SBR*S*18*******CI*Breaking this down:
| Element | Value | Meaning |
|---|---|---|
| SBR01 | S | Payer responsibility — Secondary |
| SBR02 | 18 | Patient relationship to insured (Self) |
| SBR09 | CI | Claim filing indicator — Commercial Insurance |
For a tertiary claim, SBR01 would be T.
CAS — Claim Adjustment Segment
The CAS segment carries the adjustments the primary payer applied to the claim. This is how you tell the secondary payer: “The primary already reduced this by $X for contractual reasons.”
CAS*CO*45*150.00*
CAS*PR*3*25.00*CO*45*150.00— Contractual obligation, adjustment group CO, reason code 45 (charges exceed your contracted/legislated fee arrangement), amount $150.00PR*3*25.00— Patient responsibility, deductible, amount $25.00
The secondary payer uses this data to calculate what (if anything) they owe. Missing or incorrect CAS segments are one of the top causes of secondary claim rejection.
AMT — Claim Supplemental Information
The AMT segment provides dollar amounts related to the primary payer’s payment. Several AMT qualifiers are used in COB:
AMT*D*250.00
AMT*A8*175.00| Qualifier | Meaning |
|---|---|
| D | Primary payer’s paid amount |
| A8 | Primary payer’s allowed amount |
| EAF | Primary payer’s coinsurance amount |
OI — Other Insurance Coverage Information
The OI segment (within Loop 2320) specifies how benefits were assigned and whether other payers have already been billed.
OI***Y*B**Y| Element | Meaning |
|---|---|
| OI03 | Benefits assignment certification — Y (yes, benefits assigned) |
| OI04 | Medicare as secondary payer reason code |
| OI06 | Release of information — Y (yes, release authorized) |
MOA — Medicare Outpatient Adjudication (837I Only)
For institutional claims where Medicare is primary, the MOA segment carries Medicare-specific adjudication information:
MOA***MA02**This segment includes Medicare’s reason codes, the ESRD (End Stage Renal Disease) payment amount, and other payer-specific data. If you’re billing Medigap or Medicaid as secondary to Medicare, this segment is critical.
A Complete COB Claim Excerpt (837P)
Here’s a stripped-down example showing the COB-related segments in a secondary 837P claim:
ST*837*0001*005010X222A1
BPR*...
NM1*41*2*BILLING PROVIDER*****XX*1234567890
...
CLM*CLAIM001*500.00***...
...
SBR*S*18*******CI*
OI***Y***Y
NM1*IL*1*DOE*JANE****MI*XYZ123456789
NM1*PR*2*SECONDARY INSURANCE CO*****PI*54321
CAS*CO*45*150.00*
CAS*PR*3*25.00*
AMT*D*250.00
AMT*A8*400.00
...
SE*30*0001In plain English:
- Jane Doe had a $500 claim
- Primary payer allowed $400, wrote off $150 (CO-45), and applied $25 to deductible (PR-3)
- Primary paid $250 (AMTD250.00)
- Secondary is now being billed to cover the remaining $25 deductible (and potentially more, depending on the secondary’s benefits)
COB Claim vs. Crossover Claim
A common point of confusion: not all secondary claims are created equal.
Standard COB Claim
You receive the primary’s EOB/ERA, gather the adjudication data, and manually (or programmatically) build the secondary 837 with the CAS/AMT/OI data above.
Crossover Claim
Some primary payers — especially Medicare — automatically forward the claim to a known secondary payer. This is called a crossover. You don’t need to submit the secondary claim yourself; Medicare sends it to the Medigap or Medicaid payer directly.
When a claim crosses over, you’ll see a remark on the 835 ERA like MA18 (“claim has been submitted to another payer”). If you re-submit a crossover claim manually, you’ll get a duplicate denial.
Key rule: Check your ERA before submitting a secondary claim. Look for crossover indicators before you assume you need to re-bill.
Common COB Errors and How to Fix Them
1. Missing CAS Segments
Error: Secondary payer cannot calculate patient liability. Fix: Pull the primary’s 835 ERA. Map each adjustment line to a CAS segment. Every CO, PR, and OA adjustment from the primary needs to appear in the secondary 837.
2. Wrong SBR01 Value
Error: Claim routes to wrong payer sequence.
Fix: SBR01 must match the payer order: P = primary, S = secondary, T = tertiary. In a secondary claim, the payer you’re billing should have SBR01 = S in Loop 2320.
3. Primary Paid Amount Doesn’t Match ERA
Error: Secondary rejects for “COB amount discrepancy.” Fix: Use the exact paid amount from the primary’s 835 — not the billed amount, not the allowed amount. The AMT*D value must match the primary’s payment.
4. Submitting a Crossover as a Manual Claim
Error: Claim rejected as duplicate. Fix: Check your 835 for MA18 or similar crossover remarks before re-billing. If the primary already forwarded it, don’t touch it.
5. Incorrect Payer Responsibility Sequence
Error: Claim rejected because primary payer data is missing or incomplete. Fix: Make sure your NM1 segments in Loop 2330B accurately identify the primary payer (not the one you’re billing). The secondary payer needs to verify who paid first.
COB in the Context of Medicare
Medicare Secondary Payer (MSP) rules are the most complex COB scenario in healthcare billing. When Medicare is not the primary payer, you must:
- Determine the correct MSP reason code (Worker’s Comp, auto, employer group health plan, etc.)
- Bill the primary payer first
- Submit the secondary claim to Medicare with the primary’s adjudication data and the appropriate MSP qualifier in the SBR08 element
Medicare crossover programs handle many of these automatically for Medigap and Medicaid beneficiaries, but not all plans participate.
For Medicare Advantage (Part C) plans as secondary, the rules differ — you’re billing a private plan, not CMS directly, so standard COB rules apply.
Validating COB Claims Before Submission
Before you send a secondary 837, validate:
- Primary payer information in Loop 2330B is correct (NM1, REF, DTP segments)
- CAS segments present and complete for all adjustment groups
- AMT*D (primary paid amount) matches the primary’s 835
- OI segment has the correct release-of-information and assignment indicators
- SBR segments have the correct payer responsibility sequence
- No duplicate claim risk (check for crossover indicators on the primary ERA)
Running your 837 through a validator before submission catches structural errors that would cause rejection at the clearinghouse or payer level.
Summary
Coordination of Benefits in EDI is about giving the secondary payer exactly what it needs to calculate its obligation. That means:
- Correct payer sequencing in SBR segments
- Complete CAS segments with every primary adjustment
- Accurate AMT segments reflecting the primary’s payment
- OI and MOA segments correctly populated for benefit assignment and Medicare-specific scenarios
Get this right, and secondary claims process cleanly. Get it wrong, and you’re looking at denials, resubmissions, and delayed cash flow.
The mechanics are precise — but they’re learnable. And once you understand the loop and segment structure, diagnosing COB rejections becomes a matter of knowing where to look.
Ready to work with EDI files in your browser? Try EDI Paisan free — no install required.