COB chaining (2320 CAS / AMT*F2)

Outcome

When a primary payer adjudicates, the platform automatically generates the correct secondary 837 with 2320 CAS, 2320 AMT*F2, and the per- line 2430 SVD/CAS/DTP*573 loops the secondary payer requires — and when the secondary adjudicates, the tertiary chain extends without operator intervention.

Prerequisites

A member with multiple coverages (primary, secondary, sometimes tertiary). The primary's 835 has been parsed and posted (6.2 — Posting & thresholds).

Why COB exists in the EDI layer

When we bill a secondary payer, the secondary needs to know what the primary paid and adjusted. They need this in a specific format inside the 837 — the 2320 CAS for claim-level adjustments, 2320 AMT*F2 for patient amounts, and 2430 SVD per service line. A secondary 837 that omits these loops is rejected (STC01 = A8) by every well-behaved secondary payer.

The platform builds these automatically from the primary's posted remittance. EDI staff need to know what the loops look like to debug when a secondary rejects.

2320 — Other Subscriber

The 2320 loop sits inside the 2000B (subscriber) hierarchy of the secondary 837. It carries the prior payer's adjudication summary:

SBR*S*18*GRP12345**MA*****MC~     (other subscriber relationship + filing indicator)
CAS*CO*45*100.00**253*5.00~       (claim-level adjustments from primary)
AMT*F2*125.00~                     (patient amount paid to the primary)
AMT*EAF*250.00~                    (amount owed by the patient)
DMG*D8*19800101*F~                 (other subscriber demographics)
OI***Y***Y~                        (other insurance coverage indicator)
NM1*IL*1*DOE*JANE****MI*ABC123~   (other subscriber name)

Element	Meaning
SBR01	S Secondary, T Tertiary.
SBR02	18 Subscriber (relationship).
SBR03	Group / policy number (primary plan).
SBR05	Filing indicator (MA, MB, MC, 12, etc.).
SBR09	Insurance type code (MC Medicaid, MA Medicare A).

2330 — Other Payer

Inside the 2320, the 2330 loop names the prior payer:

NM1*PR*2*ANTHEM PPO*****PI*60054~
N3*1234 PAYER LANE~
N4*COLUMBUS*OH*43215~
DTP*573*D8*20260115~                (date of adjudication)
REF*F8*ANTHEM-CC-99887766~         (other payer claim control number)

DTP*573 is critical — it tells the secondary when the primary adjudicated. Without it, secondary payers reject as untimely.

REF*F8 carries the primary's claim control number (echoes CLP07 from the primary's 835).

2430 — Line Adjudication

For each service line in 2400, the secondary 837 carries a 2430 with the primary's per-line decision:

SVD*ANTHEM PPO*80.00*HC:99213*  *1~          (SVD per primary)
CAS*CO*45*20.00~                              (line-level CAS from primary)
DTP*573*D8*20260115~                          (line adjudication date)

SVD is the Service Line Adjudication segment — it echoes what the primary paid for this line. CAS repeats per-line adjustments from the primary's 835 line-level CAS. DTP*573 is the adjudication date.

How the platform builds them

The snapshot service writes per-claim and per-line remittance_adjustment records with the original CAS triplets, the AMT amounts, and the adjudication date. The 837 builder reads them when constructing the secondary claim.

The full chain is automatic; operator awareness is for diagnosis only.

Tertiary

The same machinery handles the secondary → tertiary handoff. When the secondary's 835 lands and posts, the snapshot service records the secondary's adjustments alongside the primary's. The tertiary 837 then emits two 2320 loops — one for primary, one for secondary — with each loop's own 2330 payer block.

Steps to debug a secondary rejection

A secondary rejection that cites missing COB context (STC01 = A8, status 21 "Missing or invalid information"):

1. Open the secondary 837 at /transactions/:id. Walk to the 2320 loop in the segment trace.

2. Confirm 2320 segments are present. If absent, the snapshot was empty — verify the primary 835 posted before the secondary built.

3. Confirm 2320 CAS amounts match the primary 835. If they differ, the snapshot captured a stale primary view.

4. Confirm DTP*573 carries the primary adjudication date (not today's date). Secondary payers reject when this is missing or plausibly wrong.

5. Confirm REF*F8 carries the primary CLP07. Without it, secondary cannot cross-reference.

6. If everything looks right, the rejection is content-based, not COB-format-based — escalate to the secondary payer.

Validation

Check	Expected
Secondary claim built within minutes of primary 835 posting	Yes.
2320 loop matches primary 835 line for line	Yes.
DTP*573 matches primary adjudication date	Yes.
Tertiary chain extends after secondary 835 posts	Yes — two 2320 loops in the tertiary.

Troubleshooting

Symptom	Cause	Fix
Secondary 837 has empty 2320 loops	Primary 835 was DENIED or PENDED, not paid	The platform resumes the chain when primary resolves to PAID/PARTIAL; nothing for operator to do.
Tertiary built but excludes the right payer	Same payer appears twice in member coverage	The platform refuses to bill the same payer twice — confirm member coverage list.
DTP*573 carries today's date	Snapshot service did not record adjudication date	Likely a parser bug; file an issue with the primary 835.
Secondary cites OA-94 "processed in excess of charges"	Sum of primary paid + 2320 CAS exceeds total billed	Inspect the snapshot — usually a duplicate CAS captured at both claim and line level.

Next

3.1 — 837P outbound