Changelog

Point C is now one-click enrollment

Healthcare payer Point C (Payer ID: 22823) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

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.

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.

San Francisco Health Plan is now one-click enrollment

Healthcare payer San Francisco Health Plan (Payer ID: SFHP1) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

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.

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.

Blue Cross Blue Shield of South Carolina is now one-click enrollment

Blue Cross Blue Shield of South Carolina (Payer ID: 00401) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

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.

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.

Claim edit: Invalid taxonomy code

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include a provider taxonomy code with an invalid format.

How the edit works

A taxonomy code identifies a provider's classification and specialization, such as cardiology or orthodontics.

Taxonomy codes are defined by the National Uniform Claim Committee (NUCC) and follow a strict format: exactly 10 alphanumeric characters, ending with the letter X.

If a claim contains a taxonomy code that doesn’t follow the format, 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 Taxonomy Code. The taxonomy code for Billing Provider does not meet the required format. Taxonomy codes must be 10 alphanumeric characters ending with 'X'. 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, entity identifier code, and error message.

STC*A7>145>85*[DATE]*U*[AMOUNT]******A7>569**Invalid Taxonomy Code. The taxonomy code for Billing Provider does not meet the required format. Taxonomy codes must be 10 alphanumeric characters ending with 'X'. Correct and resubmit.~

Introducing pagination for the List Payers API

You can now paginate List Payers API responses using the pageSize and pageToken query parameters.

Stedi's Payer Network includes thousands of payers. Previously, List Payers responses always included all of them in one response. The pageSize parameter lets you retrieve them in smaller pages. The pageToken parameter lets you navigate pages using cursor-based pagination.

If you omit pageSize, the List Payers API still returns all payers in a single response. Existing integrations aren't affected.

How to paginate List Payers responses

Pass pageSize in your List Payers API request. The value must be 10 or greater.

curl --request GET \
  --url "https://healthcare.us.stedi.com/2024-04-01/payers?pageSize=100" \
  --header "Authorization: <api_key>"

If more results are available, the response includes a nextPageToken.

{
  "items": [...],
  "nextPageToken": "yrZ3we9982etYlMgmw==" // Pass this as pageToken in your next request
}

Pass nextPageToken as the pageToken parameter to retrieve the next page:

curl --request GET \
  --url "https://healthcare.us.stedi.com/2024-04-01/payers?pageSize=100&pageToken=yrZ3we9982etYlMgmw==" \
  --header "Authorization: <api_key>"

When the response contains no nextPageToken, you've retrieved the last page.

For more information, see our List Payers API reference.

Introducing aggregation preferences for ERA enrollments

You can now set an aggregation preference – NPI or tax ID (TIN) – on ERA transaction enrollment requests. The preference tells the payer how you’d like them to group payment information in ERAs.

Selecting the right aggregation preference means ERAs arrive grouped the way your billing system expects. Without it, mismatched grouping can require manual reconciliation to match payments to providers or practices.

What is ERA aggregation?

An Electronic Remittance Advice (ERA) contains payment and adjudication information for one or more claims. Providers use ERAs for payment reconciliation, where they match claims to their payments.

Payers group the information inside an ERA and route ERAs based on one of two identifiers in the related claims:

• Tax identification number (TIN) – A 9-digit tax ID, either a Social Security Number (SSN) or Employer Identification Number (EIN).

• National Provider Identifier (NPI) – A 10-digit ID assigned to individual providers and organizations.

TIN vs. NPI-based aggregation

TINs are sometimes shared across multiple billing providers within the same organization. For example, a clinic may submit claims for several doctors using a single TIN.

NPIs always uniquely identify a single provider entity, either an individual provider or an organization. For example, a doctor employed by multiple clinics may use the same NPI to submit claims across multiple TINs.

Most payers default to TIN-based aggregation. For more background, see How payers route ERAs.

How aggregation preferences work

Aggregation preferences are a request to the payer, not a guarantee. The payer, not Stedi, controls how ERAs are grouped and routed.

Checking payer support

Not all payers support both aggregation types. You can check which types a payer supports using the Payers API or the Stedi Payer Network before submitting an enrollment request.

In the Stedi Payer Network:

In Payers API responses, the supportedAggregationPreferences field lists the supported types. The field is omitted when Stedi has yet to determine a payer's supported aggregation types.

