Check claim status

You may need to check the status of a claim when you don't receive a 277CA or 835 ERA response from the payer within your expected timeframe. You may also want to check the status of a claim submitted by another entity. For example, a billing agency may want to check the status of a claim submitted by their customer, who is a provider.

Testing

You can only run real-time claim status checks for production claims that have entered the payer's processing system.

Requests for test claims or claims the payer hasn't yet accepted for processing won't return results. That's why our claim status best practices recommend waiting at least a week after submission before attempting to check a claim's status. You also won't be able to check the status if Stedi or the payer rejected a claim with a 277CA claim acknowledgment.

You can find examples of claim status requests and responses in the sample requests and responses section on this page.

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 real-time claim status checks through a new clearinghouse. This enrollment process is separate from the transaction enrollment process for 837 claims.

Enrolling through Stedi may cancel existing real-time claim status enrollments you have through other clearinghouses. We can help you determine whether this applies to your specific payers. However, enrolling through Stedi for real-time claim status checks doesn't affect your existing enrollments for other transaction types. For example, enrolling with Stedi won't unenroll the provider from receiving transactions like Electronic Remittance Advices (ERAs) through other clearinghouses.

You can check whether a specific payer requires transaction enrollment for real-time claim status checks in the Payer Network or through the Payers API.

To enroll, complete the following steps:

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
Submit an enrollment request for real-time claim status. Stedi portal | API endpoint

Best practices

We recommend following these best practices when checking claim status.

Wait for the payer to receive the claim. You can check a claim's status once the payer has received and accepted it into their processing system - you don't need to wait until the claim is fully adjudicated. We recommend waiting at least 2-3 days after submitting the claim or until you receive a 277CA claim acknowledgment from the payer indicating they have received the claim.
Check periodically. If you haven't received an 835 ERA, we recommend checking the claim's status at 21 days after submission and then again at 1 month.
Supply a date of service range. We recommend the following when providing dates of service:
- The date range should be at least plus or minus 7 days from the date of the services listed in the claim. The payer may have stored a different date for the encounter than the one in your records, so providing a date range increases the likelihood that the payer will find a match.
- Keep the date range to 30 days or less. Some payers may reject requests with a date range that is too wide.
- Don't submit future dates - only submit date ranges up to and including today's date. Some payers reject requests containing future service dates.
Start with the recommended base request. Providing too much information in a claim status request can negatively affect the results. We recommend starting with only the minimum required information.

Manual submission

You can submit a claim status request manually through the Create claim status check form in Stedi.

The response view shows both claim-level and service-level details. If the claim status request returns information for multiple claims, you can use the dropdown to navigate between them.

API submission

Call one of the following endpoints to send a 276/277 real-time claim status:

Claim Status to send requests in JSON
Claim Status Raw X12 to send requests in X12 EDI

Both endpoints return a synchronous claim status response from the payer in JSON format. The response may contain information about more than one claim, if the payer has multiple claims on file that match the information you provided.

Headers

When constructing the request, you must include the following information in HTTP headers:

Authorization: Generate an API key to use for authentication.
Content-Type: Set to application/json.

Body - JSON

For best results, you should start with our recommended base request and add more information only as needed.

Note that objects marked as required are required for all requests, while others are conditionally required depending on the circumstances. When you include a conditionally required object, you must include all of its required properties.

For example, you must always include the subscriber object in requests, but you only need to include the serviceLinesInformation object when you want to request the status for a specific service line.

JSON base request

We recommend starting with the following properties in a request to the Real-Time Claim Status JSON endpoint:

