Changelog

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.

Bulk transaction enrollment CSVs now support new fields

You can now include four optional fields when creating transaction enrollment requests using a bulk CSV import:

• providerTransactionAccessNumber – The Provider Transaction Access Number (PTAN) assigned by the payer. The PTAN is a Medicare-issued identifier that providers receive from their Medicare Administrative Contractor (MAC) in an approval letter after enrolling with Medicare.

• requestedEffectiveDate – Date you'd like an ERA enrollment to take effect with the payer. Uses the YYYYMMDD format. See Introducing requested effective dates for ERA enrollments.

• aggregationPreferenceNpi – National Provider Identifier (NPI) to use for ERA aggregation.

• aggregationPreferenceTaxId – Tax ID number (TIN), such as an employer identification number (EIN) or Social Security Number (SSN), to use for ERA aggregation.

You can only provide one aggregation preference field, aggregationPreferenceNpi or aggregationPreferenceTaxId, per row.

The aggregation preference fields tell the payer how you'd like them to group payment information in ERAs. The preference is a request to the payer, not a guarantee. See Introducing aggregation preferences for ERA enrollments.

Previously, these four fields were only available through the Create Enrollment API or the Stedi portal UI.

Now you can also use the fields in bulk CSV imports. Bulk CSV imports are commonly used for clearinghouse migrations, new customer onboarding, and group practice rollouts.

Claim edit: Missing adjustment reason code

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include an adjustment amount or quantity without a corresponding adjustment reason code.

How the edit works

In a healthcare claim, an adjustment is a dollar amount that reduces what the payer owes the provider. Adjustments can cover things like a contractual write-off or the patient's responsibility, such as a co-pay or deductible.

Payers apply adjustments during adjudication and return them, along with other payment information, to the provider in an Electronic Remittance Advice (ERA). Adjustments are provided at both the claim and service-line level.

In the ERA, each adjustment's dollar amount is paired with a Claim Adjustment Reason Code (CARC). The reason code explains why the adjustment was made.

When billing a secondary or tertiary payer – a process called coordination of benefits (COB) – the provider or their billing system copies the prior payer's adjustments onto the claim.

Each adjustment has a reason code, a dollar amount, and an optional quantity. Not all three are required, but if an amount or quantity is present, the reason code must be too.

Claim-level adjustment reason code

Service line-level adjustment reason code

If the amount or quantity is copied without the corresponding reason code, the payer can't process the adjustment and will 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 Adjustment Reason Code. When an adjustment amount or quantity is present on the claim then a corresponding adjustment reason code 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, and error message:

STC*A6>521*[DATE]*U*[AMOUNT]********Missing Adjustment Reason Code. When an adjustment amount or quantity is present on the claim then a corresponding adjustment reason code is required. Correct and resubmit.~

Claim edit: Missing adjustment amount

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include an adjustment reason code without a corresponding adjustment amount.

How the edit works

In a healthcare claim, an adjustment is a dollar amount that reduces what the payer owes the provider. Adjustments can cover things like a contractual write-off or the patient's responsibility, such as a co-pay or deductible.

Payers apply adjustments during adjudication and return them, along with other payment information, to the provider in an Electronic Remittance Advice (ERA). Adjustments are provided at both the claim and service-line level.

In the ERA, each adjustment's dollar amount is paired with a Claim Adjustment Reason Code (CARC). The reason code explains why the adjustment was made.

When billing a secondary or tertiary payer – a process called coordination of benefits (COB) – the provider or their billing system copies the prior payer's adjustments onto the claim.

Each adjustment has a reason code, a dollar amount, and an optional quantity. Not all three are required, but if a reason code is present, the amount must be too.

Claim-level adjustment amount

Service line-level adjustment amount

If the reason code is copied without the corresponding amount, the payer can't process the adjustment and will 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 Adjustment Amount. When an adjustment reason code is present then a corresponding adjustment amount is required. Impacted adjustment reason code(s) 96. 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>519*[DATE]*U*[AMOUNT]********Missing Adjustment Amount. When an adjustment reason code is present then a corresponding adjustment amount is required. Impacted adjustment reason code(s) 96. Correct and resubmit.~

