Changelog

Filter claims by member ID in the Stedi portal

You can now filter claims in the Stedi portal's claims view by one or more subscriber member IDs.

The subscriber's member ID also appears as a column in the claims list, alongside details like patient name, payer, and processed date.

For claims with secondary insurance, the column shows the subscriber's member ID for the primary plan.

Eligibility PDFs now include submitter transaction IDs and payer trace numbers

Stedi's eligibility PDFs now include the submitter transaction ID and payer trace number when they're present in the eligibility response.

Both IDs are used to trace eligibility checks across provider and payer systems.

This means you can look up a specific check in your EHR, RCM, or practice management platform, or in the payer's system, using only an eligibility PDF.

You can download eligibility PDFs using the Retrieve Eligibility PDF API endpoint or the Stedi portal.

Submitter transaction IDs

A submitter transaction ID is an identifier you – the submitter – set on an eligibility request. The payer echoes it back in the response.

EHR, RCM, and practice management platforms often use submitter transaction IDs to track eligibility checks.

When present in the response, the submitter transaction ID appears in the Request section at the bottom of the eligibility PDF.

Payer trace numbers

A payer trace number is an optional, payer-assigned ID for an eligibility check. Payers can include one or more in the response.

Providers and billers often need to cite payer trace numbers when contacting payer support about a specific eligibility check.

When present in the response, payer trace numbers appear in the Payer row of the summary at the top of the eligibility PDF.

Some payers issue separate trace numbers for the subscriber and a dependent. The PDF lists both, separated by a comma.

Note: Stedi also generates an internal trace number for every check. Eligibility PDFs always exclude Stedi-generated trace numbers.

Claim edit: ICD-10 diagnosis code with pre-implementation service date

Stedi now rejects 837P professional, 837I institutional, and 837D dental claims that pair an ICD-10-CM diagnosis code with a service date before October 1, 2015.

Service dates

In a claim, a service line represents billing for a specific service, such as an office visit or X-ray. The date of service, also called the service date, is the date the service was performed.

Diagnosis codes

Diagnosis codes describe what's wrong with the patient. For example, I10 is the ICD-10-CM code for essential (primary) hypertension.

For services on or after October 1, 2015, HIPAA requires that claims use valid, billable ICD-10-CM codes as diagnosis codes. For services before that date, ICD-9-CM diagnosis codes were used.

Each diagnosis code is paired with a qualifier identifying its code set and position. ICD-10-CM codes use ABK (principal diagnosis) or ABF (other diagnosis). ICD-9-CM codes use BK or BF.

For example, the ICD-10-CM code E11.9 (Type 2 diabetes mellitus without complications) submitted as the principal diagnosis carries the ABK qualifier.

How the edit works

If you submit a claim with an ICD-10-CM diagnosis code (qualifier ABK or ABF) and any service line has a date of service before October 1, 2015, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which are slower and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid ICD-10 Diagnosis for Date of Service. ICD-10 diagnosis codes (qualifier ABK, ABF) are valid for dates of services on or after the implementation date of 10/01/2015. Prior to the implementation date, ICD-9 codes (qualifier BK, BF) are typically used. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>700*[DATE]*U*[AMOUNT]********Invalid ICD-10 Diagnosis for Date of Service. ICD-10 diagnosis codes (qualifier ABK, ABF) are valid for dates of services on or after the implementation date of 10/01/2015. Prior to the implementation date, ICD-9 codes (qualifier BK, BF) are typically used. Correct and resubmit.~

Claim repair and edit: Incomplete ZIP Code

Stedi now validates ZIP Codes for US addresses in 837P professional, 837D dental, and 837I institutional claims.

X12 standards require a full 9-digit ZIP Code, called a ZIP+4, for the billing provider and service facility addresses when the address is in the United States.

For billing provider and service facility addresses without a full 9-digit ZIP+4, Stedi attempts to repair the claim by looking up the full 9-digit ZIP+4. If the lookup fails and the submitted ZIP is an invalid length, this edit rejects the claim.

