Submit claims through SFTP

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 SFTP setup 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.

Coordination of benefits check

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 SFTP setup 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:

• 837 Claim: Professional (X222A1)
• 837 Claim: Institutional (X223A2)
• 837 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.

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. If you don't already have payer IDs you use today, we recommend using the primary Payer ID.

Group Control Number

Each claim should have a unique value in GS06 (Group Control Number), so you can correlate 999 Implementation Acknowledgments with the original claim submission.

Stedi returns an error 999 when it rejects a claim due to X12 EDI validation errors. Without a unique GS06, you won't be able to determine which claim was rejected.

Patient Control Number

We recommend including a unique value in CLM01 (Patient Control Number) for each claim. This value is returned in both the 277 Claim Acknowledgment and 835 ERA responses, so you can use it to correlate responses with the original claim.

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.

Envelope and header

You can submit transactions with any values in the ISA and GS envelope, as long as they conform to the X12 EDI specification.

However, you must set ST03 to the appropriate value for the transaction type:

• 837P professional claims: 005010X222A1
• 837I institutional claims: 005010X223A2
• 837D dental claims: 005010X224A2
• 275 claim attachments: 005010X210

If your system requires you to send unique values in the ISA and GS envelope, you can find suggested configurations for each transaction type on the SFTP setup page under ISA settings.

Send claims and attachments

You can drop claim and attachment files 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.

Monitor for 999 rejections (strongly recommended)

Stedi returns a 999 Implementation Acknowledgment within minutes after each file submission to indicate whether Stedi accepted or rejected the included transaction(s) for processing.

We strongly recommend monitoring for error 999s that indicate rejections. Otherwise, your claim and attachment submissions may silently fail because Stedi doesn't send rejected transactions to the payer.

A 999 doesn't indicate whether the payer accepted or rejected your claim. For that information, check the 277CA claim acknowledgment response from the payer.

Interpret 999s

Check AK901 (Functional Group Acknowledge Code). The 999 will contain one AK901 element for each functional group in the file.

• Receipt acknowledgment 999: AK901 is set to A for Accepted. Stedi accepted all transactions in the functional group for processing and sent them to the payer.
• Error 999: AK901 is set to either R for Rejected or P for Partially Accepted. Stedi rejected at least one transaction in the functional group due to X12 EDI validation errors. For each transaction, the 999 will include Loop 2000 (Transaction Set Response Header). Within that loop, check IK501 (Transaction Set Acknowledgment Code).
  • Accepted transactions have IK501 set to A. Stedi sends accepted transactions to the payer, so you only need to correct and resubmit the rejected ones.
  • Rejected transactions have IK501 set to R. For rejected transactions, Stedi lists the validation errors in Loop 2100 (Error Identification). You must correct the errors and resubmit.

Correlate 999s with claim

Use AK102 (Group Control Number) to correlate the 999 with the original claim. It contains the same value you supplied in the claim's GS06 (Group Control Number). For this reason, you should always use a unique value in GS06 for each claim.

Set up webhooks

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

You can set up webhooks for these events to get real-time notifications when Stedi processes your claims and claim responses.

Retrieve claim responses

You can retrieve claim responses at your preferred cadence from the from-stedi directory. These responses are in X12 EDI format.

• You'll first receive a 999 Implementation Acknowledgment from Stedi indicating whether your submission was accepted or rejected. We strongly recommend monitoring 999s for rejections.
• Once Stedi accepts your claim, you may receive 277 Claim Acknowledgment and 835 Health Care Claim Payment/Advice (ERA) responses.

X12 EDI specifications: 999 | 277 | 835

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.

277CA vs. claim status check

The 277CA contains different information than a real-time claim status check. Specifically:

• 277CAs: Tell you whether the payer has received a claim and accepted it for processing. If the claim was rejected, 277CAs tell you why so you can resubmit. 277CAs don't indicate whether the claim has been adjudicated or paid.
• Real-time claim status checks: Tell you the status of a claim that's already been accepted into the payer's system. They provide information about whether the claim has been adjudicated, paid, denied, or is pending further review.

If you're waiting for an ERA, you should first check the related 277CA to confirm that the claim was accepted for processing. If the claim was rejected, you won't receive an ERA because the payer didn't adjudicate the claim.

Then, you can run a real-time claim status check to get updates about the claim's adjudication and payment status.

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.

Duplicate ERAs

Payers typically only send one ERA per claim. However, they may occasionally retransmit another identical 835 ERA, so you should have logic in place to handle these duplicates.

You can assume an ERA is a duplicate if the Check or EFT Trace Number is the same. This is the transactions[].paymentAndRemitReassociationDetails.checkOrEFTTraceNumber property in a processed 835 ERA from Stedi. In X12 EDI, this is available in segment TRN (Reassociation Trace Number), element TRN02 (Check or EFT Trace Number).

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