Changelog

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

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.