Stedi also rejects claims with other addresses, such as subscriber or payer addresses, that contain ZIP Codes that don't meet length requirements.

Billing provider and service facility addresses

How the repair works

If the billing provider or service facility ZIP Code isn't a full 9-digit ZIP+4, Stedi attempts to look up the ZIP+4 using the rest of the address. If the lookup succeeds, Stedi repairs the claim with the resolved ZIP+4.

Billing provider address ZIP Code

Claim-level service facility address ZIP Code

Service-line-level service facility address ZIP Code

For example, if you submit a claim with a billing provider address of 1600 Pennsylvania Ave, Washington, DC, Stedi looks up and uses a ZIP+4 of 200033228.

Before the lookup, Stedi normalizes the submitted ZIP value. Hyphens and other separators are removed.

If Stedi can't look up the ZIP+4 (for example, because the address isn't recognized), Stedi preserves the submitted ZIP Code. If the value is only 5 digits, Stedi pads it with 0000 to reach the required 9-digit length. For example, a ZIP Code of 20003 becomes 200030000.

How the edit works

If the resulting ZIP Code isn't 9 digits after lookup and normalization, this edit rejects the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which are slower and delay payment for the provider.

Rejection errors

If you submit a claim that fails the edit for a billing provider or service facility address using Stedi's Claim Submission API endpoints, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Incomplete ZIP Code. The billing provider address requires the full 9-digit ZIP code (ZIP+4) when the address is in the United States. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit for a billing provider or service facility address using SFTP, Stedi rejects the claim with a 277CA claim acknowledgment. The acknowledgment includes a related claim status category code, claim status code, entity identifier code, and error message:

STC*A6>500>85*[DATE]*U*[AMOUNT]********Incomplete ZIP Code. The billing provider address requires the full 9-digit ZIP code (ZIP+4) when the address is in the United States. Correct and resubmit.~

Other addresses

Other addresses in a claim, such as the subscriber, payer, or patient address, can use either a valid 5-digit ZIP or 9-digit ZIP+4.

Stedi doesn't perform lookups for other addresses in the claim. Those addresses are rejected if they don't meet the 5-digit or 9-digit format requirement after Stedi normalizes them.

Rejection errors

If you submit a claim that fails the edit for an address other than the billing provider or service facility, such as the subscriber or payer address, using Stedi's Claim Submission API endpoints, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid ZIP Code. The subscriber address requires either the 5-digit or full 9-digit ZIP code (ZIP+4) when the address is in the United States. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit for an address other than the billing provider or service facility using SFTP, Stedi rejects the claim with a 277CA claim acknowledgment:

STC*A6>500>HK*[DATE]*U*[AMOUNT]********Invalid ZIP Code. The subscriber address requires either the 5-digit or full 9-digit ZIP code (ZIP+4) when the address is in the United States. Correct and resubmit.~

Previous edit

This edit replaces the previous billing provider ZIP Code edit for institutional claims. The previous edit rejected institutional claims with an address missing a full ZIP+4. This edit adds the ZIP+4 lookup repair.

Test mode now supports mock Raw X12 and SOAP Eligibility API requests

We've expanded Stedi's test mode for eligibility checks:

• More endpoints: You can now use a test API key to run mock eligibility checks using Stedi's Raw X12 and SOAP Eligibility API endpoints. Previously, you could only use the JSON Eligibility endpoint or the Stedi portal to run mock checks.

• PDF downloads: You can now download eligibility PDFs for mock eligibility responses using the Stedi portal or Retrieve Eligibility PDF endpoint.

• Benefits table: You can now view the full benefits table for mock eligibility responses in the Stedi portal. Previously, only the Stedi Agent mock response supported the benefits table.

For more details, see our announcement blog.

Claim edit: Invalid patient status code

Stedi now rejects 837I institutional claims that contain an invalid patient status code.

How the edit works