Information	Description
`tradingPartnerServiceId`	This is the payer ID. Visit the Payer Network for a complete list. You can send requests using the primary payer ID, the Stedi payer ID, or any payer ID alias listed in the payer record.
`providers`	The billing provider information from the original claim. To start, provide only the `npi`, `organizationName`, and `providerType` properties.
`subscriber`	The subscriber information from the original claim. To start, provide only the `firstName`, `lastName`, `dateOfBirth`, `gender`, and `memberId` properties.
`dependent`	The dependent information from the original claim. To start, provide only the `firstName`, `lastName`, `dateOfBirth`, and `gender` properties. If the patient is the subscriber, you can omit this object.
`encounter`	The encounter information from the original claim. To start, provide only the `beginningDateOfService` and `endDateOfService` properties. Remember that you should provide a date range that is plus or minus 7 days from the date of service listed in the claim for best results. Only use date ranges that are up to and including today's date - some payers reject requests containing future service dates.

The following examples show two base request payloads: one where the patient is the subscriber and one where the patient is the dependent. They include only the minimum recommended information:

{
  "encounter": {
    "beginningDateOfService": "20240318",
    "endDateOfService": "20240402"
  },
  "providers": [
    {
      "npi": "1999999984",
      "organizationName": "Behavioral Services P.C.",
      "providerType": "BillingProvider"
    }
  ],
  "subscriber": {
    "firstName": "Jane",
    "lastName": "Doe",
    "dateOfBirth": "19000806",
    "gender": "F",
    "memberId": "111222333"
  },
  "tradingPartnerServiceId": "3429"
}

{
  "encounter": {
    "beginningDateOfService": "20240318",
    "endDateOfService": "20240402"
  },
  "providers": [
    {
      "npi": "1999999984",
      "organizationName": "Behavioral Services P.C.",
      "providerType": "BillingProvider"
    }
  ],
  "subscriber": {
    "firstName": "Jane",
    "lastName": "Doe",
    "dateOfBirth": "19000806",
    "gender": "F",
    "memberId": "111222333"
  },
  "dependent": {
    "firstName": "John",
    "lastName": "Doe",
    "dateOfBirth": "19100323",
    "gender": "M"
  },
  "tradingPartnerServiceId": "3429"
}

Body - X12 EDI

Your payload must conform to 276 X12 EDI format. For best results, you should start with our recommended base request and add more information only as needed.

Envelope and header

Stedi generates its own ISA and GS headers and IEA and GE trailers before sending your claim status request to the payer. You can submit your request to Stedi with any values in these segments, as long as they conform to the X12 EDI specification.

However, you must set ST03 (Version, Release, or Industry Identifier) to 005010X212.

X12 base request

We recommend starting with the following properties in a request to the Real-Time Claim Status Raw X12 endpoint:

Loop	Fields and Description
`Loop 2100A` (Payer Name)	You'll need to provide `NM1` (Payer Name). Specifically, `NM109` (Payer 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.
`Loop 2100B` (Information Receiver Name)	The information for the entity making the request. To start, provide only the following: `NM103` (Information Receiver Last or Organization Name) `NM108` (Identification Code Qualifier) `NM109` (Information Receiver Identification Number) - this is the Electronic Transmitter Identification Number (ETIN)
`Loop 2100C` (Provider Name)	The billing provider's information from the original claim. To start, provide only the following: `NM101` (Entity Identifier Code) `NM102` (Entity Type Qualifier) `NM103` (Provider Last Name or Organization Name) `NM108` (Identification Code Qualifier) set to `XX` for the NPI `NM109` (Provider Identifier) - the provider's NPI
`Loop 2000D` (Subscriber)	The subscriber information from the original claim. To start, provide the following: `HL` (Hierarchical Level) `DMG01` (Date Time Period Format Qualifier) `DMG02` (Subscriber Birth Date) `DMG03` (Subscriber Gender Code)
`Loop 2100D` (Subscriber Name)	The subscriber information from the original claim. To start, provide the following: `NM101` (Entity Identifier Code) `NM102` (Entity Type Qualifier) `NM103` (Subscriber Last Name) `NM104` (Subscriber First Name) `NM109` (Member Identification Number)
`Loop 2000E` (Dependent)	The dependent information from the original claim. If the patient is the subscriber, you can omit this loop. To start, provide only the following: `DMG02` (Dependent Birth Date) `DMG03` (Dependent Gender Code)
`Loop 2100E` (Dependent Name)	The dependent information from the original claim. If the patient is the subscriber, you can omit this loop. To start, provide only the following: `NM103` (Patient Last Name) `NM104` (Patient First Name)
`Loop 2200D` (Claim Status Tracking Number)	The encounter information from the original claim. To start, only provide the following: `TRN` (Claim Status Tracking Number) `DTP` (Claim Service Date): Provide a date range that is plus or minus 7 days from the date of service listed in the claim for best results. Only use date ranges that are up to and including today's date - some payers reject requests containing future service dates.

