Submit secondary and tertiary claims
When a patient has coverage from more than one health plan, each plan can pay part of the same claim. The plans pay in a set order: the primary payer adjudicates the claim first, then the secondary payer, then the tertiary payer. This process is called coordination of benefits (COB).
You must make a separate claim submission to each payer, in order. Each secondary or tertiary claim submission includes the same services and charges as the primary claim submission, plus how every prior payer adjudicated it.
For example, a patient has coverage through their employer's Cigna plan and through Medicare Part B. Cigna is the primary payer and Medicare is the secondary payer. You submit the claim to Cigna first. After you receive Cigna's 835 Electronic Remittance Advice (ERA), you submit the claim to Medicare with what Cigna paid and adjusted.
Paper claims have additional requirements. Visit Secondary and tertiary paper claims for details.
Workflow
Determine which payer is primary, secondary, and tertiary. Visit Determine payer order.
Submit the claim as you normally do, with the primary payer as the payer. You must bill the primary payer first, even if you expect a $0 payment. For example, the patient hasn't met their deductible or only their secondary plan covers the service.
The primary payer adjudicates the claim and sends an 835 Electronic Remittance Advice (ERA) with what it paid and adjusted. Wait to submit the secondary claim until you receive it.
Sometimes the primary payer forwards the claim to the secondary payer for you. The primary payer's ERA shows whether it forwarded the claim. Visit Check for crossover claims.
Submit the claim again to the secondary payer, and include the primary payer's adjudication details. Visit Prepare the claim.
After you receive each payer's ERA, submit the claim to the next payer with every prior payer's adjudication details.
Determine payer order
To bill each payer in order, you need to know the patient's other coverage and which payer is primary.
Find other coverage
If the patient gives you their coverage, such as on their insurance cards or intake forms, verify the coverage with eligibility checks and then determine the payer order. Otherwise, you can find the patient's other coverage with an eligibility check to the primary payer or an insurance discovery check.
Eligibility check: Some payers report other coverage they know about in the eligibility response:
- Stedi portal: Other payers appear in the Related entities column of the eligibility check's benefits table. To show only benefits that have related entities, use the Has related entities filter.
- API responses: Other payers appear in each benefit's related entities, as shown in the following examples.
The Real-Time Eligibility Check JSON endpoint returns the plans shape.
Look for entries in plans[].benefits.otherOrAdditionalPayer. The other payer is in the entry's relatedEntities array. The following example shows a commercial dental plan's response that names Medicare.
{
"coverageLevel": "INDIVIDUAL",
"service": {
"value": "30",
"definition": "Health Benefit Plan Coverage",
"system": "STC"
},
"relatedEntities": [
{
"type": "PAYER",
"name": { "organization": "MEDICARE" }
}
]
}Insurance discovery check: Run an insurance discovery check to search for coverage. Insurance discovery doesn't determine the payer order.
Set the payer order
You can establish primacy from a prior claim denial or by running a coordination of benefits (COB) check.
Prior claim denial
When you're sure the patient has only two active coverages and one of those payers has already denied a claim citing COB, the other payer is primary.
For example, a patient has active coverage with both Aetna and Cigna, and Aetna denied your claim citing COB. In this case, Cigna is primary:
- Resubmit the claim to Cigna and wait for adjudication.
- Bill Aetna with a secondary claim built from Cigna's 835 Electronic Remittance Advice (ERA). Use the payment and adjustment amounts exactly as the ERA reports them.
COB check
If you're not sure about primacy, run a COB check. COB checks determine primacy across a member's known coverage and report the billing order in the response. A COB check can also return payers you didn't know about. Always set the billing order from a COB response, not from an insurance discovery or eligibility response.
Original Medicare isn't part of the COB database, though many Medicare Advantage plans are. When a patient has Original Medicare, a COB check can't determine the billing order, so you must apply the primacy rules yourself. Visit Primacy rules for the guidelines Stedi follows, including how Medicare coordinates with other plans.
Submit claims in the payer order you determined. If you submit to the payers out of order, the payers can reject or deny the claims.
Check for crossover claims
Some payers automatically forward a claim to the next payer after they adjudicate it, creating a crossover claim. This is most common when Medicare forwards a claim to the patient's Medicare Supplement (Medigap) plan. Commercial payers rarely forward claims to each other. Before you submit a claim to the next payer, check the prior payer's 835 Electronic Remittance Advice (ERA) for a crossover. If the payer forwarded the claim, you don't need to submit it yourself.
To check whether the payer forwarded the claim, review the ERA's claim status code. It's in the claimPaymentInfo.claimStatusCode property in JSON, or in Loop 2100 CLP02 (Claim Status Code) in X12 EDI. Any of the following status codes means the payer forwarded the claim as a crossover claim:
19: Processed as Primary, Forwarded to Additional Payer(s)20: Processed as Secondary, Forwarded to Additional Payer(s)21: Processed as Tertiary, Forwarded to Additional Payer(s)
In the Stedi portal, check the Status code on the prior payer's Claim payment information card in the claim timeline. If that payer forwarded the claim, the status matches its position in the payer order. For example, a primary payer that forwarded the claim shows Processed as primary, forwarded. On the ERA's details page, the Claim payment information section shows the same status in its Status code column.
You can also find the crossover carrier, which is the payer that received the forwarded claim, in the crossoverCarrier object in JSON or in Loop 2100 NM1 (Crossover Carrier Name) with NM101 set to TT in X12 EDI. Confirm that the crossover carrier is the secondary payer you expected.
The crossover payer can also send its own 835 ERA and 277CA claim acknowledgments. You can sometimes use the information in a 277CA to run a real-time claim status check for the crossover claim.
The following example shows a Medicare Part B claim that Medicare processed as primary and forwarded to a Blue Cross Blue Shield plan.
{
"claimPaymentInfo": {
"patientControlNumber": "26030112345",
"claimStatusCode": "19", // Processed as primary, forwarded
"totalClaimChargeAmount": "150",
"claimPaymentAmount": "96.4",
"claimFilingIndicatorCode": "MB", // Medicare Part B
"payerClaimControlNumber": "2226083012345",
"facilityTypeCode": "11",
"claimFrequencyCode": "1"
},
"patientName": {
"lastName": "DOE",
"firstName": "JANE",
"memberId": "1EG4TE5MK73"
},
"crossoverCarrier": {
"organizationName": "HCSC-BCBS OF TEXAS-STD A & B", // Payer that received the claim
"centersForMedicareAndMedicaidServicesPlanId": "66666"
}
}When to enroll with the crossover payer
If the crossover payer isn't part of the same parent corporation as the payer that forwarded the claim, enroll the provider with the crossover payer for the transactions it requires:
- 835 ERAs: All payers require enrollment for ERAs. Enroll the provider for ERAs to receive the crossover payer's ERA.
- Claims: Use the Payer Network or the Payers API to check whether the crossover payer requires enrollment for claims. If it does, the crossover payer can pause processing the claim or reject it until the enrollment is live. If it rejects the claim, resubmit the claim after the enrollment is live.
Choose a submission method
If the prior payer didn't forward the claim as a crossover claim, you need to submit it yourself. You can submit secondary and tertiary claims through Stedi in the following ways:
- JSON APIs: Use one of the following endpoints:
- Professional claims: 837P JSON (Legacy). The Professional Claim JSON endpoint doesn't support secondary or tertiary claims.
- Dental claims: 837D JSON.
- Institutional claims: 837I JSON. This endpoint only supports secondary claims. To submit a tertiary institutional claim, use X12 EDI.
- X12 EDI APIs: Use one of the following endpoints:
- Professional claims: 837P Raw X12.
- Dental claims: 837D Raw X12.
- Institutional claims: 837I Raw X12.
- SFTP: Visit Submit claims through SFTP.
- Stedi portal: Use X12 EDI upload. The CMS-1500 form doesn't support secondary or tertiary claims. Visit the upload instructions for professional, dental, and institutional claims.
Prepare the claim
Complete the claim as you normally do for a professional, dental, or institutional claim. Then, make the following changes for the secondary or tertiary payer:
- Payer responsibility: Set
subscriber.paymentResponsibilityLevelCodetoS(Secondary) orT(Tertiary). For a fourth or later payer, useA(Payer Responsibility Four) throughH(Payer Responsibility Eleven). - Patient Control Number (PCN): Set
claimInformation.patientControlNumberto a new, unique PCN. Don't reuse the PCN from the primary claim. Stedi groups submissions with the same PCN into one claim, so reusing the PCN adds the secondary claim to the primary claim's timeline as a resubmission. - Prior payer information: Add one object to
claimInformation.otherSubscriberInformationfor each prior payer. For institutional claims,otherSubscriberInformationis a single object, so you can only add one prior payer. In each object, set:paymentResponsibilityLevelCodeto the payer's position in the payer order, such asPfor the primary payer.otherPayerName.otherPayerIdentifierto the payer's ID.
- Adjudication details: Add each prior payer's payments, adjustments, and payment dates from its 835 Electronic Remittance Advice (ERA). Then, make sure the claim balances. Visit Add prior adjudication details and Balance the claim.
Add prior adjudication details
The claim must include each prior payer's adjudication details: what the payer paid, what it adjusted, and when it paid.
Keep the following in mind when you add the ERA's adjudication details to your claim:
- Use the adjudicated procedure code and modifiers. If the payer paid a different procedure code than you billed, use the code and modifiers the payer paid, not the ones you billed.
- Copy every adjustment, including patient responsibility. Include every adjustment group code, reason code, and amount exactly as the ERA reports them, including patient responsibility (
PR) adjustments. Leaving outPRadjustments is a common reason claims don't balance.
The following sections show the adjudication details to get from the ERA and add to the claim.
Payment
The payment date is the day the prior payer paid the claim: the check or electronic funds transfer (EFT) date. Where you add it in the claim depends on whether the ERA includes service line details.
Get the payment date from the ERA:
Add it to one of the following places in the claim:
- If the ERA includes service line details:
serviceLines[].lineAdjudicationInformation[].adjudicationOrPaymentDate, for each service line - If the ERA doesn't include service line details:
claimInformation.otherSubscriberInformation[].otherPayerName.otherPayerAdjudicationOrPaymentDate
The following example shows a primary payer's ERA reporting a January 26, 2026, payment date:
{
"financialInformation": {
"checkIssueOrEFTEffectiveDate": "20260126"
}
}The ERA includes service line details, so the secondary claim includes the date on the service line:
{
"serviceLines": [
{
"lineAdjudicationInformation": [
{
"adjudicationOrPaymentDate": "20260126"
}
]
}
]
}Claim
The claim details are the total amount the prior payer paid on the claim, across all service lines, and its claim-level adjustments. For Medicare, they also include any inpatient or outpatient adjudication information.
Copy each value from the ERA's transactions[].detailInfo[].paymentInfo[] object to the corresponding property in the claim's claimInformation.otherSubscriberInformation.
Add one object to otherSubscriberInformation for each prior payer. For institutional claims, otherSubscriberInformation is a single object, so you can only add one prior payer.
| Value | ERA paymentInfo[] | Claim otherSubscriberInformation[] |
|---|---|---|
| Amount the payer paid on the claim | claimPaymentInfo.claimPaymentAmount | payerPaidAmount |
| Claim-level adjustments | claimAdjustments[] | claimLevelAdjustments |
| Medicare outpatient adjudication | outpatientAdjudication | medicareOutpatientAdjudication |
| Medicare inpatient adjudication (institutional claims only) | inpatientAdjudication | medicareInpatientAdjudication |
The following example shows a primary payer's ERA reporting a $65.52 payment on the claim:
{
"claimPaymentInfo": {
"claimPaymentAmount": "65.52"
}
}The secondary claim includes that amount as the primary payer's paid amount:
{
"claimInformation": {
"otherSubscriberInformation": [
{
"payerPaidAmount": "65.52"
}
]
}
}Service line
The service line details are the prior payer's results for each service line: the amount it paid, the procedure code and units it paid for, and its adjustments to the line. This includes patient responsibility.
Copy each value from the ERA's service lines, in transactions[].detailInfo[].paymentInfo[].serviceLines[], to the corresponding property in the lineAdjudicationInformation array for the same service line in your claim.
Add one object to the array for each prior payer, and set its otherPayerPrimaryIdentifier to the prior payer's ID. The ID must match the payer ID in that payer's otherSubscriberInformation[].otherPayerName.otherPayerIdentifier.
| Value | ERA servicePaymentInformation | Claim lineAdjudicationInformation[] |
|---|---|---|
| Amount the payer paid on the service line | lineItemProviderPaymentAmount | serviceLinePaidAmount |
| Adjudicated procedure code | adjudicatedProcedureCode | procedureCode |
| Procedure code qualifier | productOrServiceIDQualifier |
|
| Adjudicated procedure modifiers | adjudicatedProcedureModifierCodes | procedureModifier |
| Revenue code (institutional claims only, required) | nationalUniformBillingCommitteeRevenueCode | serviceLineRevenueCode |
| Paid units | unitsOfServicePaidCount |
|
| Service line adjustments | serviceAdjustments[], in the service line instead of servicePaymentInformation |
|
| Remaining patient liability | The total of the service line's PR (Patient Responsibility) adjustments in serviceAdjustments[] | remainingPatientLiability |
The following example shows a primary payer's ERA reporting a $65.52 payment, a $21.84 contractual adjustment, and $21.84 of patient responsibility on a $109.20 service line:
{
"servicePaymentInformation": {
"productOrServiceIDQualifier": "HC",
"adjudicatedProcedureCode": "90837",
"adjudicatedProcedureModifierCodes": ["95"],
"lineItemProviderPaymentAmount": "65.52",
"unitsOfServicePaidCount": "1"
},
"serviceAdjustments": [
{
"claimAdjustmentGroupCode": "CO",
"adjustmentReasonCode1": "45",
"adjustmentAmount1": "21.84"
},
{
"claimAdjustmentGroupCode": "PR",
"adjustmentReasonCode1": "2",
"adjustmentAmount1": "21.84"
}
]
}The secondary claim includes the same payment and adjustments in the service line's lineAdjudicationInformation, plus the $21.84 of patient responsibility in remainingPatientLiability. Each ERA adjustment's numbered reason codes and amounts become adjustmentDetails objects:
{
"lineAdjudicationInformation": [
{
"otherPayerPrimaryIdentifier": "62308",
"serviceIdQualifier": "HC",
"procedureCode": "90837",
"procedureModifier": ["95"],
"serviceLinePaidAmount": "65.52",
"paidServiceUnitCount": "1",
"claimAdjustmentInformation": [
{
"adjustmentGroupCode": "CO",
"adjustmentDetails": [
{
"adjustmentReasonCode": "45",
"adjustmentAmount": "21.84"
}
]
},
{
"adjustmentGroupCode": "PR",
"adjustmentDetails": [
{
"adjustmentReasonCode": "2",
"adjustmentAmount": "21.84"
}
]
}
],
"adjudicationOrPaymentDate": "20260126",
"remainingPatientLiability": "21.84"
}
]
}Balance the claim
The amounts in a secondary or tertiary claim must add up to its total charges. To balance a secondary or tertiary claim:
-
Copy every payment and adjustment from each prior payer's ERA. Follow the instructions in Add prior adjudication details.
-
Ensure the total charge equals the primary payer's paid amount plus all of its claim-level and service line adjustments.
For example, the example claim balances because its $109.20 charge equals Cigna's $65.52 payment, plus a $21.84 contractual adjustment, plus $21.84 of patient responsibility.
-
Ensure each service line's charge equals the sum of the following amounts:
- What every prior payer paid on the line
- Every prior payer's adjustments, except patient responsibility (
PR) adjustments - The most recent prior payer's
PRadjustments
For a tertiary claim, use the
PRadjustments from the secondary payer's ERA, not the primary payer's. The secondary payer's payment and adjustments already account for the primary payer's patient responsibility.
Example: balanced tertiary service line
The following example shows the service line from a tertiary professional claim. The line includes adjudication details from both prior payers:
- Cigna (primary payer, payer ID
62308): Paid $60, with a $20 contractual adjustment (CO) and $20 of patient responsibility (PR). - Aetna (secondary payer, payer ID
60054): Adjudicated Cigna's $20 of patient responsibility. It paid $15 and left $5 of patient responsibility (PR).
To balance the service line, add Cigna's $60 payment and $20 contractual adjustment, and Aetna's $15 payment and $5 of patient responsibility. The total is $100, which matches the line item charge amount.
The total doesn't include Cigna's $20 of patient responsibility, because Aetna paid $15 of that $20 and the patient now owes $5. Adding Cigna's original $20 of patient responsibility to the total would be incorrect, because it would count that amount twice.
The tertiary claim's service line includes one lineAdjudicationInformation object for each prior payer. The otherPayerPrimaryIdentifier in each object is the payer's ID.
{
"professionalService": {
"lineItemChargeAmount": "100.00",
"procedureIdentifier": "HC",
"procedureCode": "90837"
},
"lineAdjudicationInformation": [
{
"otherPayerPrimaryIdentifier": "62308",
"serviceLinePaidAmount": "60.00",
"serviceIdQualifier": "HC",
"procedureCode": "90837",
"paidServiceUnitCount": "1",
"claimAdjustmentInformation": [
{
"adjustmentGroupCode": "CO",
"adjustmentDetails": [
{ "adjustmentReasonCode": "45", "adjustmentAmount": "20.00" }
]
},
{
"adjustmentGroupCode": "PR",
"adjustmentDetails": [
{ "adjustmentReasonCode": "2", "adjustmentAmount": "20.00" }
]
}
],
"adjudicationOrPaymentDate": "20260126"
},
{
"otherPayerPrimaryIdentifier": "60054",
"serviceLinePaidAmount": "15.00",
"serviceIdQualifier": "HC",
"procedureCode": "90837",
"paidServiceUnitCount": "1",
"claimAdjustmentInformation": [
{
"adjustmentGroupCode": "PR",
"adjustmentDetails": [
{ "adjustmentReasonCode": "2", "adjustmentAmount": "5.00" }
]
}
],
"adjudicationOrPaymentDate": "20260216"
}
]
}Balancing rejections
Stedi rejects claims that don't balance. It checks the claim total and each service line separately, so one missing adjustment can cause more than one message. For example, if a secondary claim leaves out one of the primary payer's adjustments, the rejection includes messages like the following:
Coordination of Benefits (COB) balancing failed. For line 1, payer 62308's paid amount $65.52 plus adjustments $21.84 do not equal the prior balance of $109.20. Correct and resubmit.
Coordination of Benefits (COB) balancing failed. The total charged amount of $109.20 does not equal the sum of the paid amount of $65.52 and all adjustment amounts of $21.84. Correct and resubmit.Claims typically don't balance for one of the following reasons:
- A missing adjustment: The claim leaves out one of the prior payer's adjustments, such as the patient responsibility (
PR) adjustment. - A missing payment: The claim leaves out the prior payer's payment for one or more service lines.
- No prior payer details: The claim names the prior payer but has none of its payments or adjustments. This happens when you submit it before you receive the prior payer's ERA, or when you bill payers out of order.
If the claim doesn't include the prior payer at all, Stedi rejects it for a different reason, with the message "The Primary Payer information is missing."
For a worked example of each reason in a secondary claim, visit How to balance COB claims on the Stedi blog.
Example: secondary professional claim
The following example shows a secondary professional claim. The patient has coverage through their employer's Cigna plan and through Medicare Part B. Cigna is the primary payer and Medicare is the secondary payer. Cigna paid $65.52 of the $109.20 claim, with a $21.84 contractual adjustment and $21.84 of patient responsibility.
The secondary claim keeps the primary claim's provider, patient, diagnosis, and service line details, with the following changes:
- Payer: The claim goes to Medicare New York Part B Upstate (payer ID
13282). The subscriber's member ID is the patient's Medicare Beneficiary Identifier (MBI). - Payer responsibility: The subscriber's payer responsibility is
S(Secondary). - Patient Control Number (PCN): The claim has a new, unique PCN, so it appears as a separate claim in the Stedi portal instead of as a resubmission of the primary claim.
- Prior payer information: The claim names Cigna (payer ID
62308) as the primary payer and includes the patient's Cigna member ID. - Adjudication details: The claim includes Cigna's payment, adjustments, and payment date from its ERA.
- Medicare details: Because Medicare is the secondary payer, the claim filing code is
MB(Medicare Part B) and the insurance type code is12(Medicare Secondary Working Aged Beneficiary or Spouse with Employer Group Health Plan).
The claim balances because its $109.20 charge equals Cigna's $65.52 payment, plus the $21.84 contractual adjustment, plus $21.84 of patient responsibility.
The following request body for the 837P JSON (Legacy) endpoint shows the secondary claim:
{
"tradingPartnerName": "Medicare New York Part B Upstate",
"tradingPartnerServiceId": "13282",
"usageIndicator": "P",
"billing": {
"address": {
"address1": "123 Some St",
"address2": "Floor 1",
"city": "A City",
"postalCode": "123451234",
"state": "NY"
},
"contactInformation": {
"name": "Test Data Health Services, Inc.",
"phoneNumber": "5553334444"
},
"employerId": "123456789",
"npi": "1999999984",
"organizationName": "Therapy Associates",
"providerType": "BillingProvider",
"taxonomyCode": "207PH0002X"
},
"claimInformation": {
"benefitsAssignmentCertificationIndicator": "Y",
"claimChargeAmount": "109.20",
"claimFilingCode": "MB",
"claimFrequencyCode": "1",
"healthCareCodeInformation": [
{
"diagnosisCode": "F1111",
"diagnosisTypeCode": "ABK"
}
],
"otherSubscriberInformation": [
{
"benefitsAssignmentCertificationIndicator": "Y",
"claimFilingIndicatorCode": "CI",
"individualRelationshipCode": "18",
"insuranceGroupOrPolicyNumber": "3335555",
"otherPayerName": {
"otherPayerOrganizationName": "Cigna",
"otherPayerIdentifierTypeCode": "PI",
"otherPayerIdentifier": "62308"
},
"otherSubscriberName": {
"otherInsuredQualifier": "1",
"otherInsuredLastName": "Anon",
"otherInsuredFirstName": "John",
"otherInsuredIdentifierTypeCode": "MI",
"otherInsuredIdentifier": "U7777788888"
},
"payerPaidAmount": "65.52",
"paymentResponsibilityLevelCode": "P",
"releaseOfInformationCode": "Y"
}
],
"patientControlNumber": "<NEW-UNIQUE-PCN>",
"placeOfServiceCode": "02",
"planParticipationCode": "A",
"releaseInformationCode": "Y",
"serviceFacilityLocation": {
"address": {
"address1": "1234 Other St",
"city": "A City",
"postalCode": "123451234",
"state": "NY"
},
"npi": "1999999984",
"organizationName": "Smith Associates"
},
"serviceLines": [
{
"lineAdjudicationInformation": [
{
"otherPayerPrimaryIdentifier": "62308",
"serviceLinePaidAmount": "65.52",
"serviceIdQualifier": "HC",
"procedureCode": "90837",
"procedureModifier": ["95"],
"paidServiceUnitCount": "1",
"claimAdjustmentInformation": [
{
"adjustmentGroupCode": "CO",
"adjustmentDetails": [
{
"adjustmentReasonCode": "45",
"adjustmentAmount": "21.84"
}
]
},
{
"adjustmentGroupCode": "PR",
"adjustmentDetails": [
{
"adjustmentReasonCode": "2",
"adjustmentAmount": "21.84"
}
]
}
],
"adjudicationOrPaymentDate": "20260126",
"remainingPatientLiability": "21.84"
}
],
"professionalService": {
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": ["1"]
},
"lineItemChargeAmount": "109.20",
"measurementUnit": "UN",
"procedureCode": "90837",
"procedureIdentifier": "HC",
"procedureModifiers": ["95"],
"serviceUnitCount": "1"
},
"providerControlNumber": "111222333",
"renderingProvider": {
"firstName": "Jane",
"lastName": "Smith",
"npi": "1999999984",
"providerType": "RenderingProvider",
"taxonomyCode": "207PH0002X"
},
"serviceDate": "20260105"
}
],
"signatureIndicator": "Y"
},
"receiver": {
"organizationName": "Stedi"
},
"submitter": {
"contactInformation": {
"name": "Test Data Health Services, Inc.",
"phoneNumber": "5552223333"
},
"organizationName": "Test Data Health Services, Inc.",
"submitterIdentification": "0000001"
},
"subscriber": {
"address": {
"address1": "2222 Random St",
"city": "A City",
"postalCode": "123450000",
"state": "NY"
},
"dateOfBirth": "19580101",
"firstName": "John",
"gender": "M",
"insuranceTypeCode": "12",
"lastName": "Anon",
"memberId": "2AB3CD4EF56",
"paymentResponsibilityLevelCode": "S"
}
}