Changelog

Claim edit: Duplicate occurrence codes in institutional claims

Stedi now rejects 837I institutional claims that include the same occurrence code more than once within a single occurrence code group.

How the edit works

In institutional claims, occurrence codes report significant events in a patient's care. These codes can affect how much a payer will approve or pay for a claim or service.

For example, occurrence code 11 reports the onset of symptoms or illness. Code 42 reports the date of discharge. Occurrence codes are defined by the National Uniform Billing Committee (NUBC).

A claim can contain up to two groups of occurrence codes. Each group can contain up to 12 codes.

Occurrence code

The NUBC states that each occurrence code must be unique within a single group. If a claim includes the same occurrence code more than once within a single group, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve 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 Occurrence Code(s). If submitting multiple occurrence codes, each code must be unique. The submitted occurrence code(s) are submitted more than once, 45. 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>719*[DATE]*U*[AMOUNT]******A7>732**Invalid Occurrence Code(s). If submitting multiple occurrence codes, each code must be unique. The submitted occurrence code(s) are submitted more than once, 45. Correct and resubmit.~

Related claim edits

Stedi has another edit for duplicate occurrence span codes. Occurrence codes report a single event on a specific date. Occurrence span codes report a condition that applied over a range of dates. See Duplicate occurrence span codes in institutional claims.

Claim edit: Invalid admission type code

Stedi now rejects 837I institutional claims with an invalid admission type code.

How the edit works

In institutional inpatient claims, an admission type code indicates the general nature of a patient’s admission. It provides context about the urgency or purpose of the hospital admission.

Admission type code

Admission type codes are defined by the National Uniform Billing Committee (NUBC). Valid admission type codes are:

• 1 – Emergency

• 2 – Urgent

• 3 – Elective

• 4 – Newborn

• 5 – Trauma Center

• 9 – Information Not Available

If an institutional claim includes an invalid admission type code, such as 6 or 0, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve 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 Admission Type Code. The submitted admission type code, 0 is not a recognized value. The value must be valid per NUBC Priority (Type) of Admission or Visit Codes. 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>231*[DATE]*U*[AMOUNT]********Invalid Admission Type Code. The submitted admission type code, 0 is not a recognized value. The value must be valid per NUBC Priority (Type) of Admission or Visit Codes. Correct and resubmit.~

Claim edit: Invalid date range

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims where the start of a date range is later than the end date.

Date formats

X12 standards require that every date on a claim, such as the service date or admission date, use one of two formats:

• Single date – Eight digits in CCYYMMDD format. Example: 20260515.

• Date range – Two dates in CCYYMMDD-CCYYMMDD format. Example: 20260515-20260516.

In raw X12, each date has a related qualifier indicating the format: D8 for single dates and RD8 for date ranges.

Date ranges in the JSON API

In Stedi's JSON Claim Submission API endpoints, most dates that support ranges use paired fields. For example, in the JSON Professional Claim Submission endpoint, you can provide a date of service either as:

• A single date using the serviceDate field

• A range using the serviceDate and serviceDateEnd fields.

Some dates accept a range in a single field. For example, in the JSON Dental Claim Submission endpoint, the claim-level serviceDate field accepts either a single date or a date range.

How the edit works

For date ranges in a claim, the start date should never fall after the end date. If it does, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve 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 Service date range. The start date (20250708) cannot be later than the end date (20250608). 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>187*[DATE]*U*[AMOUNT]********Invalid Service date range. The start date (20250708) cannot be later than the end date (20250608). Correct and resubmit.~

Claim edit: Missing claim-level place of service code

Stedi now rejects 837P professional and 837D dental claims that are missing a claim-level place of service code.

How the edit works

In a healthcare claim, a place of service code tells the payer where a service was delivered, such as an office or inpatient facility. Place of service codes can have a significant effect on how much a payer will approve or pay for a claim or service.

X12 standards require that 837P professional and 837D dental claims include a place of service code at the claim level. Place of service codes can also be specified at the service line level but should only be included if they differ from the claim-level code.

Claim-level place of service code

If a professional or dental claim is missing a claim-level place of service code, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve 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 Place of Service code. A place of service code is required for this 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*A6>249*[DATE]*U*[AMOUNT]********Missing Place of Service code. A place of service code is required for this claim. Correct and resubmit.~

