Changelog

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

Introducing global search in the Stedi portal

You can now find records and open pages from one search field in the Stedi portal.

Previously, the find-by-ID search only opened a record from its exact ID. To find records by other values, like an NPI, you filtered each list page. Now, one search checks those filters across your list pages at once.

To open the search, press Cmd+K on Mac or Ctrl+K on Windows. You can also click the search field under the account menu in the sidebar.

You can type a page name to go to that page. For example, new check opens the form for a new eligibility check. You can also paste a record ID to search for that record.

To search records, type a value like a provider's NPI. The search shows how many records match in each product your account can use, such as claims, ERAs, or eligibility checks. Each result opens the list page with that filter applied.

You can search these records:

• Eligibility checks – Member ID or provider NPI
• Eligibility searches – Provider NPI
• Claims – Patient Control Number (PCN), patient name, member ID, or billing provider NPI or tax ID
• ERAs – Trace number, PCN, or payee name, NPI, or tax ID
• Payments – ACH trace number, reassociation trace number, or check number
• Enrollments – Enrollment ID, provider NPI or tax ID, payer name or ID, or user email
• Transactions – Words in the content or control numbers (transaction or functional group)

Most searches need the whole value, like a full NPI or member ID. Eligibility check and eligibility search results only cover the last month. To find older results, adjust the date filter on the list page.

For more information about each list page's filters, see our claims view and eligibility views docs.

Introducing the redesigned insurance discovery detail page

Insurance discovery checks you submit in the Stedi portal now show their results on a redesigned detail page.

Previously, the detail page listed coverages in the order they were discovered and showed benefits as a static list.

Now, the page uses the same structure as the redesigned eligibility check view. The redesign includes:

• Coverage status – A banner at the top of each coverage shows its number and status.
• Filterable benefits table – Each coverage uses the benefits table and filters from eligibility checks, so you can narrow the list to the benefits you need.
• Active coverage first – The page opens on the first active coverage, when there is one.
• Coverage navigation – A dropdown in the header switches between coverages when the check finds more than one.

For more details, see our announcement blog.

Claim edit: Invalid claim frequency code

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims with a claim frequency code that isn't valid for the claim type.

Claim frequency codes

The claim frequency code tells the payer whether a claim is an original claim, a replacement, a void, or another type of submission.

Claim frequency code

The valid codes depend on the claim type:

• 837P professional and 837D dental claims – 1 (Original), 7 (Replacement of Prior Claim), or 8 (Void/Cancel of Prior Claim).
• 837I institutional claims – A National Uniform Billing Committee (NUBC) frequency code, such as 1 (Admit thru Discharge Claim), 7 (Replacement), or 8 (Void).

How the edit works

If a claim uses a code outside this set, 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 Frequency Code. The submitted frequency code, 6, is not a recognized claim frequency code for this claim type. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>535*[DATE]*U*[AMOUNT]********Invalid Claim Frequency Code. The submitted frequency code, 6, is not a recognized claim frequency code for this claim type. Correct and resubmit.~

Related claim edits

Stedi has another edit for claim frequency codes that conflict with the patient status code. See Invalid claim frequency code and patient status code combination.

Claim edit: Missing billing provider taxonomy code in dental claims

Stedi now rejects 837D dental claims that are missing a billing provider taxonomy code when no rendering provider or assistant surgeon is reported.

How the edit works

A taxonomy code identifies a provider's type and specialty, such as general dentistry or orthodontics.

A dental claim can name a rendering provider or an assistant surgeon for the whole claim or for individual service lines. If the claim names neither at any level, the billing provider is the one who rendered the service. In that case, X12 standards require the claim to include the billing provider's taxonomy code.

Billing provider taxonomy code

If the billing provider taxonomy code is missing, 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 Billing Provider taxonomy code. This code is required when no rendering provider or assistant surgeon is reported. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A6>145>85**U*[AMOUNT]******A6>732~

Related claim edits

Stedi has other edits that check the taxonomy code when it's present. See:

• Invalid taxonomy code
• Taxonomy code not in the NUCC code set

Claim edit: Prior authorization number matches the referral number

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that report the same value for the prior authorization number and the referral number.

Prior authorizations and referrals

A prior authorization is the payer's approval of a service before the provider performs it. The payer assigns a number to each approval. You can report the prior authorization number at the claim level or on a service line.

Prior authorization number

Service line prior authorization number

