Format and submit claims

After setting up SFTP and submitting test claims, you're ready to start submitting production 837 claims and unsolicited 275 claim attachments.

Before sending claims

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

Transaction enrollment

Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Some payers require enrollment before allowing providers to submit 837 claims through a new clearinghouse.

You can check whether a specific payer requires transaction enrollment for 837 claims in the Payer Network or through the Payers API.

To enroll, complete the following steps:

1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. Stedi portal | API endpoint
2. Submit an enrollment request for the claim type. Stedi portal | API endpoint

For most payers that require enrollment for claim submission, enrolling through Stedi won't impact your ability to send transactions to your original clearinghouse. Only a few payers require the 837 claim to be sent to the same clearinghouse as the 835 ERA enrollment. For any questions on payer nuances, contact Stedi's support team.

Best practices

• Leverage batch enrollments when onboarding new provider groups or many providers at a time.
• For ERAs, you can only be enrolled through one clearinghouse at a time per payer per provider. When your ERA enrollment is accepted through Stedi, you'll stop receiving ERAs through the previous clearinghouse. Every other transaction type accepts enrollment through more than one clearinghouse.

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.

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 and the SFTP user type.

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.

Required elements

You must populate all required claim information according to the X12 HIPAA specification. You can submit any valid values in the ISA and GS envelope with a few exceptions listed in the following table.

You must set the following elements to specific values:

Data	Location	Instructions
Interchange Usage Indicator	ISA15	Set to T for test claims or P for production claims. You must use a test SFTP user to submit test claims and a production SFTP user to submit production claims.
Group Control Number	GS06	Include a unique value for each claim so you can correlate error 999 Implementation Acknowledgments with the original claim submission. Without a unique GS06, you won't be able to determine which claim was rejected.
Implementation Guide Version Name	ST03	Set to the appropriate value for the claim type: • Professional: 005010X222A1 • Institutional: 005010X223A2 • Dental: 005010X224A2
Payer ID	Loop 2010BB NM109	Submit a payer identifier listed in the Payer Network so Stedi can route the claim to the correct payer. This identifier must be a payer ID or payer ID alias. You must include leading 0 characters - for example, use 00540 for SISCO, not 540.
Patient Control Number	CLM01	We recommend including a unique value for each claim. This value is returned in both the 277CA and 835 ERA responses, so you can use it to correlate responses with the original claim.

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.

The following example shows a professional claim in X12 EDI format. ISA15 is set to P, as this is a production claim.

ISA*00*          *00*          *ZZ*401576130024   *ZZ*STEDI          *260213*2039*^*00501*000000123*0*P*>~
GS*HC*574183004559*STEDI*20260213*203918*39*X*005010X222A1~
ST*837*0001*005010X222A1~
BHT*0019*00*01KHCBK84E40QQYJVXA5VVXG54*20260213*2038*CH~
NM1*41*2*Data Health Services*****46*123435~
PER*IC**TE*5552223333~
NM1*40*2*AETNA*****46*60054~
HL*1**20*1~
PRV*BI*PXC*2084P0800X~
NM1*85*2*Billing Provider Name*****XX*1999999984~
N3*123 Some St*Floor 1~
N4*A City*NY*123450000~
REF*EI*123456789~
PER*IC*Data Health Services*TE*5553334444~
HL*2*1*22*0~
SBR*P*18*3335555******CI~
NM1*IL*1*Doe*John****MI*123456789~
N3*123 Some St~
N4*Somewhere*VA*123450000~
DMG*D8*20000101*M~
NM1*PR*2*AETNA*****PI*60054~
CLM*123456789*109.2***02>B>1*Y*A*Y*Y~
HI*ABK>F1111~
NM1*77*2*Service Facility Name~
N3*1234 Other St~
N4*A City*NY*123450000~
LX*1~
SV1*HC>90837>95*109.2*UN*1***1~
DTP*472*D8*20240101~
REF*6R*111222333~
SE*29*0001~
GE*1*39~
IEA*1*000000123~

Claim identifier

Loop 2300 REF02 (Claim Identifier for Transmission Intermediaries) has different usage rules depending on your role:

• Providers: Don't include Loop 2300 REF02 when REF01 = D9 in your claim submission. It's reserved for clearinghouses and intermediaries. You can use Loop 2300 CLM01 (Patient Control Number) to correlate claims with responses instead.
• Clearinghouses and intermediaries: You can optionally include REF*D9 in your 837 submissions. Stedi always returns this value in Loop 2200D REF*D9 of 277CA claim acknowledgments, allowing you to match these responses to the claim.

Bulk claims

You can submit multiple claims in the same 837 transaction by including multiple instances of the following loops:

• Loop 2000A (Billing Provider)
• Loop 2000B (Subscriber)
• Loop 2300 (Claim Information)

After submission, Stedi separates your bulk 837 transaction into individual claims and sends each claim separately to the payer. This includes multiple claims going to the same payer - all claims within a bulk submission are sent individually to maintain consistency.

