Changelog

Stedi Treasury now lets you reuse external bank accounts across billing entities

You can now link a Stedi Treasury billing entity to an external bank account that's already in your Stedi account. An external bank account is the bank account where a billing entity receives Automated Clearing House (ACH) payouts.

Previously, you repeated the account setup for each billing entity. Now you add the account once, and other billing entities select it from your existing accounts.

Change and archive accounts

You can also:

• Change a billing entity's external bank account – Select an existing account or add a new one. After you link and verify the new account, new payouts go to it. Payouts already in progress still go to the previous account.
• Archive an account you don't use anymore – If billing entities use the account, you select a replacement. Stedi moves those billing entities to the replacement, then archives the account. To use an archived account again, add it as a new account.

You can't remove a billing entity's external bank account without a replacement.

Members with the Admin or Developer role can link an existing account to a billing entity. Only members with the Admin role can add new accounts or archive accounts.

External bank accounts tab

The new External bank accounts tab on the Billing entities page lists every external bank account in your Stedi account. Each row shows the account's bank details, status, and the billing entities that use it.

An account's status is In use, Not in use, Pending verification, or Archived. Pending verification means the account needs micro-deposit verification – a small test deposit to the account – before it can receive payouts.

For more information, see our connect your bank and external bank accounts docs.

Claim edit: Colon in a field value

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims with a colon (:) in a field value.

How the edit works

X12 standards use delimiters – reserved characters that mark the boundaries between segments, elements, and components. Some payers and clearinghouses use the colon as a delimiter when they write claims.

Stedi checks name, address, and other text fields for a colon. If a field value contains one, 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

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "description": "Invalid character. The Subscriber First Name (2010BA/NM1-04) contains a reserved X12 delimiter character (colon). Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid character. The Subscriber First Name (2010BA/NM1-04) contains a reserved X12 delimiter character (colon). Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>481>HK*[DATE]*U*[AMOUNT]********Invalid character. The Subscriber First Name (2010BA/NM1-04) contains a reserved X12 delimiter character (colon). Correct and resubmit.~

Related claim edits

