You can use Stedi’s fully-managed SFTP server to submit claims - including 275 claim attachments - to payers and retrieve responses without calling Stedi APIs. You must submit claims and attachments in X12 EDI format, and Stedi returns claim responses through the SFTP connection in X12 EDI format. This makes Stedi SFTP a good option if you have an existing system that generates X12 EDI files and you want to send them through Stedi without completing an API integration.

​
How SFTP connections work

Use the following process to submit claims to Stedi:
  1. Create SFTP users through the Healthcare page in your account. You’ll use these credentials to connect to Stedi’s SFTP server.
  2. Connect to Stedi’s server and drop X12 EDI claim files into the to-stedi directory.
  3. Stedi automatically validates the claim data and uses the Interchange Usage Indicator field (T or P) to determine whether each file contains a test or a production claim. If there are no validation errors, Stedi routes your claims to the test or production clearinghouse accordingly.
  4. Stedi places claim responses - 277CA claim acknowledgments and 835 Electronic Remittance Advice (ERAs) - into the from-stedi directory in X12 EDI format. You can retrieve these responses from the directory at your preferred cadence without setting up webhooks or calling Stedi APIs.
Stedi shows all claims and claim responses sent through the SFTP connection on the Files and Transactions pages in the UI. This allows you to review your claim submissions, quickly find related responses, and download transaction data.

​
Before sending claims

You may need to complete the following steps before sending claims.

​
Transaction enrollment

All payers require providers to complete an enrollment process before they can start receiving 835 ERAs. Some payers also require enrollment before allowing providers to submit claims. The Stedi Payer Network lists which payers require transaction enrollment. Visit Transaction Enrollment for details about the transaction enrollment process. We recommend running a coordination of benefits (COB) check to ensure you submit claims to the correct payer. COB checks can help you determine:
  • If a patient is covered by more than one health plan
  • Whether coverage overlap requires coordination of benefits
  • Each payer’s responsibility for payment (primacy) in coordination of benefits scenarios
Visit Coordination of benefits (COB) checks for more information.

​
Create SFTP users

Go to the Healthcare page in your account settings to create SFTP users. You can create either test or production users.
  • Test users can only send claims with the Usage Indicator Code set to T (test). These claims are only sent to Stedi’s test clearinghouse and not to the payer. Note that you will receive a 277 Claim Acknowledgment for test claims, but you will not receive an 835 ERA.
  • Production users can only send claims with the Usage Indicator Code set to P (production). These claims are sent through Stedi’s production clearinghouse to the payer.

​
Connect to Stedi’s server

Use your user credentials to connect to Stedi’s SFTP server at transfer.us.stedi.com using Port 22.

​
Static IPs

You can use these static IP addresses to allowlist Stedi’s server: 18.119.51.218 and 18.206.132.233

​
Format X12 EDI files

You must drop claims and claim attachments into the to-stedi directory in X12 EDI format. Stedi validates the claims and routes them to the appropriate clearinghouse based on the ISA15 Interchange Usage Indicator element.

​
837 claims

Claims must adhere to the following X12 HIPAA claim specifications: We recommend submitting one claim per file to make troubleshooting easier. However, an EDI Interchange can contain multiple transactions, so you can submit multiple claims within a single file if needed. Regardless of how many claims you submit in a file, Stedi processes each claim individually and returns each claim response as a separate file.

​
Payer ID

You must submit a payer identifier in Loop 2010BB (Payer Name) NM109 so Stedi can route your claim to the correct payer. This identifier must be a payer ID or payer ID alias listed in the Payer Network. For example, you could use 60054, HPQRS, AETNA, or any other listed payer ID alias for Aetna.

​
275 claim attachments

Claim attachments must adhere to the 275 Patient Information X12 HIPAA specification. Before you can submit an attachment, you must first submit a claim that references the attachment(s) in the appropriate location. Visit Claim attachments for complete instructions. We recommend limiting attachments to 64MB each, but some payers may have different size requirements. When in doubt, check the payer’s documentation to determine their specific limits. This limit is per attachment file - you can submit multiple attachment files in each 275 transaction.

​
EDI envelope