In an institutional claim, the patient status code describes the patient's condition at the end of the claim's billed period. It tells the payer whether the patient was discharged, transferred, or still admitted.

The patient status code must be a valid two-digit value from the UB-04 FL17 code set. If it isn’t a valid code, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which are slower and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Patient Status Code. Patient status codes must be submitted as two numeric digits and must be a valid discharge status code. The submitted status code is not valid, 00. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>234*[DATE]*U*[AMOUNT]********Invalid Patient Status Code. Patient status codes must be submitted as two numeric digits and must be a valid discharge status code. The submitted status code is not valid, 00. Correct and resubmit.~

Claim edit: Missing admission date for inpatient claims

Stedi now rejects 837P professional claims that indicate an inpatient setting but are missing an admission date.

How the edit works

In professional claims, an inpatient claim is a claim for services delivered to a patient who’s formally admitted to a hospital or similar facility.

Inpatient claims must include the patient's admission date. The date tells the payer when the patient was admitted to the facility for care.

Admission date

The place of service code identifies whether a claim is an inpatient claim. Codes such as 21 (Inpatient Hospital) or 51 (Inpatient Psychiatric Facility) indicate an inpatient setting.

Place of service code

If the place of service code indicates an inpatient setting and no admission date is present, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which are slower and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Admission Date/Hour. The admission date/hour should be present on all inpatient claims and some outpatient claims. The submitted place of service, 21, indicates an inpatient claim. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>189*[DATE]*U*[AMOUNT]******A8>249**Missing Admission Date/Hour. The admission date/hour should be present on all inpatient claims and some outpatient claims. The submitted place of service, 21, indicates an inpatient claim. Correct and resubmit.~

Claim edit: Negative line item charge amount

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include a negative line item charge amount for a service line.

How the edit works

In a claim, a service line represents billing for a specific service, such as an office visit or X-ray.

A line item charge amount is what the provider billed for a single service.

If a service line's line item charge amount is below zero, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which are slower and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid line charge amount. Submitted value -50.00 on line 1 must be zero or greater. Negative values are not allowed. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>583*[DATE]*U*[AMOUNT]******A7>732**Invalid line charge amount. Submitted value -50.00 on line 1 must be zero or greater. Negative values are not allowed. Correct and resubmit.~

Resolution tips

Billers usually add negative line item charge amounts when attempting to:

• Reverse a charge. Instead, submit a void or replacement claim.

• Adjust for deductibles or contracted rates. Avoid doing this. Payers apply these automatically and report the adjustments in the 835 Electronic Remittance Advice (ERA).

Several Blue Cross Blue Shield payers now support one-click enrollment

The following Blue Cross Blue Shield (BCBS) payers now support one-click transaction enrollment:

About one-click enrollment

Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollment for ERAs. For other transactions, it depends on the payer.

Transaction enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

With one-click transaction enrollment, you only need to submit an enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer supports one-click enrollment using the Stedi Payer Network or the Payer APIs.

Updated guidance for claim resubmissions

Stedi has updated its claim resubmission guidance to align with the new claims management functionality in the Stedi portal. Customers that follow the updated guidance will see resubmitted claims linked to the original claim in the claims view and claim timeline.

Important: This guidance only affects how claim submissions are linked in the Stedi portal. It doesn’t affect claims processing. You can continue to submit claims to Stedi without following the updated guidance, but it will lead to a suboptimal viewing experience in the portal.

The update covers two fields in the claim submission: patient control numbers (PCNs) and claim frequency codes (CFCs).

If you don't update your resubmission logic, resubmissions will still succeed, but the resubmitted claim won't appear linked to the original claim in the Stedi portal's claims view and claim timeline.

Claims and resubmissions already submitted under previous guidance won't be retroactively linked in the claims view or claim timeline.

Patient control numbers

A patient control number (PCN) is a tracking ID for a claim. You include a PCN when you submit a claim. The payer sends the PCN back in follow-up transactions: claim acknowledgments, Electronic Remittance Advice (ERAs), and real-time claim status checks.

