Check claim status
You may need to check a claim's status when you don't receive a 277CA claim acknowledgment or 835 Electronic Remittance Advice (ERA) from the payer within your expected timeframe.
You can run real-time claim status checks to determine whether a payer is still processing a claim or if it's been rejected or denied.
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.
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.
You can check whether a specific payer requires transaction enrollment for real-time claim status checks in the Payer Network.
To enroll:
- Go to the Providers page and create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step.
- Go to the Enrollments page and submit an enrollment request for real-time claim status.
For most payers that require enrollment for claim status checks, enrolling through Stedi won't impact your ability to send transactions to your original clearinghouse. For any questions on payer nuances, contact Stedi's support team.
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.
Run a claim status check
To submit a 276/277 real-time claim status check:
- Go to the Create claim status check page.
- Enter the required information.
- Start with our recommended base request.
- We also strongly recommend reviewing our best practices. Supplying too much information or a too narrow/broad date of services range can negatively affect the results.
- Click Submit.
Stedi displays the claim status response on the next page. If the payer finds a matching claim, the response includes the claim's status and (if applicable) one or more rejection messages indicating the reason(s) for rejection. When the claim status check returns more than one matching claim, you can toggle between them using the dropdown at the top left of the page.
The claim status response also includes information about the attached claim, including key identifiers (such as the Patient Control Number), service details, billed amount, and paid amount (if applicable). However, it doesn't include all details from the original claim and any associated 835 Electronic Remittance Advice (ERAs). For example, if you need a detailed breakdown of payments and adjustments, you must check the related ERA.
Claim status checks aren't listed on the Transactions page. You can only review the response immediately after submitting the request. If you need to know the status of the same claim later, you must run a new claim status check.
Recommended base request
We recommend starting with the following fields in your claim status request.
| Form fields | Description |
|---|---|
| Trading partner service ID | You must specify the payer. Choose the payer from the dropdown. Start typing to filter the list. |
| Providers | The provider information from the original claim. To start, provide only the NPI, Organization name, and Provider type fields. |
| Subscriber | The subscriber information from the original claim. To start, provide only the First name, Last name, Date of birth, Gender, and Member ID fields. You'll need to click Select fields to add the Gender field to the form. |
| Dependent | The dependent information from the original claim. To start, provide only the First name, Last name, Date of birth, and Gender fields. You'll need to click Select fields to add the Dependent fields to the form. If the patient is the subscriber, don't include this information. |
| Encounter | The encounter information from the original claim. To start, provide only the Beginning date of service and End date of service fields. 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. |
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.
No matches - Interpret status codes
When the payer can't find matching claims, they return codes that can help you diagnose the problem.
Claim Status Category Code
These codes qualify the type of Claim Status Code included in the response and can provide additional information about why the payer couldn't find a match. Visit the X12 documentation for a complete list: Claim Status Category Codes
Often, this will be a generic D0 (Data Search Unsuccessful) to indicate that the payer couldn't find any matching claims.
Claim Status Code
These codes identify the status of an entire claim or service line. It can be either a Health Care Claim Status Code or a National Council for Prescription Drug Programs (NCPDP) Reject/Payment Code, when the status is related to pharmacy claims.
When the payer can't find matching claims, this code is often just a generic 35 (Claim/Encounter Not Found). However, sometimes these codes can help explain why there are no matches. For example, 97 (Patient eligibility not found with entity) indicates that the payer couldn't find the patient in their system.
Example
The following combination of codes suggests that the payer couldn't find insurance coverage information for the patient details you entered. This can happen when the patient's demographic details are incorrect - for example, if their name is misspelled - or when the final claim was submitted to a different payer than the one the patient identified when receiving services.
- Status Category Code:
D0(Data Search Unsuccessful - The payer is unable to return status on the requested claim(s) based on the submitted search criteria) - Status Code:
97(Patient eligibility not found with entity)
Troubleshooting steps
If your claim status requests don't return matching claim information, we recommend trying the following troubleshooting steps in order, regardless of the error codes you receive.
Payers often send non-specific or even misleading error codes in claim status responses. While error codes sometimes provide insight into the issue, we recommend trying all of these common troubleshooting steps if you're not getting successful results. For example, Claim Status Category Codes like E1 (Response not possible - System Status) can indicate that the payer's systems are temporarily down, but some payers also send these codes when your request information was incorrect.
Step 1: Add additional fields
Regardless of the status codes in the response, we recommend immediately retrying with these fields added to the request one by one, in the following order. Through experience, we've found including this information reliably improves hit rates for a large number of payers:
-
Submitted amount: The total charge amount for the entire claim - the sum of all service lines.
To add: Click Select fields, go to the Encounter section, and check the box next to Submitted amount.
-
Payer Claim Control Number (PCCN): The unique identifier the payer assigns to claims in their adjudication system.
You can find the PCCN in 277CA claim acknowledgments from the payer once the claim has entered their adjudication system. Go to the claims view, click the claim to open its timeline, and click See more detail on the 277CA. The PCCN is listed under Payer claim control number if available.
To add: Click Select fields, go to the Encounter section, and check the box next to Trading partner claim number.
-
Tax ID: The billing provider's Tax Identification Number (TIN). Some payers need this identifier instead of the NPI to find the right claim.
To add: Click Select fields, go to the Providers section, and check the box next to Taxpayer Identification Number (TIN).
Step 2: Check for common errors
Many failed claim status requests are due to the following errors. Sometimes, the status codes can indicate the cause and help you focus your troubleshooting efforts. If not, we recommend checking all of the following:
Payer-specific requirements
Many payers document additional requirements beyond the X12 HIPAA specification. Check the payer's 276/277 companion guide, and look for information about:
-
Provider type: We recommend starting with only the billing provider's information in claim status checks. However, some payers may require information about the service provider(s) instead of or in addition to the billing provider. Check whether
Loop 2100C(Provider Name) is listed as required, optional, or disallowed and whether there are specific requirements about the type of provider.You can adjust this information in the Providers section.
-
Provider identifier: Some payers may require a different identifier than the NPI, such as the provider's tax ID. Check whether the payer has specific notes about what to use for
Loop 2100C NM109(Provider Identifier).You can adjust this information in the Providers section by clicking Select fields and checking the box next to Taxpayer Identification Number (TIN).
-
Member ID format: Some payers may require that you enter the subscriber's member ID with a specific prefix or digit count. Check whether the payer has specific notes about
Loop 2100D NM109(Subscriber Identifier).You can adjust this information in the Subscriber section by updating the Member ID field.
-
Demographics: Some payers require additional demographic information about the subscriber or dependent. Check whether the payer has specific notes about
Loop 2000D(Subscriber) orLoop 2000E(Dependent).You can adjust this information in the Subscriber or Dependent sections. Click Select fields to see all available demographic fields.
If you need help finding a payer's companion guide, contact Stedi support.
Date of service range
Some payers store service dates differently than what you submitted. Try expanding your date of service range to plus or minus 14 days from the original claim's service date.
You can adjust the date range in the Encounter section by updating the Beginning date of service and End date of service fields.
Billing provider NPI
The billing provider NPI must match the one submitted in the claim. If your group or practice uses a group NPI for billing, try resubmitting with that organizational NPI instead.
If the billing provider NPI fails, try substituting the rendering provider's NPI as the billing NPI. Some payers index claims by the rendering provider rather than the billing organization.
You can adjust the NPI in the Providers section.
Patient demographics
Administrative entities that handle claim submission sometimes discover changes to the patient's insurance information after services were rendered. For example, they may:
- discover a coordination of benefits (COB) scenario. As a result, they may submit the final claim to a different payer than the one originally listed as the patient's insurance provider.
- update the patient's name, member ID, or other identifying information. As a result, you may be making claim status requests with incorrect patient data.
Try running a real-time eligibility check with the patient's information. If the check is successful, it confirms that your patient data is correct.
If the payer returns AAA errors, you can often use them to identify issues with the patient's data. For example:
- An
AAAerror71(Patient Birth Date Does Not Match That for the Patient on the Database) indicates that the patient's birthdate may be the issue. - An
AAAerror73(Invalid/Missing Subscriber/Insured Name) may indicate that the patient's first or last name are spelled incorrectly. - An
AAAerror75(Subscriber/Insured Not Found) indicates that the payer couldn't find the patient in their system. This may indicate that the patient's name, member ID, or other demographics are incorrect or that they're insured with a different payer.
BCBS / BlueCard routing
For BCBS members, the claim may have been adjudicated by the member's home plan rather than the local plan where services were rendered. To identify the correct payer, run a real-time eligibility check with the patient's information.
Stedi enriches the eligibility response with information about the patient's home plan when the eligibility check includes the member's first name, last name, birthdate, and full member ID (including the 3-character BCBS alpha prefix).
This information appears in the Benefit column of the eligibility response benefits table as a Related entity. The Type will be "Party performing verification" and the Entity will contain the payer's name. Once you've identified the correct home plan, resubmit the claim status check using that payer instead.
Note that BCBS enrichment isn't supported when:
- The patient's member ID doesn't contain the 3-character alpha prefix.
- The patient has stand-alone vision and pharmacy cards issued through an intermediary model.
- The patient's plan is a stand-alone dental product.
- The patient is part of a Federal Employee Program (FEP). In this case, the patient has R before their member ID.
Provider credentialing
Some payers require the provider NPI to be credentialed or enrolled specifically for real-time claim status checks, separate from claim submission enrollment. If you receive codes indicating that the request was sent to the wrong payer but you're certain the payer you selected is correct, the provider may not be credentialed properly with the payer.
For example, the following combination of codes may indicate a credentialing issue:
- Claim Status Category Code
E0(Response not possible - error on submitted request data) - Claim Status Code
116(Claim submitted to incorrect payer.)
Try the same request with a different provider that you know is properly credentialed with that payer. If you get a different response, such as category code A4 with status code 35 (Claim/Encounter Not Found), the original provider is likely the issue.
Stedi handles transaction enrollment - the process of registering a provider to send and receive specific EDI transactions through Stedi with a payer. However, Stedi doesn't handle credentialing (validating a provider's qualifications) or payer enrollment (registering a credentialed provider with a payer's health plan). Providers must complete credentialing and payer enrollment directly with each payer or through a specialized service.
Step 3: Contact support
If you've tried all these steps and still receive errors for claim status checks with information you know is correct, contact Stedi support. We can help figure out the next steps.