The following example would produce 12 separate claims (2 x 3 x 2 = 12):

• 837 transaction contains information for two billing providers (2x Loop 2000A)
• Each billing provider has three subscribers (3x Loop 2000B)
• Each subscriber has two claims (2x Loop 2300)

By default, Stedi returns one 999 Implementation Acknowledgment when one or more transactions in the bulk 837 fail validation. 999s for fully accepted bulk transactions are opt-in only - visit Monitor for 999 rejections for details.

Then, you'll typically receive separate 277CA claim acknowledgments for each claim. Note that Stedi sends accepted claims to the payer, even if other claims within the batch fail our validation. You should monitor for 277CA rejections and resubmit those claims accordingly.

Each claim will also receive its own test ERA from Stedi's test clearinghouse if the payer was STEDITEST. Visit Test claims workflow for details.

You'll be billed per claim submitted, not per bulk 837 transaction. For example, if you submit a bulk 837 transaction with 10 claims, you'll be billed for 10 claims.

275 claim attachments

You can submit unsolicited claim attachments through SFTP. Unsolicited attachments are sent proactively with the claim without a prior payer request. If a payer sends a Request for Additional Information (277 RFA), you cannot submit the requested attachments through Stedi.

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.

Claim attachments must adhere to the 275 Patient Information (X210) X12 HIPAA specification.

Required elements

You must set the following elements to specific values:

Data	Location	Instructions
Interchange Usage Indicator	ISA15	Set to T for test attachments or P for production attachments. You must use a test SFTP user to submit test attachments and a production SFTP user to submit production attachments.
Implementation Guide Version Name	ST03	Set to 005010X210 for all 275 claim attachments.
Payer ID	Loop 1000A NM109	Submit a payer identifier listed in the Payer Network so Stedi can route the attachment to the correct payer. This identifier must be a payer ID or payer ID alias. You must include leading 0 characters - for example, use 00540 for SISCO, not 540.
Attachment Control Number	Loop 2000A TRN02	This value must match the value you submitted in the claim's PWK06 element. This is how Stedi and the payer match the attachment with the claim.

The following example shows a 275 claim attachment in X12 EDI format. ISA15 is set to T, as this is a test attachment.

ISA*00*          *00*          *ZZ*STEDI          *ZZ*CIGNA          *250227*2140*^*00501*000000001*0*T*>~
GS*PI*STEDI*CIGNA*20250227*214016*1*X*005010X210~
ST*275*1001*005010X210~
BGN*11*0001*20060915~
NM1*PR*2*CIGNA*****XV*62308~
NM1*41*2*XYZ SERVICES*****46*1999999976~
NM1*1P*2*THE HOSPITAL*****XX*3999000B01~
NX1*1P~
N3*123 Main~
N4*Miami*FL*11111~
NM1*QC*1*DOE*JOHN*J***MI*987654320~
REF*EJ*DOE123~
REF*EA*AAAAA12345~
DTP*472*D8*20060812~
LX*1~
TRN*2*11122233344~
STC*R4>18626-2>>LOI~
DTP*368*D8*20060915~
CAT*AE*TX~
EFI*05~
BIN*8*U3RlZGk=~
SE*20*1001~
GE*1*1~
IEA*1*000000001~

Size limits

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.

Send claims and attachments

You can drop claim and attachment files into the to-stedi directory. Stedi automatically validates the data and then routes each transaction to the appropriate clearinghouse (test or production).

Stedi deletes files from the to-stedi directory after processing them to avoid duplicate submissions.

Monitor for 999 rejections (strongly recommended)

When claim or attachment transactions fail Stedi's validation, Stedi returns a 999 Implementation Acknowledgment within minutes of the file submission. The 999 indicates that at least one transaction in the file was rejected for processing; other transactions in the same file may still be accepted and sent to the payer.

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

By default, you'll only receive 999s when Stedi rejects one or more transactions in a functional group. You can opt in to receive 999s for fully accepted functional groups as well. To update your 999 settings in the Stedi portal:

1. Go to the SFTP setup page in your account settings.
2. Under 999 settings, select All 999s.

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.

Examples

AK901 (Functional Group Acknowledge Code) is set to R if all transactions were rejected, or P if the group was partially accepted:

AK9*P*3*3*1~    ← Partially accepted: 3 transactions submitted, 3 received, 1 accepted (2 rejected)

For each rejected transaction, IK501 (Transaction Set Acknowledgment Code) is set to R. The IK3 (Error Identification) and IK4 (Implementation Data Element Note) segments identify where the error occurred. For example:

AK2*837*0002~      ← Responding to transaction 0002
IK3*CLM*22**8~     ← CLM segment at position 22 has element errors
IK4*2*782*1~       ← Element 2 is missing a mandatory value
IK5*R*5~           ← Transaction rejected

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.