Changelog

Blue Cross Blue Shield of North Carolina (Payer ID: BCSNC) – also called BCBS NC – now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

What is transaction enrollment?
Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer.

For Electronic Remittance Advice (ERAs), enrollment is always required. A payer only sends ERAs to the clearinghouse the provider has enrolled with, and a provider can only enroll with the payer through one clearinghouse at a time.

Stedi offers fully-managed, API-based transaction enrollment at no extra cost. You can use Stedi’s enrollment API to submit and track enrollments programmatically.

You can also submit and track enrollments manually in the Stedi portal, which supports bulk CSV imports.

What is one-click enrollment?
Transaction enrollment requirements vary by payer. Some payers require extra steps, such as signing a PDF or logging into a portal.

If a payer supports one-click enrollment, you only need to submit the enrollment request. There are no follow-up steps. Stedi handles everything else.

How to find other one-click enrollment payers
You can check whether a payer requires enrollment for ERA and other transaction types using the Stedi Payer Network or the Payer APIs.

For details, see our transaction enrollment docs.

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.