Claim edit: ZIP or postal code not allowed outside the U.S. and Canada

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include a ZIP or postal code in an address outside the U.S. or Canada.

How the edit works

X12 states that ZIP and postal code fields are specific to the U.S. and Canada. If an address in a claim has a country code other than US or CA, it should not contain a ZIP or postal code. If it does, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve 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 postal code usage. A ZIP Code must only be submitted when the country is US or CA. The submitted address for Subscriber includes a ZIP Code with country code FR. 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>500>HK*[DATE]*U*[AMOUNT]******A8>680>HK**Invalid postal code usage. A ZIP Code must only be submitted when the country is US or CA. The submitted address for Subscriber includes a ZIP Code with country code FR. Correct and resubmit.~

Claim edit: Duplicate contract amount on a service line

Stedi now rejects 837P professional and 837D dental claims that report the same contract amount on a service line and at the claim level.

Important: Most claims don't include a contract amount. Submitters send one only when the provider’s contract with the payer requires it. Confirm with the payer before including it.

What is a contract amount?

A contract amount is the dollar amount a payer agreed to pay for a service in their contract with the provider. This amount often differs from the provider’s billed charge amount.

When you submit a claim, you can specify the contract amount at two levels: the claim level and the service line level.

The claim-level contract amount covers the whole claim.

Claim-level contract amount

The service-line contract amount specifies the contracted dollar amount for a specific service on the claim. A claim can have multiple service-line contract amounts – one for each service.

Service-line contract amount

How the edit works

A service-line contract amount should not duplicate the claim-level contract amount.

Some payer systems treat service-line contract amounts as an override of the claim-level value. These systems may read a duplicate contract amount at the claim and service line level as a conflicting or erroneous override.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve 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 Service Line Contract Amount. The submitted service-line contract amount on line 1 must not equal the claim-level contract amount, 500. 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>545*[DATE]*U*[AMOUNT]******A8>710**Invalid Service Line Contract Amount. The submitted service-line contract amount on line 1 must not equal the claim-level contract amount, 500. Correct and resubmit.~

Resolution tip

If a service line has the same contracted amount as the claim, remove the service line’s contract amount. The claim-level amount already applies to every line on the claim.

Claim edit: Invalid EPSDT certification and condition indicator combination

Stedi now rejects 837P professional and 837I institutional claims where the Early and Periodic Screening, Diagnostic, and Treatment (EPSDT) certification indicator and the first EPSDT condition indicator contradict each other.

What are EPSDT certification and condition indicators?

Early and Periodic Screening, Diagnostic, and Treatment (EPSDT) is a mandatory federal Medicaid benefit for children and other beneficiaries under the age of 21. It covers routine checkups and screenings, plus any follow-up care those screenings show the patient needs.

837P professional and 837I institutional claims include dedicated fields for EPSDT services. A payer uses these fields to decide how coverage rules apply and whether to approve the services on the claim:

• EPSDT Certification Condition Code Applies Indicator, also called the EPSDT certification indicator – A yes/no flag for whether the patient needs follow-up care based on the screening. A value of N indicates the patient does not need follow-up care.

• EPSDT condition indicators – Two-character codes that describe whether the patient was referred for follow-up care and the outcome of that referral. For example: AV (Referral Available – Not Used), S2 (Under Treatment), or ST (New Services Requested). A value of NU (Not Used) indicates the screening didn’t result in a referral for follow-up care. A claim can contain one or more EPSDT condition indicators.

EPSDT certification indicator

EPSDT condition indicators

How the edit works

This edit compares the EPSDT certification indicator against the first EPSDT condition indicator:

• If the first condition indicator is NU (Not Used), the EPSDT certification indicator must be N.

• If the EPSDT certification indicator is N, the first condition indicator must be NU.

If the EPSDT certification indicator and first EPSDT condition indicator contradict each other, Stedi rejects the claim. This prevents later payer rejections, which take longer to resolve 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.

If the first condition indicator is NU but the EPSDT certification indicator is not N:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid EPSDT Condition Indicator. When the EPSDT condition indicator is 'NU' (not used), the EPSDT certification code applies indicator must be 'N' (no). Submitted indicator is 'Y'. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If the EPSDT certification indicator is N but the first EPSDT condition indicator is not NU:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid EPSDT Certification Condition Code Applies Indicator. When the EPSDT certification applies indicator is 'N' (no), the EPSDT condition indicator must be 'NU' (not used). Submitted indicator is 'AV'. 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.

