Submit claims through SFTP

You can use Stedi’s fully-managed SFTP server to submit claims to payers and retrieve claim responses without calling Stedi’s APIs.

You must submit claims 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 Clearinghouse without completing an API integration.

​

How SFTP connections work

Use the following process to submit claims to Stedi Clearinghouse:

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 - 277 Claim Acknowledgments and 835 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’s 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.

​

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 claims

You must drop claims 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 field.

Claims must adhere to the following X12 HIPAA claim specifications:

• Health Care Claim: Professional (X222A1)
• Health Care Claim: Institutional (X223A2)
• Health Care Claim: Dental (X224A2)

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.

​

EDI envelope

You must use specific values in certain ISA, GS, and ST header elements to ensure that Stedi can process your claims 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.

​

Set up webhooks (recommended)

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.

​

Claim Acknowledgment (277CA)

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 277 is the result of Stedi’s internal claim validation and may contain rejection message(s) and warnings, if applicable.
• You may receive a second 277CA from Stedi around the same time. This 277CA can contain additional information from the payer, but is often identical to the first one. You can think of this as an initial validation 277 from the payer.
• You’ll receive a final 277CA from the payer containing summary counts of transactions received and accepted as well as detailed information for rejected transactions, including payer-specific validations and HIPAA validations. This 277 has the payer’s name in the transactions.payers.organizationName property (Loop 2100A NM103 in the original X12 EDI).

​

Electronic Remittance Advice (835 ERA)

The 835 ERA, also known as a claim payment, contains details about payments for specific services and explanations for any adjustments or denials.

​

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 response, this number is returned as Loop 2200D TRN02 (Patient Control Number).
• In the 835 response, 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 response, this number is sometimes returned as Loop 2220D REF02 (Line Item Control Number). This is because a 277CA only contains a Service Line Information Loop if it was rejected because of issues with the information provided for the service line.
• In the 835 response, this number is returned as Loop 2110 REF02 (Line Item Control Number).