FirstCare is now one-click enrollment

Healthcare payer FirstCare (Payer ID: 94998) 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.

Health Payment Systems Incorporated is now one-click enrollment

Healthcare payer Health Payment Systems Incorporated (Payer ID: 20270) 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.

Introducing requested effective dates for ERA enrollments

You can now set an optional requested effective date on ERA transaction enrollment requests. This date tells the payer when you'd like them to start routing ERAs to Stedi.

A provider can only receive Electronic Remittance Advice (ERAs) from a payer through one clearinghouse at a time. You change that clearinghouse through a transaction enrollment.

Without a predictable start date, you can't tell providers when to expect ERAs at Stedi or when to stop checking for ERAs at their old clearinghouse.

A requested effective date gives you that start date. This makes clearinghouse migrations and provider go-live dates easier to plan.

How requested effective dates work

Requested effective dates are a request to the payer, not a guarantee. The payer, not Stedi, controls when an enrollment takes effect.

Checking payer support

Not all payers support requested effective dates. You can check whether a payer supports them using the Payers API or the Stedi Payer Network before submitting an enrollment request.

In the Stedi Payer Network:

The field is omitted when Stedi has yet to determine a payer's support for requested effective dates.

In Payers API responses, check the requestedEffectiveDate field in the claimPayment enrollment process to determine support:

{
  "payer": {
    "enrollment": {
      "transactionEnrollmentProcesses": {
        "claimPayment": {
          "requestedEffectiveDate": "SUPPORTED", // Payer supports requested effective dates for ERA enrollments
          ...
        }
      },
      ...
    },
    ...
  }
}

Enrollments API

Setting a requested effective date

You can now pass an optional requestedEffectiveDate field in Create Enrollment API requests. The date uses YYYYMMDD format and can be today or any date up to 6 months from now.

{
  "transactions": {
    "claimPayment": {
      "enroll": true // ERA enrollment
    }
  },
  "requestedEffectiveDate": "20260601", // Requested effective date
  ...
}

On DRAFT enrollments, omitting the requestedEffectiveDate field leaves the value empty. For enrollments in the STEDI_ACTION_REQUIRED status, the requested effective date defaults to the submission date.

If the payer explicitly doesn't support requested effective dates, Stedi rejects the request.

Updating existing enrollments

You can update a DRAFT enrollment’s requestedEffectiveDate using an Update Enrollment API request.

Viewing requested effective dates

The Retrieve Enrollment API and List Enrollments API responses return requestedEffectiveDate on each enrollment record. For example, in a Retrieve Enrollment response:

{
  "id": "db6675c5-7be7-4af9-8c68-a54a336d2911",
  "requestedEffectiveDate": "20260601",
  ...
}

Filtering and sorting by requested effective dates

The List Enrollments API also accepts new query parameters to filter and sort by requested effective date:

• Use requestedEffectiveDateFrom and requestedEffectiveDateTo to filter enrollments with a requested effective date in a given range

• Use sortBy=requestedEffectiveDate:asc or sortBy=requestedEffectiveDate:desc to sort results by requested effective date

For example, the following request returns enrollments with a Q2 2026 requested effective date, sorted from earliest to latest:

curl --request GET \
  --url "https://enrollments.us.stedi.com/2024-09-01/enrollments?requestedEffectiveDateFrom=20260401&requestedEffectiveDateTo=20260630&sortBy=requestedEffectiveDate:asc" \
  --header "Authorization: <api_key>"

Stedi portal

Requested effective dates appear in the enrollments list view.

You can filter enrollments by requested effective date.

They also appear, when applicable, on each enrollment's detail page in the Stedi portal.

Availability

Transaction enrollment is free on all Stedi plans.

To learn more, check out our transaction enrollment docs.

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.~