If the first condition indicator is NU but the EPSDT certification indicator is not N:

STC*A7>527*[DATE]*U*[AMOUNT]******A8>564**Invalid EPSDT Condition Indicator. When the EPSDT condition indicator is 'NU' (not used), the EPSDT certification code applies indicator must be 'N' (no). Submitted indicator is 'Y'. Correct and resubmit.~

If the EPSDT certification indicator is N but the first EPSDT condition indicator is not NU:

STC*A7>564*[DATE]*U*[AMOUNT]******A8>527**Invalid EPSDT Certification Condition Code Applies Indicator. When the EPSDT certification applies indicator is 'N' (no), the EPSDT condition indicator must be 'NU' (not used). Submitted indicator is 'AV'. Correct and resubmit.~

Resolution tips

To avoid triggering this edit, match the claim’s EPSDT certification indicator and its first EPSDT condition indicator:

• Use EPSDT certification indicator N with an EPSDT condition indicator of NU (Not Used).

• Use EPSDT certification indicator Y with an EPSDT condition indicator of AV (Referral Available – Not Used), S2 (Under Treatment), or ST (New Services Requested).

Stedi is now CAQH CORE certified for claims, claim status checks, and ERAs

CAQH CORE has officially certified Stedi for claims, real-time claim status checks, and payment and remittance (ERAs).

Stedi was already CORE certified for eligibility checks. With this certification, we’re now CORE certified for all major HIPAA transaction types.

What is CAQH CORE?

The Council for Affordable Quality Healthcare (CAQH) is a non-profit backed by major health insurers and provider groups. The U.S. Department of Health and Human Services (HHS) designated CAQH as the official authoring entity for the operating rules that govern HIPAA administrative transactions.

HIPAA requires payers, providers, and clearinghouses to exchange transactions using the X12 EDI format. X12 defines the structure of each transaction, but leaves room for interpretation on response content, error handling, connectivity, and system availability. That gap creates inconsistencies that make systems harder to integrate.

CAQH created the Committee on Operating Rules for Information Exchange (CORE) to close that gap. The CORE Operating Rules build on X12 with stricter requirements for data content, standardized error messages, connectivity, and uptime and performance benchmarks. Certification confirms, through independent testing, that a system meets those rules.

What Stedi’s certification covers

Stedi is now CORE certified for:

• Claim submission – 837P professional, 837D dental, and 837I institutional claims

• Claim status – 276/277 real-time claim status checks

• ERAs – 835 Electronic Remittance Advice (ERAs)

• Eligibility checks – 270/271 eligibility and benefits (previously certified)

Why CORE certification matters

CORE certification is one of the few public signals that a clearinghouse's systems behave as expected. It confirms, through independent testing, that we meet defined benchmarks for each transaction type: standardized error codes, connectivity requirements, and uptime and response-time floors. Some payers also require CORE certification before opening a direct EDI connection.

Try Stedi

Start free with a sandbox account. Upgrade to production when you're ready. There are no monthly minimums or setup fees. You only pay for the transactions you use. See our pricing.

Blue Cross NC is now one-click enrollment

Healthcare payer Blue Cross NC (Payer ID: BCSNC) 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. 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.

Introducing single sign-on (SSO) and SCIM

Your team can now sign in to Stedi using single sign-on (SSO) and sync accounts automatically with directory sync (SCIM).

What is SSO?

SSO lets Stedi account members sign in to the Stedi portal through an identity provider, such as Okta or OneLogin, instead of using a separate Stedi username and password.

Stedi’s SSO supports SAML and OIDC, the protocols used by all major enterprise identity providers.

What is SCIM?

Directory sync (SCIM) automatically creates and removes Stedi accounts as you add or remove users in your provider. For example, when you deactivate an employee in Okta, SCIM automatically removes their access to Stedi.

Availability

SSO and SCIM are available by request on our custom pricing plan. To enable SSO/SCIM or to learn more about custom pricing, contact us.

To learn more about Stedi SSO and SCIM, see our documentation.