Changelog

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include duplicate payer responsibility level codes.

Payer responsibility level codes, also called payment responsibility sequence number codes, indicate which payer is supposed to pay first, second, and so on. For example, a code of P indicates the primary payer. A code of S indicates the secondary payer.

The process of determining this order is known as coordination of benefits (COB). Payers use this information to process secondary and tertiary claims correctly.

If a claim lists more than one payer at the same responsibility level – for example, two primary payers – the payer may reject the claim, which can cause payment delays.

This edit – the industry’s term for an automated validation rule – catches the issue before it reaches the payer.

When this edit applies
A claim will fail this edit when:

• JSON API
  If you’re using one of Stedi’s JSON claim submission API endpoints, the edit fails if the subscriber.paymentResponsibilityLevelCode field and/or any claimInformation.otherSubscriberInformation.paymentResponsibilityLevelCode fields contain a duplicate value.

• X12
  If you’re using X12, the edit fails if Loop 2000B (Subscriber Hierarchical Level) and/or Loop 2320 (Other Subscriber Information) contain a duplicate SBR-01 (Payer Responsibility Sequence Number Code) value.

• Stedi portal
  You can’t fail this edit using the Stedi portal’s professional claim submission form. Currently, the form only supports claims to a single primary payer. Secondary and tertiary claims aren't supported.

This edit does not fail if a claim lists multiple payers with a responsibility level code of U (Unknown). A code of U doesn’t indicate a specific payment order, so duplicates are allowed.

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid payer responsibility submitted. Duplicate payer responsibility codes were detected: [P, S, S]. Payer responsibility values within a claim must be unique. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that don’t include a primary payer.

Every claim must include exactly one primary payer. For primary claims, this payer determines routing. For secondary and tertiary claims, payers use this information to determine coordination of benefits (COB) and adjudicate the claim correctly. If it’s missing, the payer may reject the claim, which can cause payment delays.

This edit – the industry’s term for an automated validation rule – catches the issue before it reaches the payer.

When this edit applies
A claim will fail this edit when:

• JSON API
  If you’re using one of Stedi’s JSON claim submission API endpoints, the edit fails if neither the subscriber.paymentResponsibilityLevelCode nor any claimInformation.otherSubscriberInformation.paymentResponsibilityLevelCode fields contains a value of P (Primary) in the request.

• X12
  If you’re using X12, the edit fails if neither Loop 2000B (Subscriber Hierarchical Level)) nor Loop 2320 (Other Subscriber Information) contains an SBR-01 (Payer Responsibility Sequence Number Code) value of P (Primary).

• Stedi portal
  You can’t fail this edit using the Stedi portal’s professional claim submission form. Currently, the form only supports claims to a single primary payer. Secondary and tertiary claims aren't supported.

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The Primary Payer information is missing. A primary payer must be indicated in either the Subscriber or Other Subscriber loops of the claim. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Resolution tips
For secondary and tertiary claims, include a single primary payer in other subscriber information:

• JSON API
  If you’re using one of Stedi’s JSON claim submission API endpoints, you can provide this information in a claimInformation.otherSubscriberInformation object with a paymentResponsibilityLevelCode of P (Primary) in the request.

• X12
  If you’re using X12, you can provide this information in Loop 2320 (Other Subscriber Information) with an SBR-01 value of P (Primary).

In the coming weeks, Stedi will normalize all X12 271 eligibility responses to use a standard set of delimiters.

If you do not parse the raw X12 271 and only parse Stedi's JSON response, this change will not impact you.

What are X12 delimiters?
In X12, delimiters are characters that separate the parts of a transaction set. Each transaction set has four types of delimiters:

• Element Separator – Separates fields

• Repetition Separator – Separates repeat values

• Component Element Separator – Separates sub-elements

• Segment Terminator – Ends each segment

These delimiters are defined in the ISA segment and can vary across transaction sets.

How it works today
Stedi currently passes through whatever X12 delimiters the payer sends.

However, some payers use unsafe characters, such as carriage returns, as delimiters in their 271 eligibility responses. This can break X12 parsing for some Stedi customers.

What’s changing
Stedi will normalize all delimiters returned in X12 271 eligibility responses to the following characters:

• Element Separator: * 

• Repetition Separator: ^

• Component Element Separator: >

• Segment Terminator: ~

If any of the above delimiters appear in a data element value – meaning the delimiter isn’t used to delimit content but is used as content – we will replace it as follows:

For example:

O*CONNOR → O|CONNOR
CODE^01 → CODE|01
O`CONNOR → O'CONNOR
MSG~HELLO → MSG|HELLO

What’s impacted
This change will affect all X12 271 eligibility responses returned by Stedi, including those returned by the:

• X12 Eligibility API endpoint

• SOAP Eligibility API endpoint

• x12 property of our JSON Eligibility API endpoint

• x12 field of our Poll Batch Eligibility Checks endpoint

• Stedi portal

Next steps
If you do not parse the raw X12 271 and only parse Stedi's JSON response, this will not impact you. Most Stedi customers won’t need to make any changes for this update. 

However, if your X12 parser assumes fixed delimiters instead of reading them from the ISA segment, you should confirm that your parser will continue to work after the update.

If you need time to update your parsing logic or have questions, contact us using your dedicated support channel or our contact form by December 22, 2025.

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that list a non-physical address for the billing provider. Non-physical addresses include Post Office (PO) Boxes, lockboxes, private mailboxes (PMBs), and similar mailbox-only addresses.

For claims, HIPAA requires that the provider’s billing address be a physical practice location where care is delivered. If you’re using Stedi’s JSON claim submission API endpoints, this address is in the request’s billing.address field. In X12, the address is in N3 (Billing Provider Address)  of Loop 2010AA (Billing Provider Name).

Payers may reject claims when the billing provider address is not a real street address, which can cause payment delays.

This edit – the industry’s term for an automated validation rule – catches the issue before it reaches the payer.

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Billing Provider address. The billing provider address must be a street address. Post Office Box or Lock Box addresses are to be sent in the Pay-To Address (2010AB Loop). Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Resolution tips
If the billing provider receives mail at a PO Box, lockbox, or other non-physical address, you can provide a “pay-to” address in the claim.

If you’re using Stedi’s JSON claim submission API endpoints, you can specify the pay-to address in the request’s payToAddress field or, for institutional claims, the billingPayToAddressName field. In X12, you can specify the pay-to address in N3 (Pay-to Address) of Loop 2010AB (Pay-to Address Name).