You can set the PCN in the following locations:

• JSON API: claimInformation.patientControlNumber

• X12 (API or SFTP): Loop 2300 CLM01 (Patient Control Number)

• CMS-1500 claim form: Box 26 (Patient account number)

Stedi matches claims and resubmissions in the claims view and claim timeline using the PCN. We recommend using nanoid to generate strong, unique 17-character PCNs. See our docs for best practices.

What’s changing

Previously, our guidance was to use a new, unique PCN for any claim resubmission. Since Stedi’s claims management views use the PCN to link claims and resubmissions, this meant that a claim and a resubmission with different PCNs would not be linked in the portal.

We now recommend reusing the same PCN from the original submission in two scenarios:

• Pre-adjudication claims (any payer): The claim hasn't yet entered the payer's adjudication system. The clearest signals that a claim is in pre-adjudication are that the payer's 277CA doesn't contain a payer claim control number (PCCN), no real-time claim status check has returned a PCCN, and you haven't received an ERA for the original claim. See Pre-adjudication vs. adjudication in our docs.

• Medicare claims in adjudication: The clearest signals that a claim is in adjudication are that the payer's 277CA contains a PCCN, a real-time claim status check returned a PCCN, or you've received an ERA for the original claim. Medicare resubmissions don’t use the PCCN, so reusing the PCN doesn't risk duplicate-claim errors. See Medicare resubmission in our docs.

Reusing the PCN in these scenarios allows Stedi to link resubmissions to the same claim timeline.

For non-Medicare claims in adjudication, our guidance is unchanged: use a new, unique PCN. This helps avoid duplicate-claim errors from the payer. It also makes it easier to differentiate ERA responses for the original claim from those for resubmissions.

Claim frequency codes

The claim frequency code (CFC) tells the payer whether a claim is an original claim, a correction, or part of an ongoing stay.

You can set the CFC in the following locations:

• JSON API: claimInformation.claimFrequencyCode

• X12 (API or SFTP): Loop 2300 CLM05-03 (Claim Frequency Code)

• CMS-1500 claim form: Qualifier in Box 22 (Resubmission code)

Institutional claims support a broader set of CFC values than professional or dental claims. For example, long-term care facilities often submit interim claims every 30 days using CFC 2 (Interim - First Claim), 3 (Interim - Continuing Claims), or 4 (Interim - Last Claim). Resubmitting an interim claim with CFC 1 would incorrectly signal a final end-to-end claim.

What’s changing

Previously, our guidance was to use CFC 1 (Admit thru Discharge Claim) for pre-adjudication claims and Medicare claims in adjudication, and CFC 7 (Replacement of Prior Claim) for corrections or 8 (Void/Cancel of Prior Claim) for cancellations, for non-Medicare claims in adjudication. This guidance didn't account for institutional interim claims (described above), which retain their original CFC across resubmissions.

We now recommend institutional claims use the original submission's CFC in two scenarios:

• Pre-adjudication institutional claims (any payer): The claim hasn't yet entered the payer's adjudication system. The clearest signals that a claim is in pre-adjudication are that the payer's 277CA doesn't contain a PCCN, no real-time claim status check has returned a PCCN, and you haven't received an ERA for the original claim. See Pre-adjudication vs. adjudication in our docs.

• Institutional Medicare claims in adjudication: The clearest signals that a claim is in adjudication are that the payer's 277CA contains a PCCN, a real-time claim status check returned a PCCN, or you've received an ERA for the original claim. See Medicare resubmission in our docs.

Preserving the original CFC keeps the claim's intent intact – original, interim, or final – across resubmissions.

For professional and dental claims, and for non-Medicare claims in adjudication (all claim types), our guidance is unchanged.

Support

For more details, see our resubmit or cancel claims docs.

If you have questions or concerns, contact us using your dedicated support channel or our contact form.