{
  "payer": {
    "enrollment": {
      "transactionEnrollmentProcesses": {
        "claimPayment": {
          "supportedAggregationPreferences": ["NPI", "TIN"], // Payer supports ERA aggregation by NPI and TIN
          ...
        }
      }
    },
    ...
  }
}

Enrollments API

Setting aggregation preferences

You can now pass the optional aggregationPreference object in Create Enrollment API requests. In almost all cases, the NPI or TIN should belong to the provider being enrolled.

To request NPI-based aggregation, provide an NPI in the aggregationPreference.npi property. For example, in a Create Enrollment API request body:

{
  "transactions": {
    "claimPayment": {
      "enroll": true    // ERA enrollment
    }
  },
  "aggregationPreference": {
    "npi": "1234567890" // Aggregate by the provided NPI
  },
  ...
}

To request TIN-based aggregation, use the aggregationPreference.taxId property:

{
  "transactions": {
    "claimPayment": {
      "enroll": true    // ERA enrollment
    }
  },
  "aggregationPreference": {
    "taxId": "999888777" // Aggregate by the provided tax ID (TIN)
  },
  ...
}

The aggregationPreference object is only supported for ERA transaction enrollments.

Updating existing enrollments

You can update the aggregationPreference object using an Update Enrollment API request if the enrollment is in the DRAFT status.

Payer support for aggregation preference

Before accepting an enrollment request, Stedi checks whether the payer supports the provided aggregationPreference. If not, Stedi rejects the request with an error.

If you omit the aggregationPreference field, the payer’s default aggregation method is used.

Viewing aggregation preferences

The Retrieve Enrollment API and List Enrollment API responses now return the submitted aggregationPreference object in enrollment records. For example, in a Retrieve Enrollment API response:

{
  "id": "db6675c5-7be7-4af9-8c68-a54a336d2911",
  "aggregationPreference": {
    "npi": "1234567890"
  },
  ...
}

The object is omitted for enrollments created before this feature was available.

Stedi portal

You can now use the optional TIN or NPI selectors to indicate an aggregation preference when creating an ERA enrollment request in the Stedi portal. By default, the TIN and NPI values in the selectors belong to the provider being enrolled.

Each ERA enrollment’s details page shows the aggregation preference.

Availability

Transaction enrollment is free on all Stedi plans.

To learn more, check out our transaction enrollment docs.

Claim edit: Missing property and casualty claim number

Stedi now rejects 837P professional claims that include a property and casualty date of first contact without a related claim number.

How the edit works

Property and casualty (P&C) insurance claims cover injuries from accidents or liability events like auto accidents, Workers' Compensation, personal injury, and liability cases. These claims go to a P&C insurer rather than a healthcare payer.

In P&C claims, the date of first contact notes when a healthcare provider first treated the patient for the injury. 

Property and casualty date of first contact

The insurer opens an incident file and assigns a related claim number before it can process any billing.

Property and casualty claim number

If a P&C claim includes the date of first contact but not the claim number, 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 Property Casualty Claim Number. When the Property and Casualty Date of First Contact is submitted (20260101), the Property and Casualty Claim Number must also be present. 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*A6>629*[DATE]*U*[AMOUNT]********Missing Property Casualty Claim Number. When the Property and Casualty Date of First Contact is submitted (20260101), the Property and Casualty Claim Number must also be present. Correct and resubmit.~

Filter batch eligibility results by search outcome

You can now filter batch eligibility results in the Stedi portal and API by search outcome: whether the payer returned active insurance coverage, no coverage, or an error.

The Stedi portal also now displays the search outcome for each check directly in the batch results view.

Previously, the Stedi portal didn't show search outcomes for individual checks. To find patients with a specific outcome, you had to cross-reference the Eligibility searches page, which includes checks from all sources, not just your batch.

Filter using the API

Use the Retrieve Batch Check Statuses API endpoint’s eligibilitySearchOutcome query parameter to filter batch eligibility results by search outcome. You can pass multiple search outcomes as values.

For example, the following request returns all checks where the payer returned no coverage or an error:

curl "https://manager.us.stedi.com/2024-04-01/eligibility-manager/batch/{batchId}/items?eligibilitySearchOutcome=inactive&eligibilitySearchOutcome=failed" \
  -H "Authorization: Key <api_key>"

Claim edit: Missing first name

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include a person entity with no first name.

How the edit works