Stedi also rejects claims with an asterisk (*), greater-than sign (>), caret (^), grave accent (`), or tilde (~) in a field value. See Claim edit: Reserved X12 delimiter in a field value.

Claim edit: Unrecognized or inactive NDC

Stedi now rejects 837P professional and 837I institutional claims that contain an unrecognized or inactive National Drug Code (NDC).

NDCs and service dates

An NDC identifies a drug or biologic regulated by the U.S. Food and Drug Administration (FDA). A provider lists an NDC on a service line to get paid for a drug given during care.

National Drug Code

The service date is the date the provider performed the service. You report it on each service line.

Service date

How the edit works

The FDA lists NDCs in the NDC Directory, along with the dates each drug was on the market. Stedi checks each NDC against the directory for the service line's service date.

If the NDC isn't in the directory or wasn't on the market on the service date, 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

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "description": "Invalid NDC code. The submitted NDC 99999999999 on service line 1 is not a recognized code. Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "description": "Inactive NDC code. The submitted NDC 00052433001 on service line 1 was not marketed until 20130927, after the date of service. Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "description": "Expired NDC code. The submitted NDC 00052433001 on service line 1 was expired or inactive on the date of service. Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid NDC code. The submitted NDC 99999999999 on service line 1 is not a recognized code. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Inactive NDC code. The submitted NDC 00052433001 on service line 1 was not marketed until 20130927, after the date of service. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Expired NDC code. The submitted NDC 00052433001 on service line 1 was expired or inactive on the date of service. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>218**U*********Invalid NDC code. The submitted NDC 99999999999 on service line 1 is not a recognized code. Correct and resubmit.~

STC*A7>218**U*********Inactive NDC code. The submitted NDC 00052433001 on service line 1 was not marketed until 20130927, after the date of service. Correct and resubmit.~

STC*A7>218**U*********Expired NDC code. The submitted NDC 00052433001 on service line 1 was expired or inactive on the date of service. Correct and resubmit.~

Related claim edits

Stedi has another edit for NDCs that aren't 11 digits. See Invalid NDC format.

Filter payouts by status and billing entity in the Stedi portal

The Stedi portal's Payouts page has two new list filters:

• Status – Shows payouts with a specific processing status: Pending, In-transit, Paid out, or Failed.
• Billing entity – Shows payouts for one of your account's billing entities.

Previously, the Payouts page listed every payout for your Stedi account with no filters. Now you can find a specific billing entity's payouts, or payouts with a specific status.

For example, you can set the Status filter to Failed and use the Billing entity filter to review a specific billing entity's failed payouts.

For more information, see our filter payouts docs.

Introducing enrollment status update requests in the Stedi portal

You can now request a status update for a delayed transaction enrollment from the Stedi portal.

Previously, you had to copy the enrollment ID and contact Stedi support to ask about a delayed enrollment. Now you can send the request from the enrollment's details page.

How status update requests work

Each payer has a published enrollment timeframe for each transaction type. The timeframe starts when an enrollment enters PROVISIONING status – the point when Stedi sends it to the payer.

Until the timeframe elapses, most enrollments show a This enrollment is on track notice. It shows the date Stedi sent the enrollment to the payer and the expected processing time.

If the enrollment takes longer than expected, the details page shows a This enrollment is taking longer than expected notice. Click Request status update in the notice to open a prefilled support message.

The message includes the enrollment ID, payer, provider, transaction type, and submission date. Stedi checks the enrollment, follows up with the payer when needed, and replies by email.

For more information, see our review enrollment details docs.

The Stedi portal now lets you report missing ERAs

You can now report missing Electronic Remittance Advice (ERAs) from a form in the Stedi portal.

Previously, Stedi support followed up on missing ERA reports to ask for payment details. Now, the form collects them up front and sends them to Stedi support in a ticket.

To open the form, click Report a missing ERA in one of these places:

• Enrollment details page – For ERA enrollments with a LIVE status. The form fills in the enrollment's payer and provider.
• ERA list – When your filters return no results. The form fills in the payer and provider from your filters, if you set them.

In the form, enter the Payment amount, Date received, and EFT or check number for each payment. Stedi support uses these details to find the ERA with the payer.

To report more than one payment, click Add payment.

When you select a payer and provider, the form shows their ERA enrollment. The form also warns you about common reasons for a missing ERA, such as an enrollment that isn't live yet.

Before you click Submit ticket, you must confirm that the form doesn't include Protected Health Information (PHI). PHI is patient data, such as names, dates of birth, or member IDs.

Eligibility checks now show the patient's name

The Stedi portal and eligibility PDFs now label each eligibility check with the patient's name. When a check includes a dependent, the dependent is the patient.

Previously, the portal and eligibility PDFs always labeled each check with the subscriber's name, even for a dependent's check. The subscriber is the person who holds the insurance policy. This made the dependent's benefits look like the subscriber's.

Now, the patient's name appears in these places:

• Checks view – The Subscriber column is now the Patient column. Hover over a dependent's name to see the dependent's and the subscriber's names.
• Check details – The breadcrumb and the Overview title show the patient's name. For a dependent, the title can also show Dependent of and the subscriber's name.
• Eligibility PDFs – The PDF header matches the Overview title.

The Member ID column still shows the subscriber's member ID.

For more information, see our eligibility views docs.

Eligibility and claim status checks now fill in missing provider names

Stedi has made the provider name (first and last name, or organization name) optional in the following endpoints:

• Real-Time Eligibility Check JSON
• Real-Time Eligibility Check JSON (legacy)
• Real-Time Eligibility Check Raw X12
• Real-Time Eligibility Check SOAP
• Batch Eligibility Check JSON
• Real-Time Claim Status JSON
• Real-Time Claim Status Raw X12

If you leave the provider name out, Stedi fills it in from the provider's National Plan and Provider Enumeration System (NPPES) record.

Why the provider name matters

In eligibility and claim status checks, most payers use only the National Provider Identifier (NPI) and ignore the provider name. But Stedi has observed that some payers respond differently based on the provider name. If the name doesn't match the one in their backend system, they can return different benefits and claim status information.

For example, an eligibility check for NPI 1999999984 uses the name ACME Health Services. But some payers have the name ACME Health Services, Inc. in their backend system. Certain payers will return a limited set of benefits. If they include network status, they can even return the incorrect status for a given NPI.

Most payers use NPPES as the source of truth for provider names. As such, we recommend that you omit the provider name and let Stedi fill it in from NPPES. Only include the name if you believe the name in the payer's backend system is different from the name in NPPES. We don't recommend sending placeholder values like PROVIDER.

How it works

When the last name or organization name is missing, Stedi looks up the provider's NPI in NPPES. If the NPI has an active NPPES record, Stedi uses the record's primary name, which depends on the NPI type:

• Individual (Type 1) NPIs – The last name, plus the first name, middle name, and suffix when the record has them.
• Organization (Type 2) NPIs – The organization name.

Stedi also sets the entity type – individual or organization – to match the record. It doesn't use other names on the record, such as a doing business as (DBA) name. If the NPPES name is too long for the payer's transaction, Stedi shortens it. If Stedi can't get a name from NPPES, it uses PROVIDER.

If you include a provider name, Stedi doesn't replace it. This includes placeholders, such as PROVIDER, and names that don't match NPPES. We made this optional instead of replacing names because payers can theoretically use their own name records instead of NPPES. We haven't identified specific payers that do this. But we don't want to negatively affect requests where you chose a non-NPPES name intentionally.

This new functionality doesn't add transaction latency. Stedi performs all NPPES lookups locally in its own copy of the NPPES database. NPPES updates are released weekly. So name changes in NPPES will take up to one week to update in Stedi's copy.

For more information, see Provider name in our docs.

Filter claims by who rejected them in the Stedi portal

You can now filter claims in the Stedi portal's claims view by who rejected them – Stedi or the payer.

Previously, the Status filter had one Rejected option. Now you can expand Rejected and select By Stedi or By payer.

This lets you handle each type of rejection separately. For example, you can combine By payer with the Payer filter to review one payer's rejections. You can also review By Stedi rejections over a date range to find recurring errors.

A Stedi rejection happens before Stedi sends the claim to the payer. A payer rejection happens before adjudication. It can happen even after the payer acknowledges receipt.

For more information, see our filter claims docs.

Claim edit: Multiple prior authorization or referral numbers on a service line

Stedi now rejects 837P professional and 837D dental claims that report more than one prior authorization number or referral number on a service line for the payer you're sending the claim to.

Service line prior authorization and referral numbers

A prior authorization is the payer's approval of a service before the provider performs it. A referral is a provider's recommendation that the patient see another provider. Some plans, such as HMOs, require a referral before they cover a specialist visit. The payer assigns a number to each.

Service line prior authorization number

Service line referral number

How the edit works

Per X12 standards, a prior authorization or referral number without a payer identifier belongs to the payer you're sending the claim to. A service line can have only one of each for that payer.

To report another payer's prior authorization number, such as the primary payer's in a coordination of benefits (COB) claim, include that payer's identifier in otherPayerPrimaryIdentifier (REF-04 with qualifier 2U). In the CMS-1500 API, use otherPayerPrimaryId. The JSON API doesn't support payer identifiers for referral numbers, so report only one per service line.

If a service line reports more than one, 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

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "description": "Invalid Prior Authorization Number. Only one prior authorization number for the destination payer is allowed per service line. Other payers' numbers need a payer identifier (2U). Line 1 reports 2 without one. Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Prior Authorization Number. Only one prior authorization number for the destination payer is allowed per service line. Other payers' numbers need a payer identifier (2U). Line 1 reports 2 without one. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Referral Number. Only one referral number for the destination payer is allowed per service line. For other payers' numbers, include the payer identifier (2U). Line 1 reports 2 without one. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>252>HK**U*******A8>247**Invalid Prior Authorization Number. Only one prior authorization number for the destination payer is allowed per service line. Other payers' numbers need a payer identifier (2U). Line 1 reports 2 without one. Correct and resubmit.~

STC*A7>761>HK**U*******A8>247**Invalid Referral Number. Only one referral number for the destination payer is allowed per service line. For other payers' numbers, include the payer identifier (2U). Line 1 reports 2 without one. Correct and resubmit.~

Related claim edits

Stedi has other edits for service line prior authorization and referral numbers. See Prior authorization number matches the referral number and Service-line referral number without a claim-level referral number.

Introducing the Billing member role

You can now assign the Billing role to members of your Stedi account.

Previously, a member needed the Admin role to manage billing. That role also gives access to transactions, which contain protected health information (PHI).

Now, finance and billing staff can manage billing without access to PHI.

Billing members can:

• View and pay invoices
• Replace the payment method
• Edit billing details and billing email addresses
• Add prepaid credits with a manual top-up
• Get billing and payment notifications

Billing members can't change the pricing plan. They also can't access transactions, API keys, members, or other settings.

Each member has one role, so a member who needs billing access and access to other resources needs the Admin role. An account can have up to 5 billing members, including pending invitations.

Admins can assign the Billing role from the Members page in your account settings.

For more information, see our member roles docs.

Eligibility PDFs are now available within milliseconds

Stedi's eligibility PDFs are now typically available within milliseconds after an eligibility check completes. A small number of PDFs take slightly more than one second.

Previously, a PDF became available 4-20 seconds after the check, requiring users to add a delay before attempting to retrieve the PDF.

You can now call the Retrieve Eligibility PDF API endpoint as soon as you get the eligibility check response. The endpoint returns an HTTP 404 error until the PDF is available.

The endpoint and the PDFs are unchanged. You don't need to update your integration.

Introducing real-time validation in Stedi's CMS-1500 form

Stedi's CMS-1500 form now checks your claim for errors as you fill it out, including errors that would fail Stedi's claim edits.

Previously, the form checked the claim only when you clicked Submit claim. If the claim failed a claim edit, Stedi still created the claim and then rejected it with a 277CA claim acknowledgment.

Now, Stedi shows errors when you leave each box. It doesn't submit the claim until you fix every error. When you resubmit a claim using the form, Stedi shows its existing errors, including failed claim edits, as soon as the form opens.

Real-time validation also works when you use the CMS-1500 form in test mode.

For more details, see our announcement blog.

Claim edit: Invalid remark code in COB claims

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that report an invalid remark code from a previous payer.

Remark codes in COB claims

When a patient has more than one insurance plan, say a child covered by both parents' health insurance, claims go to the primary payer first, then the secondary, and so on. This is called coordination of benefits (COB).

Claims sent to non-primary payers can include the Remittance Advice Remark Codes (RARCs) from a previous payer's explanation of benefits (EOB) or Electronic Remittance Advice (ERA). A remark code gives more detail about why that payer adjusted the claim's payment.

Outpatient adjudication remark codes

Inpatient adjudication remark codes

How the edit works

Each remark code must be a valid RARC and active on the date the previous payer adjudicated the claim. If it isn't, 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

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Claim Payment Remark Code (RARC). Other payer 60054, payer responsibility P, reported code(s) ZZ99 that are not in the X12 remittance advice remark code list. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Expired Claim Payment Remark Code (RARC). Other payer 60054, payer responsibility P, reported code(s) M33 (2004-07-31) that expired before the 2024-03-15 adjudication. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Claim Payment Remark Code (RARC) Not Yet Effective. Other payer 60054, payer responsibility P, reported code(s) N905 (2025-03-01) that took effect after the 2024-03-15 adjudication. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>634>GB*[DATE]*U*[AMOUNT]********Invalid Claim Payment Remark Code (RARC). Other payer 60054, payer responsibility P, reported code(s) ZZ99 that are not in the X12 remittance advice remark code list. Correct and resubmit.~

STC*A7>634>GB*[DATE]*U*[AMOUNT]********Expired Claim Payment Remark Code (RARC). Other payer 60054, payer responsibility P, reported code(s) M33 (2004-07-31) that expired before the 2024-03-15 adjudication. Correct and resubmit.~

STC*A7>634>GB*[DATE]*U*[AMOUNT]********Claim Payment Remark Code (RARC) Not Yet Effective. Other payer 60054, payer responsibility P, reported code(s) N905 (2025-03-01) that took effect after the 2024-03-15 adjudication. Correct and resubmit.~

Related claim edits

Stedi has another edit for COB claims without the previous payer's adjudication date. See Missing other payer adjudication date in COB claims.

Claim edit: Attachment control number for an attachment available on request

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include an attachment control number for an attachment that's only available on request.

Attachment transmission codes and control numbers

A claim can reference attachments, such as X-rays or treatment plans. The attachment transmission code says how the provider sends each attachment to the payer. The AA (Available on Request at Provider Site) code means the provider doesn't send it. The payer must ask for it.

Attachment transmission code

The attachment control number lets the payer match an attachment to the claim.

Attachment control number

How the edit works

An attachment that's only available on request has nothing for the payer to match. X12 HIPAA standards say to leave out the attachment control number in this case. If the claim includes one, 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

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Attachment Control Number. When the attachment transmission code is 'AA' (Available on Request at Provider Site) the attachment control number must not be submitted. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>489*[DATE]*U*[AMOUNT]******A7>732**Invalid Attachment Control Number. When the attachment transmission code is 'AA' (Available on Request at Provider Site) the attachment control number must not be submitted. Correct and resubmit.~

Related claim edits

Stedi has another edit for attachments the provider sends without an attachment control number. See Missing attachment control number.

Claim edit: Missing ambulance transport information

Stedi now rejects 837P professional claims for ambulance services that don't include ambulance transport information.

Place of service and ambulance transport information

A place of service code of 41 (Ambulance – Land) or 42 (Ambulance – Air or Water) marks an ambulance claim.

Place of service code

An ambulance procedure code identifies the service, but not the details of the transport. Ambulance transport information gives the reason for the transport and the distance. Payers use these details to evaluate coverage, medical necessity, and payment.

Ambulance transport information

How the edit works

X12 standards require ambulance claims to include ambulance transport information at the claim level. Ambulance transport information on a service line doesn't replace it. If an ambulance claim omits the claim-level information, 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

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "description": "Missing Ambulance Transport Information. When a claim indicates ambulance services (POS 41, 42), the ambulance transport information segment (CR1) is required. Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Ambulance Transport Information. When a claim indicates ambulance services (POS 41, 42), the ambulance transport information segment (CR1) is required. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A6>428*[DATE]*U*[AMOUNT]********Missing Ambulance Transport Information. When a claim indicates ambulance services (POS 41, 42), the ambulance transport information segment (CR1) is required. Correct and resubmit.~

Claim edit: Missing CLIA number for a lab test

Stedi now rejects 837P professional claims that bill a lab test without a Clinical Laboratory Improvement Amendments (CLIA) number.

Lab tests and CLIA numbers

A CLIA number identifies a lab that's certified to test human specimens. Payers require the number on claims that bill lab tests.

A service line reports the lab test as a procedure code.

Procedure code

You can report the CLIA number at the claim level or on individual service lines.

Claim-level CLIA number

Line-level CLIA number

How the edit works

The Centers for Medicare & Medicaid Services (CMS) lists lab test procedure codes in the Clinical Laboratory Fee Schedule (CLFS). Stedi checks each service line's procedure code against the CLFS for the line's service date.

If a line bills a lab test and has no CLIA number at either level, the payer may reject the claim. CLIA-waived tests still need a CLIA number.

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

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "description": "Missing CLIA Number. A Laboratory Test was billed on line 1, 87811, which requires a Clinical Laboratory Improvement Amendment (CLIA) number. This can be included at the claim or line-level. Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Missing CLIA Number. A Laboratory Test was billed on line 1, 87811, which requires a Clinical Laboratory Improvement Amendment (CLIA) number. This can be included at the claim or line-level. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A6>544**U*********Missing CLIA Number. A Laboratory Test was billed on line 1, 87811, which requires a Clinical Laboratory Improvement Amendment (CLIA) number. This can be included at the claim or line-level. Correct and resubmit.~

Related claim edits

Stedi has another edit for CLIA numbers in an invalid format. See Invalid CLIA number format.

Claim edit: Accident date after the service date

Stedi now rejects 837P professional and 837D dental claims where the accident date is after a service date.

Accident and service dates

The accident date is the date the injury occurred. You report it when a claim relates to an accident.

Accident date

The service date is the date the provider performed the service. You report it on each service line.

Service date

In dental claims, the service-line service date is optional. When a service line omits it, the claim-level service date in claimInformation.claimDateInformation.serviceDate (DTP-03 of Loop 2300) applies.

How the edit works

An accident date ties the claim's services to that accident. A service before the accident can't result from it. If the accident date is after a service date, 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

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "description": "Invalid Accident Date. The accident date must be on or before the service date. The submitted accident date, 20240305, is after the service date, 20240301 on line 1. Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Accident Date. The accident date must be on or before the service date. The submitted accident date, 20240305, is after the service date, 20240301 on line 1. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>727*[DATE]*U*[AMOUNT]******A8>187**Invalid Accident Date. The accident date must be on or before the service date. The submitted accident date, 20240305, is after the service date, 20240301 on line 1. Correct and resubmit.~

Related claim edits

Stedi has another edit for accident-related claims without an accident date. See Missing accident date.

Claim edit: Mismatched DME procedure code on a service line

Stedi now rejects 837P professional claims with a service line where the durable medical equipment (DME) procedure code doesn't match the line's procedure code.

How the edit works

DME is equipment a patient uses at home over time, such as a wheelchair or an oxygen concentrator.

A service line can report a procedure code in two places:

• SV1-01-02 (Procedure Code) of Loop 2400 (Service Line Number) – the code for the billed service
• SV5-01-02 (Procedure Code) of Loop 2400 (Service Line Number) – the code for the DME

X12 standards require the two codes to match. If they differ, the payer may reject the claim.

The JSON Professional Claims endpoint doesn't accept a separate DME procedure code. The edit applies only to claims you submit as raw X12 or through SFTP.

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

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Durable Medical Equipment procedure code. The DME procedure code must match the service procedure code on the same line. Line 1 reports DME code 99901 against procedure code 80369. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>454**U*******A8>490**Invalid Durable Medical Equipment procedure code. The DME procedure code must match the service procedure code on the same line. Line 1 reports DME code 99901 against procedure code 80369. Correct and resubmit.~

Claim edit: Missing DME certification revision date

Stedi now rejects 837P professional claims that renew or revise a durable medical equipment (DME) certification without a certification revision date.

DME certifications and revision dates

A DME certification is the provider's statement that a piece of equipment, such as a wheelchair, is medically necessary. The certification type code tells the payer whether the certification is I (Initial), R (Renewal), or S (Revised).

Certification type code

The certification revision date tells the payer when a change to the patient's certified DME needs took effect. This helps the payer confirm medical necessity.

Certification revision date

How the edit works

HIPAA standards require a certification revision date when the certification type code is R or S. If a service line omits the date, 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

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Certification Revision/Recertification Date. The certification on line 1 is a renewal (type R) or revision (type S), but the required certification revision/recertification date is missing. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A6>335**U*********Missing Certification Revision/Recertification Date. The certification on line 1 is a renewal (type R) or revision (type S), but the required certification revision/recertification date is missing. Correct and resubmit.~