You must use specific values in certain ISA, GS, and ST header elements to ensure that Stedi can process claims and claim attachments correctly. For example, you must use specific values for the sender and receiver IDs (ISA06 and ISA08). The required values differ depending on whether you are sending test or production claims. For example, the ISA08 value for test claims is STEDITEST, while the value for production claims is just STEDI. Stedi displays the exact header values you need to use for each use case on the Healthcare page in your account settings.
Your SFTP user type must match the claim type, as indicated by the value (T or P) in ISA15. If you try to send a test claim with production user credentials, Stedi returns an error. Likewise, if you try to send a production claim with test user credentials, Stedi returns an error.
Stedi emits events when it processes claims and claim responses.
  • File delivered: Emitted when Stedi successfully processes your claim and delivers it to our connection with the payer. Note that this event doesn’t indicate whether the payer received the claim or whether they have accepted or rejected it.
  • File failed: Emitted when Stedi cannot deliver the claim to the payer due to validation errors in the X12 EDI claim data. You must fix the errors and resubmit the claim.
  • Transaction processed: Emitted when Stedi successfully receives and processes a payer or intermediary clearinghouse response, such as an 835 ERA. These events are also emitted when Stedi successfully processes claims you submit through the SFTP connection.
We recommend setting up webhooks for at least file failed events so you can monitor for claim submission errors. Otherwise, your claim submissions may silently fail, and it will be much more difficult to troubleshoot issues.

​
Send claims and retrieve responses

You can drop claims into the to-stedi directory. Stedi automatically validates the claim data and then routes each claim to the appropriate clearinghouse (test or production). Stedi deletes files from the to-stedi directory after processing them to avoid duplicate claim submissions. After submitting a claim, you may receive 277 Claim Acknowledgment and the 835 Health Care Claim Payment/Advice (ERA) responses in X12 EDI format. You can retrieve these claim responses at your preferred cadence from the from-stedi directory.

​
277CA claim acknowledgment

The 277CA indicates whether the claim was accepted or rejected and (if relevant) the reasons for rejection. Though it can contain claim status information, the 277CA is different from the synchronous 277 claim status response you receive after submitting a real-time claim status request. You may receive multiple separate 277CAs for each claim you submit.
  • You’ll receive the first 277CA from Stedi within about 30 minutes of submitting the claim. This 277CA may contain rejection message(s) and warnings, if applicable.
  • You may receive additional 277CAs from intermediary clearinghouses.
  • You’ll receive one or more 277CAs from the payer. Typically, there is one 277CA that indicates receipt of the claim and a second 277CA that contains summary counts of transactions received, information about accepted transactions, and details for rejected transactions.
Each 277CA typically correlates to one 837 claim. However, some payers may send a single 277CA that references multiple claims.

​
Determine sender

You can determine whether a 277CA is from a clearinghouse or the payer from the transactions.payers array in the report. The organizationName property contains the name of the sender (for example, CIGNA) and the identityIdentifierCodeValue contains either Clearinghouse or Payer. This information is also available at the top of the 277CA’s transaction details page in the Stedi portal.

​
835 Electronic Remittance Advice (ERA)

The ERA contains details about payments for specific services and explanations for any adjustments or denials. The payer only sends ERAs for accepted claims. If a claim is rejected in a 277CA, there’s no adjudication or payment information to report.
Processing ERAs always requires transaction enrollment with the payer.

​
Correlate responses with claim

You can use the following identifiers from the original claim to correlate the 277CA and 835 ERA responses.

​
Entire claim

Use Loop 2300 CLM01 (Patient Control Number) from the original claim, if provided.
  • In the 277CA, this number is returned as Loop 2200D TRN02 (Patient Control Number).
Some payers batch acknowledgments for multiple claims into a single 277CA. This is more likely if you submitted multiple claims within a single 837 claim envelope. In these cases, the 277CA will contain multiple iterations of Loop 2200D (Claim Status Tracking Number). You can use each TRN02 (Patient Control Number) value in the 277CA to correlate it with the original claim.
  • In the 835 ERA, this number is returned as Loop 2100 CLP01 (Patient Control Number).

​
Specific service lines

Use Loop 2400 REF02 (Line Item Control Number) from the original claim, if provided. Location in responses:
  • In the 277CA, this number is sometimes returned as Loop 2220D REF02 (Line Item Control Number), but not always. This is because a 277CA only contains Loop 2220D (Service Line Information) when the claim was rejected because of issues with the information provided for the service line.
  • In the 835 ERA this number is returned as Loop 2110 REF02 (Line Item Control Number).