In a claim, each entity, such as the billing provider or subscriber, is identified as either a person or a non-person using an entity type qualifier.

When an entity is a person, a first name is required. If the first name is missing, 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.

How entity type qualifiers are specified

If you use Stedi's JSON Claim Submission API endpoints, Stedi sometimes infers the entity type qualifier. For example, if you provide a firstName and lastName for the billing provider in a JSON 837P Professional Claims API request, the entity is treated as a person. If you provide an organizationName, the entity is treated as an organization. Other entities, such as otherPayerBillingProvider, have an explicit entityTypeQualifier field.

If you use X12, you set the entity type qualifier directly in NM1-02 (Entity Type Qualifier), where 1 indicates a person and 2 indicates a non-person entity.

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 First Name. When the Billing Provider entity is a person, as identified by the entity type qualifier 1, the entity first name is required. 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, entity identifier code, and error message.

STC*A6>505>85*[DATE]*U*[AMOUNT]********Missing First Name. When the Billing Provider entity is a person, as identified by the entity type qualifier 1, the entity first name is required. Correct and resubmit.~

Introducing event destinations

You can now get real-time notifications for Stedi events using event destinations, Stedi's new webhook framework.

For this launch, event destinations support transaction enrollment events. You can get a real-time notification whenever a request goes live or is rejected. We plan to release more event types for event destinations soon.

For more details, see our announcement blog.

Claim edit: COB service lines must be balanced

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims sent to a non-primary payer when a service line's coordination of benefits (COB) amounts don't balance.

How the edit works

When a patient has multiple insurance plans, the provider submits a claim to each payer in order. The first is the primary payer. Any that follow are secondary, tertiary, and so on. This process is called coordination of benefits (COB).

A service line is a line item for a specific service on a claim, like an office visit or X-ray.

When you submit a claim to a non-primary payer, you must include each previous payer's adjudications – their payments and adjustments. Include both claim-level and service line-level adjudications from each prior payer. Don't include the same amounts at both levels.

Balancing service lines

When you include prior payer adjudications at the service line level, the amounts must add up as follows:

Billed line charge

Prior payer line paid amount

Line adjustment amounts

If the amounts don't balance for any service line adjudication, 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.

We previously added a separate edit for claim-level COB balancing.

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": "Coordination of Benefits (COB) balancing failed. For line 1, the total charged amount of $150.00 does not equal the sum of the paid amount of $0.00 and all adjustment amounts of $200.00 for payer STEDITEST. 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>551*[DATE]*U*[AMOUNT]********Coordination of Benefits (COB) balancing failed. For line 1, the total charged amount of $150.00 does not equal the sum of the paid amount of $0.00 and all adjustment amounts of $200.00 for payer STEDITEST. Correct and resubmit.~

Introducing the Stedi NPI registry

You can now look up details for any U.S. healthcare provider by NPI using the Stedi NPI registry.

An NPI is required for most healthcare transactions, including eligibility checks, claims, and claim status checks. You can use the registry to verify a provider’s NPI and other information before submitting these transactions.

For more details, see our announcement blog.

Claim edit: Discharge hour on non-final institutional claims

Stedi now rejects 837I institutional claims that include a discharge hour but use a claim frequency code that indicates the patient has not been discharged.

How the edit works

In institutional claims, the discharge hour tells the payer when the patient left the facility.

Discharge hour

Institutional claims also include a claim frequency code that tells the payer where the claim falls in a patient's billing cycle.

Claim frequency code

Some claim frequency codes, such as 2 (Interim – First Claim), indicate the patient is still receiving care and has not yet been discharged. Claims with these frequency codes are called non-final claims.

A discharge hour should not be included on non-final claims. If it is, 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.

The error message references the claim’s bill type. This is a combination of the claim’s facility type code and claim frequency code.

For example, bill type 112 indicates facility type 11 (Hospital inpatient – general) with frequency code 2 (Interim – First Claim).

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Discharge Date/hour. Discharge information should not be present for the submitted bill type 112. These fields are only used for final inpatient claims. 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>190*[DATE]*U*[AMOUNT]********Invalid Discharge Date/hour. Discharge information should not be present for the submitted bill type 112. These fields are only used for final inpatient claims. Correct and resubmit.~

Claim edit: Missing country code for non-US addresses

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include a non-US address without a country code.

How the edit works

HIPAA-adopted X12 EDI standards require a country code when any address in a claim is outside the United States.