The following examples show two base request payloads: one where the patient is the subscriber and one where the patient is the dependent. They include only the minimum recommended information:

ISA*00*          *00*          *ZZ*SENDER         *ZZ*RECEIVER       *250916*2048*^*00501*000000001*0*T*>~
GS*HR*SENDERGS*RECEIVERGS*20260916*204811*1*X*005010X212~
ST*276*0001*005010X212~
BHT*0010*13*ABC45678*20260915*1425~
HL*1**20*1~
NM1*PR*2*PAYER NAME*****PI*87726~
HL*2*1*21*1~
NM1*41*2*REQUESTING PROVIDER NAME*****46*123456789~
HL*3*2*19*1~
NM1*1P*2*SERVICE PROVIDER NAME*****XX*1999999984~
HL*4*3*22*0~
DMG*D8*19000101*F~
NM1*IL*1*DOE*JANE****MI*MEMBERID123456~
TRN*1*123456789~
DTP*472*RD8*20260601-20260614~
SE*14*0001~
GE*1*1~
IEA*1*000000001~

ISA*00*          *00*          *ZZ*SENDER         *ZZ*RECEIVER       *250916*2048*^*00501*000000001*0*T*>~
GS*HR*SENDERGS*RECEIVERGS*20260916*204811*1*X*005010X212~
ST*276*0001*005010X212~
BHT*0010*13*ABC12345*20260915*1425~
HL*1**20*1~
NM1*PR*2*PAYER NAME*****PI*87726~
HL*2*1*21*1~
NM1*41*2*REQUESTING PROVIDER NAME*****46*123456789~
HL*3*2*19*1~
NM1*1P*2*SERVICE PROVIDER NAME*****XX*1999999984~
HL*4*3*22*0~
DMG*D8*19000101*F~
NM1*IL*1*DOE*JANE****MI*MEMBERID123456~
HL*5*4*23*0~
DMG*D8*20010104*M~
NM1*QC*1*DOE*JOHN~
TRN*1*123456789~
DTP*472*RD8*20260601-20260614~
SE*17*0001~
GE*1*1~
IEA*1*000000001~

Character restrictions

Only use the X12 Basic and Extended character sets in request data. Using characters outside these sets may cause errors.

In addition, the following characters are reserved for delimiters in the final X12 EDI transaction to the payer: ~, *, :, and ^. X12 doesn’t support using escape sequences to represent delimiters or special characters. Stedi returns a 400 error if you use these restricted characters improperly.

JSON endpoint: Don’t include delimiter characters anywhere in your request data.
Raw X12 endpoint: You can use these characters as delimiters, but not in the body of the request data.

Delimiter normalization

Stedi normalizes delimiters in both the JSON and raw X12 responses you receive to ensure consistency and prevent parsing issues. When the following delimiter characters appear within data values - meaning they are used as content - Stedi replaces them as shown:

Delimiter type	Original	Replaced with
Element separator	`*`	`\|`
Repetition separator	`^`	`\|`
Component element separator	`	`'`
Segment terminator	`~`	`\|`

Examples:

O*CONNOR becomes O|CONNOR
CODE^01 becomes CODE|01
O`CONNOR becomes O'CONNOR
MSG~HELLO becomes MSG|HELLO

If you parse raw X12 EDI responses, ensure your parser reads delimiters from the ISA segment instead of assuming fixed delimiters.

Timeout

Requests to payers typically time out at 1 minute, though Stedi can keep connections open longer than that if needed.

Concurrency limit

Our real-time claim status endpoints share a concurrency pool with other real-time healthcare APIs. For more information, visit Concurrency Limits.

Recommended API clients

You may want to use an API client to make testing and debugging easier.

We don't recommend using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds.

Visit API clients for a list of recommended clients you can use instead.

Sample requests and responses

The following examples show a 276 claim status request and 277 claim status response for Stedi's JSON endpoint.

Accepted claims

The following example shows a claim status request and response for a claim that has been accepted by the payer and is awaiting payment. The payer is UnitedHealthcare, and the request uses the payer ID alias 3429.

The following example shows a claim status request and response for a claim that has been processed and paid. The payer is UnitedHealthcare, and the request uses the primary payer ID 87726.

Note that this example response includes the payment amount and the service line item details. Some payers return this information in claim status responses, but most don't. You should typically plan to get these details from the 835 Electronic Remittance Advice (ERA) instead.

Denied claims

The following example shows a claim status request and response for a denied claim. The payer is Anthem Blue Cross Blue Shield of Virginia, and the request uses the primary payer ID 423.

In this example, the subscriber in the request is actually a dependent using the subscriber's member ID.

The following examples show a request and response for a denied claim. The payer is Aetna, and the request uses the primary payer ID 60054.

In this example, the claim is for a dependent.

No matches found

The following example shows a request and response for a claim status check that failed because the payer couldn't find a matching claim. The payer is Cigna, and the request uses the payer ID alias CIGNA.

Validation error (999)

The Real-Time Claim Status Raw X12 endpoint returns a 999 Implementation Acknowledgment when the request data fails validation. Common failure reasons are missing required segments and invalid values.

The following example request is missing required HL loops.

Limitations

Claim status requests are likely to fail in the following scenarios:

Claims submitted by other providers

You likely won't be able to check the status of a claim submitted by a different provider organization or by the patient themselves, even if you have all of the details about the claim.

Payers generally only allow a provider organization to check the status of the claims they submitted. They impose these access controls to protect plan member privacy and confidential commercial data.

Claims older than 18 months

Payers often archive claims older than 18 months, but this varies by payer. If you try to check the status of a claim from several years ago, the payer may return an error even if the information you submit matches a real historical claim.

Claims outside the payer's system

You can only check the status of claims the payer has received and accepted into their processing system. Claims that haven't entered the payer's system won't return results, even if you have all the correct information. This is why we recommend waiting at least a week after submission before running a claim status check.

You'll know the claim is in the payer's system when you receive a 277CA claim acknowledgment from the payer with acceptance codes. Some payers will never send a 277CA.

Troubleshooting

If you're not getting results from your claim status checks, visit Troubleshoot claim status checks for detailed troubleshooting steps.

Billing

Transactions are billable at the usage rates specified in your contract unless they fall into the following non-billable categories:

API calls that return 4xx or 5xx errors. For example, you won't be charged when a request fails because the payer isn't supported - in this case, Stedi returns a 400 HTTP status code.
Claim status responses that exclusively contain one or more of these non-billable Claim Status Codes in STC01-02 (Status Code): 484, 494, 667, or 689.

These codes appear in the claims[].claimStatus.statusCode and claims[].serviceDetails[].status[].statusCode properties of the JSON response.

Check claim status

Basic character set

Extended character set

Accepted, waiting for payment - Subscriber - UnitedHealthcare

Accepted, paid - Subscriber - UnitedHealthcare

Denied - Dependent - Anthem BCBS Virginia

Denied - Dependent - Aetna

No matches found - Subscriber - Cigna

Validation error (999)

On this page