A referral is a provider's recommendation that the patient can see another provider – for example, a primary care provider who sends the patient to a specialist. Some plans, such as HMOs, require a referral before they cover a specialist visit. Each referral has its own number.

Referral number

Service line referral number

How the edit works

A prior authorization and a referral are different approvals, so their numbers shouldn't match. If you submit a claim with the same value in both fields, the payer may reject the claim.

The edit compares the numbers at the claim level and on each service line. When a service line reports only one of the numbers, the edit compares it to the other number at the claim level. The comparison ignores letter case.

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. The prior authorization number, PA20261009, cannot be the same value as the referral number. Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Prior Authorization number. The prior authorization number, PA20261009, cannot be the same value as the referral number. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A8>761>QC*[DATE]*U*[AMOUNT]******A8>252>QC**Invalid Prior Authorization number. The prior authorization number, [PRIOR AUTHORIZATION NUMBER], cannot be the same value as the referral number. Correct and resubmit.~

Related claim edits

Stedi has another edit for service line referral numbers. See Service-line referral number without a claim-level referral number.

Claim edit: Service-line referral number without a claim-level referral number

Stedi now rejects 837P professional claims that report a referral number on a service line but not at the claim level.

Claim-level and service-line referral numbers

A referral number is the number a payer assigns when it approves a referral to another provider. For example, a payer may require a referral before a patient sees a specialist.

You can report the referral number at two levels. The claim-level referral number applies to every service line on the claim.

Claim-level referral number

A service-line referral number applies to a single service line.

Service-line referral number

How the edit works

Per HIPAA standards, the claim-level referral number applies to every service line. You can also report a referral number on a service line when it differs from the claim-level number. Without a claim-level referral number, there's nothing for the line to differ from.

If a claim reports a referral number on a service line but omits the claim-level referral number, 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 Line-Level Referral Number. The service-line referral number on line 1, REF789012, should not be submitted when a claim-level referral number is not 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, entity identifier code, and error message:

STC*A7>247*[DATE]*U*[AMOUNT]******A7>761>QC**Invalid Line-Level Referral Number. The service-line referral number on line 1, REF789012, should not be submitted when a claim-level referral number is not present. Correct and resubmit.~

Related claim edits

Stedi has another edit for a referring provider on a service line without one at the claim level. See Missing claim-level referring provider.

Introducing the redesigned eligibility check view

You can now review an eligibility check's result, summary, and benefits on one page in the Stedi portal's checks view.

Previously, each check had separate Overview and Benefits tabs. Plan details and benefit-related entities were on the Overview tab, apart from the benefits they applied to.

Now, the benefits table is part of the Overview tab. The redesign includes:

• Status banner and summary – A banner at the top of the page shows the check's result, above a summary of the check's details.
• Plan details – Plan names, group numbers, plan numbers, and plan dates appear in the benefits table.
• Coverage statuses – Each status has its own Statuses row in the benefits table.
• Related entities column – Benefit-related entities have their own column in the benefits table.
• Benefits filters – The benefits table has 15 filters, up from 7.

For more details, see our announcement blog.

Filter claims by billing provider name in the Stedi portal

You can now filter claims in the Stedi portal's claims view by billing provider name.

Previously, you could only filter by the billing provider's NPI or Tax Identification Number (TIN). Now you can find a provider's claims by name, without looking up an identifier.

The filter supports partial matching, so you can enter part of the provider's name. If a claim has resubmissions, it matches when any of its submissions has a matching billing provider name.

For more information, see our filter claims docs.

Test ERAs now support denials and partial payments

Stedi's test claims workflow now returns denied and partially paid test Electronic Remittance Advice (ERAs).

The test claims workflow lets you submit a test claim to the Stedi Test Payer and get a test ERA. You can choose the payment outcome with a prefix on the subscriber's member ID.

Previously, every test ERA showed every service line as paid in full. Now, the same test claims can return a denied or partially paid test ERA. You can validate how your system posts denials, contractual adjustments, and patient responsibility before you send production claims.

Submitting the test claim

To choose a payment outcome, add STEDI_PAID_, STEDI_PARTIALLY_PAID_, or STEDI_DENIED_ to the front of the subscriber's member ID. The prefix works for professional, dental, and institutional claims. It applies to every service line on every claim for that subscriber.

For example, in a Professional Claim (CMS-1500) JSON API request:

{
  "insured": {
    "memberId": "STEDI_DENIED_0000000001", // Returns a denied test ERA.
    ...
  },
  ...
}

Receiving the test ERA

