Changelog

Claim edit: A sequela code can’t be the primary ICD-10-CM diagnosis code

Stedi now rejects 837P professional and 837I institutional claims that list a sequela code as the only or primary ICD-10-CM diagnosis code.

ICD-10-CM diagnosis codes

In healthcare claims, diagnosis codes describe what’s wrong with the patient. HIPAA requires that professional and institutional claims only use valid, billable ICD-10-CM codes as diagnosis codes. For example, M54.50 is the ICD-10-CM code for “Low back pain, unspecified.”

A claim can include multiple diagnosis codes, listed in order of importance. The primary diagnosis code is in position 1, the next is in position 2, and so on.

Sequela codes

A sequela code is an ICD-10-CM diagnosis code used to describe a condition that remains after an earlier injury or illness has healed.

For example, M48.40XS (Fatigue fracture of vertebra, site unspecified, sequela of fracture) is a sequela code. Sequela codes always have S as the seventh character.

How the edit works

ICD-10-CM guidelines disallow a sequela code from being used as the primary or only diagnosis on professional or institutional claims. If it is, the payer may reject the claim, which can delay payment for the provider.

This edit – the industry term for an automated validation rule – catches the issue before the claim reaches the payer.

A sequela code can still be billed, as it provides additional context for the payer on why the patient has the current conditions. But those current conditions must be billed as the primary diagnosis, which describes the primary reason for service.

Rejection errors