If an address's state or province code is not a US state or territory, the address must include a country code. If the country code is missing from a non-US address, the payer may reject the claim.

If the country code for a non-US address in a claim is missing, Stedi attempts to look up the country code using the full address. If successful, Stedi then updates the claim.

For example, if a billing provider’s address lists a state/province code of ON (Ontario) and uses a Canadian postal code format, Stedi will automatically add a country code of CA (Canada).

If Stedi's lookup can't find the country code, this edit rejects the claim. 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.

The entity name in the error varies based on which address in the claim is missing the country code. For example, the following error indicates the billing provider's address is missing a country code:

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Country Code. The country code for Billing Provider is required when the address is outside the United States. 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, entity identifier code, and error message.

STC*A6>680>85*[DATE]*U*[AMOUNT]********Missing Country Code. The country code for Billing Provider is required when the address is outside the United States. Correct and resubmit.~

Introducing claims management features for the Stedi portal

We’ve released a dedicated set of claims management features in the Stedi portal, including an improved claims view.

The new claims view is built around the claim itself. You can see where each claim stands, review its history, and filter across your entire claims volume. Features include:

• A filterable list of all claims submitted through Stedi

• The ability to see the current status of a claim

• A timeline for each claim showing 837 claim submissions and related 277CA claim acknowledgments

• Detail pages for each claim submission and acknowledgment transaction

For more details, see our announcement blog.

Introducing the CPT/HCPCS to Service Type Code lookup tool

You can now look up common Service Type Code (STC) mappings for a CPT or HCPCS procedure code using Stedi's free lookup tool.

You can use the STCs returned by the tool to test payer STC support and find the right STC to use in eligibility checks.

For more details, see our announcement blog.

Stedi's CMS-1500 claim form now supports line item control numbers

You can now set line item control numbers for individual service lines in a professional claim using the Stedi portal’s CMS-1500 form.

What is a line item control number?

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

A line item control number is a unique, provider-assigned identifier for each service line in a claim.

Payers return line item control numbers in Electronic Remittance Advice (ERAs). Both providers and payers can use them to track service lines and reconcile claim submissions with payments.

Previously, the CMS-1500 form automatically assigned a random identifier to each service line. Now you can set your own.

How it works

When submitting a claim using the Stedi portal’s CMS-1500 form, click Set manual line item control numbers in the service lines table to reveal the Line Item Control Number field for each service line.

You can enter up to 30 characters per line. Each number must be unique within the claim.

Once you enter a line item control number, the fields stay visible and can't be hidden. To hide empty fields, click Hide manual line item control numbers.

If you later need to resubmit a claim using the CMS-1500 form, any existing line item control numbers are automatically mapped to the new submission.

Claim edit: All invalid ICD-10-CM diagnosis codes are now returned at once

Stedi's claim edit for invalid ICD-10-CM diagnosis codes now returns all invalid codes in the rejection's error message. The edit applies to 837P professional and 837I institutional claims.

Previously, if a claim had multiple invalid codes, only one was returned per rejection. To fix all the invalid codes, you had to correct and resubmit the claim multiple times – once for each invalid code.

How the edit works

In healthcare claims, diagnosis codes describe what’s wrong with the patient. HIPAA requires that professional and institutional claims only use valid, billable ICD-10-CM codes as diagnosis codes.

Diagnosis codes

Stedi previously introduced an edit for invalid ICD-10-CM diagnosis codes. The edit rejects a professional or institutional claim when any diagnosis code is:

• Not a valid ICD‑10‑CM code.
  For example, if the code is misspelled or doesn’t exist in the official ICD-10-CM code list.

• A non-billable ICD‑10‑CM code.
  Some ICD-10-CM codes are categories. They cover a broad diagnostic grouping rather than a specific condition. For example, E11 (Type 2 diabetes mellitus) is a category header.

  By themselves, category headers aren’t considered billable codes. They’re not specific enough to describe the exact condition or encounter being billed. A billable ICD-10-CM code must include both a category and a subcategory, such as E11.9 (Type 2 diabetes mellitus without complications).

• Not valid for the claim’s dates of service.
  Updates to the ICD-10-CM code set are published each year. If a claim uses a code that wasn’t valid on the dates of service, Stedi rejects it.

  For example, Z11.52 (“Encounter for screening for COVID-19”) became effective on October 1, 2021. A claim with a date of service before that date would be rejected because the code wasn’t valid at the time.