The prefix determines what the test ERA reports for each service line, using fixed amounts. A missing or unrecognized prefix returns a fully paid test ERA.

Test ERAs only support primary claims. Paid and partially paid test ERAs report the claim status as processed as primary, with payment method ACH. Denied test ERAs report the claim status as denied, with payment method NON (no payment).

Test ERAs can't simulate every production outcome, such as split or bundled claims.

Requirements

You need an ERA enrollment with the Stedi Test Payer. If Stedi's claim edits reject the claim, you don't get a test ERA.

For more information, see our test ERA scenarios docs.

Claim edit: Paper claims missing referenced attachments

Stedi now rejects 837P professional, 837D dental, and 837I institutional paper claims that reference an electronic attachment you didn't send in the same submission.

Paper claims and attachments

With paper claims, Stedi prints the claim and mails it to the payer. If the claim references a 275 claim attachment, Stedi prints the attachment and mails it in the same package.

A claim references an electronic attachment with an attachment control number and a transmission code of EL (Electronically Only). For SFTP submissions, the matching 275 must be in the same interchange (ISA/IEA envelope) as the claim.

How the edit works

The edit only runs on paper claims – claims with the receiver ID set to PAPER. If you submit a paper claim that references an attachment you didn't include in the same submission, the payer gets the claim without its supporting documents and 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

Stedi runs this edit when it prepares the claim for printing, after it accepts the submission. So the Claim Submission API endpoints don't return an error in real time for this edit.

If you submit a claim using the API or 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>21*[DATE]*U*[AMOUNT]******A6>294*A6>489*Missing Attachment. This claim requires the referenced attachment to be submitted as part of the same submission. Correct and resubmit.~

To fix the claim, resubmit it together with the attachment it references.

Related claim edits

Stedi has another edit for claims that indicate an attachment but don't include an attachment control number. See Claim edit: Missing attachment control number.

Claim edit: Reserved X12 delimiter in a field value

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims with a field value that contains a character reserved as an X12 delimiter.

How the edit works