If you submit a claim that fails the edit using Stedi’s JSON or X12 Claim Submission API endpoints, you’ll get back an error response in real time. The response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid use of Sequela Diagnosis code. The submitted diagnosis code, M48.40XS, is a sequela diagnosis (7th character \"S\") and cannot be used as the primary or only diagnosis on a claim. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>255*[DATE]*U*[AMOUNT]********Invalid use of Sequela Diagnosis code. The submitted diagnosis code, M4840XS, is a sequela diagnosis (7th character \"S\") and cannot be used as the primary or only diagnosis on a claim. Correct and resubmit.~

Resolution tip

In most cases, you can pass this edit by reordering the diagnosis codes so the current condition comes first and the sequela code(s) are listed afterward.

For example, M54.50 (Low back pain, unspecified) should be listed before the sequela, M48.40XS (Fatigue fracture of vertebra, site unspecified, sequela of fracture). Sequela codes should always accompany a preceding diagnosis code.

Claim edit: Missing billing provider tax ID

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that don't contain a tax ID for the billing provider.

Billing provider tax IDs

The billing provider is the person or organization, like a clinic or group practice, that will receive payment (if any) for the claim from the payer.

X12 standards require a tax ID for the billing provider on every professional, dental, and institutional claim. The tax ID is either an Employer Identification Number (EIN) or, for an individual provider, a Social Security Number (SSN).

Billing provider tax ID

Claim typeJSON API fieldX12 element
837P professionalbilling.employerId or billing.ssnREF02 of Loop 2010AA (Billing Provider Name), where REF01 = "EI" (Employer's Identification Number) or "SY" (Social Security Number)
837D dentalbilling.employerId or billing.ssnREF02 of Loop 2010AA (Billing Provider Name), where REF01 = "EI" (Employer's Identification Number) or "SY" (Social Security Number)
837I institutionalbilling.employerIdREF02 of Loop 2010AA (Billing Provider Name), where REF01 = "EI" (Employer's Identification Number)

How the edit works

If you submit a claim without a tax ID for the billing provider, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array.

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Billing Provider Tax Identification Number (TIN). The Tax Identification is a required identifier for the billing provider. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message.

STC*A6>128*[DATE]*U*[AMOUNT]********Missing Billing Provider Tax Identification Number (TIN). The Tax Identification is a required identifier for the billing provider. Correct and resubmit.~

Related claim edits

Stedi has another edit for claims where the billing provider is missing an identifier other than the tax ID. See Claim edit: Missing billing provider identifier.

New claim edits: Invalid subscriber individual relationship codes

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain an invalid individual relationship code for the subscriber.

Individual relationship codes

In a healthcare claim, the subscriber is the person who holds the insurance policy. The subscriber is also called the policyholder or primary cardholder.

The subscriber is not always the patient. For example, a dependent, such as a spouse or child, may receive care through an employee’s insurance. In that case, the employee is the subscriber, even though they’re not receiving care.

Claims indicate the relationship between the subscriber and the patient using an individual relationship code in the subscriber’s section. This code tells the payer whether the patient is the subscriber themselves or a dependent covered under the same plan.

How the edits work

In a claim, if the subscriber’s individual relationship code is 18 (Self), it means the subscriber is the patient. In these cases, the claim must not include information for a dependent. Similarly, if a claim does not include a dependent’s information, the subscriber’s individual relationship code must be 18.

If a claim mixes the subscriber’s individual relationship code and dependent information incorrectly, payers may reject the claim. This can delay payment for the provider.

This edit – the industry term for an automated validation rule – catches the issue before the claim reaches the payer.

Where to find the subscriber’s individual relationship code

The subscriber’s individual relationship code must not be 18

If you submit a claim with a dependent’s information and the subscriber’s individual relationship code is set to 18, Stedi’s JSON or X12 Claim Submission API endpoints return an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Subscriber Individual Relationship Code. Subscriber's individual relationship code cannot be '18' (Self) when subscriber is not the patient (as indicated by the dependent loop). Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7:N156*[DATE]*IL*[AMOUNT]********Invalid Subscriber Individual Relationship Code. Subscriber's individual relationship code cannot be '18' (Self) when subscriber is not the patient (as indicated by the dependent loop). Correct and resubmit.~

The subscriber’s individual relationship code must be 18

If you submit a claim without a dependent’s information and the subscriber’s individual relationship code is missing or not set to 18, Stedi’s JSON or X12 Claim Submission API endpoints return an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Subscriber Individual Relationship Code. Subscriber's individual relationship code must be '18' (Self) when subscriber is the patient (as indicated by the absence of dependent information). Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, 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>156*[DATE]*IL*[AMOUNT]********Missing Subscriber Individual Relationship Code. Subscriber's individual relationship code must be '18' (Self) when subscriber is the patient (as indicated by the absence of dependent information). Correct and resubmit.~

Request to join existing accounts

Now, when you sign up for Stedi, we check if your email domain is already tied to an existing account. If it is, you can request to join that account instead of creating a new one.

For example, if you sign up with john.doe@example.com and your company already has a Stedi account for example.com, you’ll see the option to request to join it. This helps avoid duplicate Stedi accounts for the same organization.

Account already exists

Transaction Enrollment API responses now include the originally submitted payer ID

We now return payer.submittedPayerIdOrAlias as an optional field in responses for the following Transaction Enrollment API endpoints:

For example, in a Retrieve Enrollment response:

{
  "payer": {
    "name": "UnitedHealthcare",       // Resolved name for the payer
    "stediPayerId": "87726",          // Resolved Stedi payer ID for the payer
    "submittedPayerIdOrAlias": "UHC", // Originally submitted payer ID
  },
  ...
}

You must pass a payer idOrAlias when creating an enrollment using the Create Enrollment endpoint. Previously, responses only returned the stediPayerId, the Stedi payer ID that the submitted payer ID or payer ID alias resolved to.

If you submitted a primary payer ID or another payer ID alias, this made it difficult to reconcile the response with the payer ID you originally provided.

Now, submittedPayerIdOrAlias returns the payer ID or payer ID alias you submitted in the original Create Enrollment request.

Introducing eligibility check IDs

Note

This entry refers to the Legacy Real-Time Eligibility Check JSON endpoint. We now have a redesigned version of that endpoint.

We strongly recommend the redesigned endpoint for new implementations. Its request and response shapes are more intuitive for both developers and AI agents, which speeds up integration. We still fix bugs in the legacy endpoint, but it's no longer under active development.

Stedi now generates and returns a universally unique ID (UUID) for every eligibility check.

The check ID is returned in the id field of the following API responses:

The check ID is a string that always starts with ec_. For example:

{
  "id": "ec_550e8400-e29b-41d4-a716-446655440000", // Unique check ID, generated by Stedi
  "eligibilitySearchId": "01922a35-a177-7171-b868-cd4974dd54df",
  "benefitsInformation": [
    ...
  ],
  ...
}

For SOAP Real-Time Eligibility Check API responses, the check ID is returned in the stedi-id HTTP response header:

stedi-id: ec_550e8400-e29b-41d4-a716-446655440000

The check ID gives you a stable handle for a single eligibility check. You can use it to:

For more information, check out our announcement blog.

Claim edit: Invalid diagnosis pointers

Stedi now rejects 837P professional and 837D dental claims with invalid diagnosis pointers.

How the edit works

In a claim, a diagnosis code describes what’s wrong with the patient, such as tooth decay or lower back pain. A claim can include multiple diagnosis codes, listed and indexed in order of importance. The primary diagnosis code is in position 1, the next is in position 2, and so on.

A service line is a single row on a claim that bills for one specific service, procedure, or supply – such as an office visit or a dental filling.

Each service line can include a diagnosis code pointer. This pointer tells the payer why the service was provided by linking it to a specific diagnosis code. For example, this office visit (service) was provided because of lower back pain (diagnosis). Payers use this information to determine the medical necessity or clinical rationale for the service.

The diagnosis code pointer refers to the index position of a diagnosis code on the claim. For example:

  • If a service line uses diagnosis pointer 2, the claim must include a diagnosis code in position 2.

  • If a service line uses diagnosis pointer 3, the claim must include a diagnosis code in position 3.

Payers may reject claims that include a diagnosis pointer that refers to a diagnosis code position that isn’t present on the claim. These rejections can delay payment for the provider.

This edit – the industry term for an automated validation rule – catches the issue before the claim reaches the payer.

Where to find diagnosis codes and pointers

Rejection errors

If you submit a claim that fails the edit using Stedi’s claim submission APIs, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The Diagnosis Pointer(s) of 2, 3, 4 on line 0 is/are invalid. The diagnosis pointer must point to an existing diagnosis code on the claim. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>477*[DATE]*U*[AMOUNT]********The Diagnosis Pointer(s) of 2, 3, 4 on line 0 is/are invalid. The diagnosis pointer must point to an existing diagnosis code on the claim. Correct and resubmit.~

Claim edit: Line item control numbers must be unique

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain duplicate line item control numbers.

How the edit works

In a claim, a service line represents billing for one specific service, procedure, or supply – for example, an office visit or a dental filling. Each service line represents a separate billable event.

A line item control number is a provider-assigned identifier for a specific service line.

Within a claim, each service line must have a unique line item control number. Payers and providers use line item control numbers to track service lines across claim submissions, claim acknowledgments, and Electronic Remittance Advice (ERAs).

Payers may reject claims with duplicate line item control numbers, which can cause payment delays.

This edit – the industry’s term for an automated validation rule – catches the issue before it reaches the payer.

Where to find line item control numbers

Rejection errors

If you submit a claim that fails the edit using Stedi’s claim submission APIs, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Line-Item Control Numbers. Each line-item control number must be unique within the claim. Control numbers, 12345, 67890, have been used more than once. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>584*[DATE]*U*[AMOUNT]********Invalid Line-Item Control Numbers. Each line-item control number must be unique within the claim. Control numbers, 12345, 67890, have been used more than once. Correct and resubmit.~

Include submitter's fax number using Stedi’s CMS-1500 form

You can now include the submitter’s fax number when submitting an 837P professional claim using Stedi’s CMS-1500 form.

The submitter is the person or organization who creates and submits the claim. When submitting a claim, you must include at least one of the following for the submitter:

  • Email address

  • Phone number

  • Fax number

Payers may use this information to contact the submitter about issues with the claim. Previously, the form only accepted the submitter’s email address and/or phone number.

Introducing status filters for batch eligibility checks in the Stedi portal

You can now filter eligibility checks within a batch by status in the Stedi portal.

Batch eligibility checks let you run multiple eligibility checks asynchronously using a single request. The checks run in a dedicated pipeline, separate from real-time checks, and Stedi handles retries for you.

You can submit batch eligibility checks through our API or by uploading a bulk CSV in the Stedi portal.

The portal’s Eligibility check batches page shows all your batch checks.

Eligibility check batches page

You can click a batch name to view its details, including the status – such as Started or Pending – of each check.

Batch details

With this change, you can now filter the list based on its status.

Filter by Status

Claim edit: The MJ unit of measurement code is only valid for anesthesia services

Stedi now rejects 837P professional claims when the MJ (minutes) unit of measurement code is used to incorrectly bill for anesthesia or non-anesthesia services.

In professional claims, the MJ unit of measurement code indicates a service was billed in minutes. While not a HIPAA mandate, it’s standard practice in the healthcare industry to bill for anesthesia services - but no other services – using MJ. Other services are billed using units, encounters, or time-based units – such as 15-minute increments – not raw minutes.

If MJ is used incorrectly, payers may reject the claim, which can lead to payment delays. This edit – the industry’s term for an automated validation rule – catches the issue before it reaches the payer.

When MJ must be used

If you submit a professional claim for anesthesia services that doesn't include the MJ unit of measurement code using Stedi’s 837P professional claim submission APIs or CMS-1500 professional claim form, you’ll get back an error message in real time. If you’re using the JSON API endpoint, the response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Measurement Code for Anesthesia Procedure Code. 01001 is an Anesthesia service which must be reported in minutes (measurement code: MJ). Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails this requirement using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message:

STC*A7:N659*[DATE]*U*[AMOUNT]********Invalid Measurement Code for Anesthesia Procedure Code. 01001 is an Anesthesia service which must be reported in minutes (measurement code: MJ). Correct and resubmit.~

When MJ must not be used

If you submit a professional claim for non-anesthesia services that includes the MJ unit of measurement code using Stedi’s 837P professional claim submission APIs or CMS-1500 professional claim form, you’ll get back an error message in real time. If you’re using the JSON API endpoint, the response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Measurement Code for Procedure Code. Measurement Code MJ is not valid for 90837 as it should be only used code for Anesthesia services. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails this requirement using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message:

STC*A7>659*[DATE]*U*[AMOUNT]********Invalid Measurement Code for Procedure Code. Measurement Code MJ is not valid for 90837 as it should be only used code for Anesthesia services. Correct and resubmit.~

Introducing operating states for payers

You can now see which U.S. states and territories a payer operates in using the Stedi Payer Network website and the Payers API.

Stedi payer records now list the states or territories where the payer is known or expected to offer coverage, based on Stedi’s curated sources. If Stedi doesn’t know the payer’s operating states, they aren’t included in the record.

You can also filter by operating states when searching for payers.

Filter by operating state in the Stedi Payer Network

When you browse or search payers on the Payer Network, click + Operating States beside Filter by and select one or more states. The results will use AND logic to only show payers that operate in those states.

Each payer now lists its Operating States in the Payer pane. National payers – those who cover all U.S. states display NATIONAL. Regional payers list one or more U.S. state or territory codes, such as CA (California) or WA (Washington).

Operating States in the Payer pane

Operating states are also listed on the Payer page:

Operating States on the Payer page

Operating states in the Payers API

All Payers API endpoints also now return an operatingStates array, if available, for payer records:

{
  "displayName": "Providence Health Plan",
  "primaryPayerId": "PHP01",
  "operatingStates": [
    "CA",
    "OR",
    "WA"
  ],
  ...
}

Payers that cover all U.S. states contain a single  NATIONAL value in the array:

{
  "displayName": "Cigna",
  "primaryPayerId": "62308",
  "operatingStates": [
    "NATIONAL"
  ],
  ...
}

Filter by operating state using the Payers API

You can also filter payers by operating state using the Search Payers endpoint’s new operatingStates query parameter.

The parameter expects exact matches and can accept multiple values. The endpoint uses AND logic to return the intersection of all filters.

For example, the following query returns only payers that operate in both CA (California) and WA (Washington):

curl --request GET \
  --url "https://healthcare.us.stedi.com/2024-04-01/payers?operatingStates=CA&operatingStates=WA" \
  --header "Authorization: <api_key>"

Claim edit: Limit line item control number to 30 characters

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims when a line item control number exceeds 30 characters.

The line item control number, also called the provider control number, is a provider-assigned identifier for each service line. Payers return this number on service lines in 277CA claim acknowledgments and 835 Electronic Remittance Advice (ERAs). Providers use it to track service lines across claim submissions, acknowledgments, and remittance files.

Line item control numbers are different from patient control numbers, which are used to track a claim as a whole.

HIPAA-adopted standards limit this line item control numbers to a maximum of 30 characters. If the value is too long, the payer may reject the claim, which can cause payment delays.

This edit – the industry’s term for an automated validation rule – catches the issue before it reaches the payer.

When this edit applies

A claim will fail this edit when:

Rejection errors

If you submit a claim that fails the edit using Stedi’s claim submission APIs, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Submitted Line Item Control Number, {123456789012345678901234567890123}, is invalid as it exceeds 30 characters. This field must be between 1-30 characters. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Horizon Blue Cross Blue Shield of New Jersey is now one-click enrollment

Horizon Blue Cross Blue Shield of New Jersey (Payer ID: 22099) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

What is transaction enrollment?
Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollments for ERAs.

You can submit and track enrollments using Stedi's transaction enrollment API, the Stedi portal, or a bulk CSV.

One-click enrollment
Enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

If a payer supports one-click enrollment, you only need to submit the enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer requires enrollment – and supports one-click enrollment – for ERAs and other transaction types using the Stedi Payer Network or the Payer APIs.

For details, see our transaction enrollment docs.

Introducing the ERA PDF API endpoint

You can now programmatically retrieve PDF versions of your 835 Electronic Remittance Advice (ERAs) using Stedi’s new ERA PDF API endpoint. The {transactionId} path parameter is the ERA's transaction ID.

By default, the endpoint returns the PDF as a base64-encoded string. To get the unencoded PDF data, include the Accept: application/pdf request header. To view the PDF, save the PDF data to a file with a .pdf extension.

curl -X GET \
  "https://healthcare.us.stedi.com/2024-04-01/electronic-remittance-advice/{transactionId}/pdf" \
  -H "Authorization: <api_key>" \
  -H "Accept: application/pdf" \
  > era.pdf

The PDFs are the same as the ones you can download from the Stedi portal:

For more, check out our announcement blog or the API reference.

Introducing enrollment document uploads

You can now upload documents required for transaction enrollment requests directly in the Stedi portal. Only PDF documents are supported.

What is transaction enrollment?

Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer.

For 835 Electronic Remittance Advice (ERAs), enrollment is always required. A payer only sends ERAs to the clearinghouse the provider has enrolled with, and a provider can only enroll with the payer through one clearinghouse at a time.

Stedi offers fully-managed, API-based transaction enrollment. You can use Stedi’s enrollment API to programmatically submit and track enrollments for providers. You can also use the Stedi portal, which supports bulk CSV imports.

When possible, we handle all enrollment paperwork on your behalf. When we can’t, we let you know what’s needed next.

Upload required enrollment documents

Enrollment requirements vary by payer. Some payers require additional documents, such as:

  • A signed form

  • A practice W-9

  • A voided check

Previously, Stedi emailed you to request these documents and asked you to email them back to us.

With this update, we’ll still email you when an enrollment requires action. But, now, you can upload completed documents by clicking Upload new document in the Documents section of the enrollment’s details page in the Stedi portal.

For more information, see our documentation.

Get payer website URLs in the Stedi Payer Network and Payers API

You can now get a payer’s website URL using the Stedi Payer Network and the Payers API.

Stedi payer records now list the payer’s website URL, when provided.

View payer URLs in the Stedi Payer Network
Each payer now includes a Visit payer website link, when available in the payer’s record, in the Payer pane:

The Payer page also includes the link:

Retrieve payer URLs using the Payers API
All Payers API endpoints also now return the urls.website response property, if available, for payer records.

{
  "displayName": "Blue Cross Blue Shield of Texas",
  "primaryPayerId": "84980",
  ...
  "urls": {
    "website": "https://www.bcbstx.com"
  }
}

Download ERA PDFs without a Stedi logo

You can now download unbranded ERA PDFs without a Stedi logo in the Stedi portal.

Stedi generates a PDF version of each Electronic Remittance Advice (ERA) you receive. Previously, all ERA PDFs included “Powered by Stedi” in the page footer. Now, you have the option to download ERA PDFs without this footer.

“Powered by Stedi” in the page footer

To download an unbranded ERA PDF:

  1. Go to the Transactions page.

  2. Click the ERA transaction you want to download.

  3. On the Overview tab, click Fetch artifact. Then click … and select Download 835 ERA PDF without Stedi logo.