This edit catches these issues 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-CM Diagnosis Code. All submitted diagnosis codes must be valid per the ICD-10 manual. Diagnosis code(s), XY9999, ZZ0000, do not exist in the code set. 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]******A7>255**Invalid ICD-10-CM Diagnosis Code. All submitted diagnosis codes must be valid per the ICD-10 manual. Diagnosis code(s), XY9999, ZZ0000, do not exist in the code set. Correct and resubmit.~

Claim edit: Invalid procedure code format

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims with a procedure code that isn't exactly 5 alphanumeric characters or is made up entirely of letters.

How the edit works

Procedure codes, such as medical CPT/HCPCS codes and dental CDT codes, identify a service performed during a patient visit.

Procedure code

In a claim, all valid procedure codes must be exactly 5 alphanumeric characters with no spaces or special characters. They must also include at least one digit. A code made up entirely of letters, such as PHONE, isn't valid; an all-numeric code, such as 87070, is.

If a claim contains a procedure code with spaces or special characters, Stedi automatically removes the spaces and characters during validation. If the resulting procedure code has a length other than 5, or is made up entirely of letters, Stedi rejects the claim. This prevents later payer rejections, which are slower and can delay payment for the provider.

For 837D dental claims, Stedi also checks that the procedure code starts with the letter D, following the CDT code format.

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.

837P professional and 837I institutional claims

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Procedure Code Format. Procedure codes must be exactly 5 alphanumerical characters with no spaces or special characters. Invalid procedure code(s) ['PHONE'] detected. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

837D dental claims

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Dental Procedure Code Format. Procedure codes must be exactly 5 alphanumerical characters and start with 'D' with no spaces or special characters. Invalid procedure code(s) ['DABCD'] detected. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

SFTP rejections

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.

837P professional and 837I institutional claims

STC*A7>511*[DATE]*U*[AMOUNT]******A7>454**Invalid Procedure Code Format. Procedure codes must be exactly 5 alphanumerical characters with no spaces or special characters. Invalid procedure code(s) ['PHONE'] detected. Correct and resubmit.~

837D dental claims

STC*A7>511*[DATE]*U*[AMOUNT]******A7>454**Invalid Dental Procedure Code Format. Procedure codes must be exactly 5 alphanumerical characters and start with 'D' with no spaces or special characters. Invalid procedure code(s) ['DABCD'] detected. Correct and resubmit.~

Introducing ERA last received timestamps

Stedi's List Enrollments and Retrieve Enrollment API responses now return a lastEraReceivedAt timestamp for ERA enrollment records.

The timestamp contains the last time Stedi routed a production Electronic Remittance Advice (ERA) for the combination of NPI, Tax ID, and payer listed in the enrollment record. For example:

{
  "id": "db6675c5-7bg7-4af9-8c68-a54a336d2911",
  "transactions": {
    "claimPayment": {
      "enroll": true  // ERA enrollment record
    }
  },
  "lastEraReceivedAt": "2026-03-27T05:31:56Z", // Timestamp of last ERA received
  ...
}

You can use the lastEraReceivedAt field to troubleshoot gaps in a payer’s ERA delivery or find payers that have stopped sending remittance.

Availability

lastEraReceivedAt is only populated for ERA transaction enrollments, not enrollments for other transaction types.

The field is omitted from enrollments that haven't yet received a production ERA.

Filter by the last ERA received timestamp

You can use the List Enrollments endpoint's new lastEraReceivedFrom and lastEraReceivedTo query parameters to filter ERA enrollments by the timestamp of the last ERA received. For example:

curl "https://enrollments.us.stedi.com/2024-09-01/enrollments?lastEraReceivedFrom=2025-01-01T00:00:00Z&lastEraReceivedTo=2025-03-31T23:59:59Z" \
  -H "Authorization: Key <api_key>"

Sort by the last ERA received timestamp

Use lastEraReceivedAt as a sortBy parameter for the List Enrollments endpoint to sort by your most- or least-recently active ERA enrollments.

curl "https://enrollments.us.stedi.com/2024-09-01/enrollments?sortBy=lastEraReceivedAt:desc" \
  -H "Authorization: Key <api_key>"

Stedi portal

The Last ERA received at field is available in the Stedi portal’s enrollments list view as a filter.

The field also appears in the enrollment detail view.