X12 standards require that a small set of characters be used only to mark the boundaries between segments, elements, and components. Stedi rejects a claim when one of them appears inside a field value: asterisk (*), greater-than sign (>), caret (^), grave accent (`), or tilde (~).

The edit checks every text field in the claim. Characters that aren't delimiters pass – the apostrophe in O'BRIEN and the hyphen in SMITH-JONES CLINIC are both valid. So is the colon, which an 837 doesn't use as a delimiter.

A reserved character inside a value collides with those boundaries, so the claim can't be read as valid X12. 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 (greater-than sign). Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid character. The Subscriber First Name (2010BA/NM1-04) contains a reserved X12 delimiter character (greater-than sign). 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 (greater-than sign). Correct and resubmit.~

The error names the field and the character, but never repeats the value you submitted – that would put the delimiter back into the acknowledgment.

If more than one field in a claim contains a reserved character, you get one rejection per field.

Related claim edits

Stedi has another edit for field values that run longer than the maximum length allowed by X12 standards. See Claim edit: Field values longer than maximum length.

Event destinations now support file processing events

You can now subscribe to file processing events using event destinations:

• file.processed – Stedi generates this event when it successfully processes a file, such as a 277CA claim acknowledgment from a payer.

• file.failed – Stedi generates this event when it fails to process a file, such as an SFTP claim submission it can't parse.

• transaction.processed – Stedi generates this event when it translates a transaction, such as a payer's Electronic Remittance Advice (ERA) into JSON.

You can subscribe on the Stedi portal's Event Destinations page, with the Event Destination APIs, or with the Stedi SDKs.

An installed OAuth app can also subscribe to these events in its provider's account.

Event payloads

Stedi events use a thin event schema. A thin event notifies you that a resource changed, but it doesn't include the resource's data.

A single file with multiple transactions produces one file.processed event and one transaction.processed event per transaction. The relatedResources array identifies the transaction type.

{
  ...
  "resource": {
    "id": "019bb508-dc63-73a1-8ddc-9d4720299072",
    "type": "transaction"
  },
  "relatedResources": [
    {
      "id": "019bb508-dc63-73a1-8ddc-9d4720299072",
      "type": "transaction.x12.835" // ERA
    }
  ],
  "type": "transaction.processed"
}

Once you receive an event, retrieve the details using Stedi's APIs or the Stedi portal:

• transaction.processed – Pass the transaction ID in relatedResources to the Get 835 ERA Report or Get 277CA Report endpoint.

• file.processed and file.failed – Pass the execution ID in resource.id to the Retrieve File Execution Input endpoint.

For event schemas, see our event types reference.

Introducing Agentic Discovery

You can now find a patient's insurance coverage and benefits in one click using Agentic Discovery.

Agentic Discovery combines eligibility checks, automated check recovery, and insurance discovery into a single, automated workflow.

With Agentic Discovery, you start by entering the data you have about a patient, such as name, date of birth, and – if you know it – the payer ID. The agent runs an eligibility check. If the check succeeds, the agent stops. If the check fails, the agent tries to recover it using Stedi's best practices. For example, the agent may try follow-up eligibility checks with variations of the patient's name.

If recovery fails, the agent then runs an insurance discovery check. Insurance discovery checks can find coverage based on limited information, even if the original eligibility check had missing or incorrect information.

Previously, you had to manually sequence and run each of these steps separately.

Agentic Discovery is now the default way to run eligibility checks in the Stedi portal. It also replaces the previous iteration of eligibility check recovery in the Stedi Agent. The Resolve with Stedi Agent option is still there, but it now runs the more complete Agentic Discovery check instead.

Watch the 2026 Stedi Keynote announcement:

How to run an Agentic Discovery check

You can start an Agentic Discovery check from the Stedi portal in three ways:

• Click + New eligibility check in the checks view, fill out the form, then under Run as, click Agentic Discovery.
• Select Agentic Discovery on the Stedi Agent's Chats page.
• Click Launch Agentic Discovery for failed eligibility checks in the checks view.

The last two options open a form in the Stedi Agent. To run an Agentic Discovery check, enter or change the patient, provider, and payer details, then click Submit.

To run a standard eligibility check without Agentic Discovery, click + New eligibility check, fill out the form, then under Run as, click Single eligibility check.

What data do I need to run an Agentic Discovery check?

You only need to provide:

• The patient's first name
• The patient's last name
• The patient's date of birth, member ID, or Social Security Number (SSN)
• The provider's NPI

We recommend you include as much information as you have, such as the state of the patient's address. Additional information increases the chances of finding active coverage.

If you don't provide a date of service, the check defaults to today's date. If you don't provide a Service Type Code (STC), the check defaults to 30 (Health Benefit Plan Coverage).

If you don't provide a payer, the agent runs an insurance discovery check using the patient's information.

Transaction enrollment with the Stedi insurance discovery payer (payer ID: DISCOVERY) isn't required, but we strongly recommend it. Enrollment lets Stedi run Medicare Beneficiary Identifier (MBI) lookups as part of insurance discovery checks, which can improve results.

Availability and pricing

Agentic Discovery is available for all Stedi production accounts.

Agentic Discovery checks are priced per agent run. You won't be billed separately for underlying eligibility or insurance discovery checks the agent uses. For pricing, see our Pricing page.

Agentic Discovery isn't available in test mode or sandbox accounts. In test mode, use the standard eligibility check form to run mock eligibility checks.

For more details, see our announcement blog.

Introducing claim lifecycle tracking in the Stedi portal

You can now track a claim's full lifecycle – from submission to payer adjudication – in the Stedi portal's claims view. For example, you can see whether the payer denied a claim, or how much the payer paid.

Previously, information in the claims view was derived solely from claim submissions and related 277CA claim acknowledgments. To get payment information for a claim, you had to jump from the claim's timeline to Electronic Remittance Advice (ERAs) with a matching patient control number (PCN).

Now, the portal displays information from those ERAs directly in the claims view, including:

• Claim processing status – Whether the claim was processed, denied, rejected, or is still being processed.
• Amount paid – What the payer paid on the claim, next to the amount charged.
• Patient responsibility – The share the patient owes.
• Adjustments – Claim-level and service line adjustments.
• Denial reasons – Why the payer denied the claim.
• Reversals – Whether the payer reversed a previous payment.

Watch the 2026 Stedi Keynote announcement:

Claim filters

The claims list view has two new filters:

• Reversals – Claims with payment reversals, or claims without them.
• Amount paid – Claims with a minimum or maximum paid amount.

For example, you can set the new Amount paid filter's Min and Max values to 0 to see unpaid claims.

We've also renamed the existing Total charges column and filter to Amount charged. Other columns and filters remain unchanged.

New claim processing statuses

We've added three claim processing statuses that are derived from the claim's matched ERAs:

• Processed by payer – The payer completed adjudication and accepted responsibility for the claim. This doesn't mean the payer paid the claim in full, or paid it at all.
• Denied – The payer completed adjudication and denied responsibility for the claim.
• Unknown – Stedi can't determine a single status for the claim. This usually happens when the payer's responses are mixed or incomplete.

The Unknown status replaces the old Invalid status, which only applied to 277CA claim acknowledgments with unrecognized status codes.

The Submitted, Received, Rejected, and Accepted statuses remain unchanged. For more, see How we determine status in our docs.

Claim timeline

Each claim's timeline now includes a card for every claim payment information record from an ERA. Each card shows the claim processing status, the amount charged, the patient responsibility, the amount paid, and the ERA trace number.

Resubmissions carry their own payment records, so you see the payments tied to each attempt.

Claim payment information details

Hover over a claim payment information card and click See more detail to open its details. That view shows payment information for one claim:

• The linked claim, with a link back to its timeline.
• Claim-level payment information: total charged, total paid, patient responsibility, and adjustments. If the claim was denied, denial reasons are also included.
• Service line details, with line-level payment amounts and adjustments.

You can view the CLP (Claim Payment Information) segment of Loop 2100 for the related ERA in the X12 tab. You can also download a PDF for a single claim payment information record.

ERA detail view

Each ERA detail view has a claim payment information table with one row per claim payment information record. Click a row to open the details for that claim.

If you receive ERAs through Stedi but submit claims elsewhere, you still get the claim payment information details for each record in an ERA.

Availability and pricing

Claim lifecycle tracking is available now in the Stedi portal's claims view for all Stedi production accounts at no extra cost.

For more details, see our announcement blog.

Introducing OAuth Stedi apps

Stedi apps are pre-configured integrations between a provider's Stedi account and an external platform, like an electronic health record (EHR), practice management system, or revenue cycle management (RCM) system.

We're releasing a completely revamped, OAuth-based version of Stedi apps that allows deeper, more seamless integration with external applications. OAuth Stedi apps include several new features:

• One-click installation – Providers can install a Stedi app without copying API keys or SFTP credentials between Stedi and the app.

• Support sessions – App developers can open a time-limited support session in a provider's Stedi account.

• Self-provisioning – An installed Stedi app can create its own event destinations and SFTP users, run eligibility checks, and manage transaction enrollments in a provider's Stedi account.

• Self-service app registration – App developers can create an app and get OAuth credentials directly in the Stedi portal.

• Redesigned Stedi app store – App developers can list their app so providers can find and install it.

Previously, providers had to generate API keys and SFTP credentials and share them with the app developer. To provide support, the app developer's staff had to join the provider's Stedi account as members. That access lasted until the provider removed the members.

Now, industry-standard OAuth replaces that credential handoff. A provider installs an app by approving one consent screen. The app developer's support staff can work in a provider's Stedi account through a time-limited session instead of a standing login.

Important: We're not changing existing Stedi apps that use API keys or SFTP credentials as part of this release. All existing Stedi apps will continue working. If you're a current Stedi app developer who wants to upgrade to OAuth, contact us.

Watch the 2026 Stedi Keynote announcement:

One-click installation for providers

A provider can click an install link in the app developer's platform, or select the Stedi app in the redesigned Stedi app store. Stedi then shows a consent screen with the app's name and the exact permissions the app requests.

The provider approves, and the connection is live.

Support sessions

App installation grants the app developer the ability to run a time-limited support session in the provider's account. When a provider uninstalls the app, that ability is removed. Support sessions use the app's permissions – nothing more.

Self-provisioning

Once the provider approves the app, the app can set up the account itself. It calls Stedi APIs with its own tokens.

An app can create event destinations, create SFTP users, run eligibility checks, and manage transaction enrollments. It acts under the exact permissions the provider approved on the consent screen. Stedi labels each resource the app creates, so providers can see what the app manages.

Stedi also sends app.installed and app.uninstalled events to the app developer's own Stedi account. Providers can uninstall an app at any time, and its access ends within an hour.

Self-service for app developers

App developers can now register apps in the Stedi portal and get their OAuth credentials there. The entire process is self-service.

App developers can list their app in the redesigned Stedi app store so providers can find it. Each Stedi account can have one active app installed.

Pricing and availability

It's free to build and publish a Stedi app. There are no developer fees. It's also free for providers to install an app.

OAuth Stedi apps are in private preview. We're onboarding new Stedi app developers. Contact us if you want to build a Stedi app.

For more details, see our announcement blog.

Introducing our redesigned JSON Real-Time Eligibility Check API

We're releasing a redesigned version of our JSON Real-Time Eligibility Check API endpoint: POST https://healthcare.us.stedi.com/2026-06-01/eligibility-check.

The new endpoint's response format makes it easier to parse a patient's benefits.

The legacy JSON Real-Time Eligibility Check API endpoint returns responses in a structure that mirrors the X12 eligibility response. Benefits for different plans and different benefit types are intermixed in a flat benefitsInformation array. The array is "polymorphic": the fields in each entry change depending on the benefit type. The responses also use X12 codes, like C for a deductible or F for limitations, so you map each one to its meaning.

The new endpoint removes the polymorphism. It groups benefits by health plan. In each plan, it breaks the payer's benefit details out into separate typed objects: statuses (for example: ACTIVE_COVERAGE and INACTIVE), coPayment, coInsurance, deductible, and more. It spells values out: ACTIVE_COVERAGE instead of 1, IN_NETWORK instead of Y. Each benefit names the Service Type Code (STC) or procedure code it applies to.

{
  "payerId": "87726",
  "plans": [
    {
      "name": "Gold Plan HMO",
      "benefits": {
        "statuses": [
          {
            "status": "ACTIVE_COVERAGE",
            "coverageLevel": "INDIVIDUAL",
            "network": { "indicator": "IN_AND_OUT_OF_NETWORK" },
            "service": {
              "system": "STC",
              "value": "30",
              "definition": "Health Benefit Plan Coverage"
            }
          }
        ],
        "coPayment": [
          {
            "amount": "15",
            "coverageLevel": "INDIVIDUAL",
            "messages": ["SPECIALIST"],
            "network": { "indicator": "IN_NETWORK" },
            "service": {
              "system": "STC",
              "value": "96",
              "definition": "Professional (Physician)"
            },
            "timePeriod": "VISIT"
          }
        ]
      }
    }
  ],
  ...
}

To run checks with the new endpoint, you only need to provide the same information you use to run eligibility checks today: the payer ID, the provider's name and NPI, the patient's details, and the STC or procedure code you want benefits for.

Watch the 2026 Stedi Keynote announcement:

Test mode support

You can use the new endpoint to run pre-defined mock eligibility checks in test mode with a test API key. Mock eligibility checks are available on all Stedi accounts, including free sandbox accounts.

Existing integrations

We're not deprecating the legacy JSON Real-Time Eligibility Check API endpoint or any other functionality as part of this release.

This release doesn't introduce any breaking changes. Your existing integrations will continue working as they do today.

Availability and pricing

The new endpoint is available on all Stedi accounts.

Mock eligibility checks are free. Production eligibility checks are priced per transaction. Checks with the new endpoint cost the same as checks with the legacy endpoint. For pricing, see our Pricing page.

For more details, see our announcement blog.

Introducing Stedi Lockbox

Providers can now receive payer paper checks, paper remits, and other mail items at a lockbox address managed by Stedi. A lockbox is a secure mailing address that receives mail on the provider's behalf. The provider can give the address to payers that require a mailing address for physical mail. Stedi deposits any checks received into a Stedi Treasury account automatically. Stedi scans the remits and other mail into PDFs you can view and download.

Checks become payment records in the Stedi portal. Paper remits and other mail become PDFs with OCR text that can be used for downstream processing.

Watch the 2026 Stedi Keynote announcement:

Automatic check deposits

Electronic Funds Transfers (EFTs) are the standard option for payer payments, but payers don't always pay electronically. Many still mail paper checks, and many mail paper remits – explanations of payment (EOPs) or explanations of benefits (EOBs) – instead of Electronic Remittance Advice (ERAs).

All that paper turns into manual work for the provider. Someone has to open the envelopes, match each check to its remit, and deposit the checks by hand.

Stedi Lockbox takes that work off the provider. Stedi receives the mail, scans it, and deposits any check into the associated Stedi Treasury account.

These check deposits appear in the Stedi portal the same way EFTs do, with one addition – a Mail card showing that the payment arrived as a paper check.

The related payment's detail page includes a scanned image of the check.

Paper remits and other mail

When a lockbox receives a paper remit, such as an EOP or EOB, Stedi makes it available in the related Stedi account as a PDF. Each PDF includes optical character recognition (OCR) text, so you can process the contents downstream.

The same applies to every other item of mail. You get the PDF, the OCR text, and the sender, then decide what to do next.

Availability and pricing

Stedi Lockbox is in private preview for Stedi production accounts. Reach out if you're interested in joining the preview.

For more details, see our announcement blog.