Troubleshoot claim status checks
This page explains how to troubleshoot claim status checks that don't return matching claim information.
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.
- JSON:
claims[].claimStatus.statusCategoryCode - X12 EDI:
Loop 2200D STC01-01(Health Care Claim Status Category Code)
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.
- JSON
claims[].claimStatus.statusCode - X12 EDI:
Loop 2200D STC01-02(Status Code)
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.
{
"claimStatus": {
"statusCategoryCode": "D0",
"statusCategoryCodeValue": "Data Search Unsuccessful - The payer is unable to return status on the requested claim(s) based on the submitted search criteria.",
"statusCode": "97",
"statusCodeValue": "Patient eligibility not found with entity."
}
}Troubleshooting steps
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 properties
Regardless of the status codes in the 277 response, we recommend immediately retrying with these properties 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. You can add the submitted amount in:
- JSON:
encounter.submittedAmount - X12:
Loop 2200D AMT02(Total Claim Charge Amount)
- JSON:
-
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:
- JSON:
transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails[].claims[].claimStatus.tradingPartnerClaimNumber - X12 EDI:
Loop 2200D REF02, whereREF01=1K(Payor's Claim Number) - Stedi portal: 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.
You can add the PCCN to your claim status request in:
- JSON:
encounter.tradingPartnerClaimNumber - X12:
Loop 2200D REF02(Payer Claim Control Number) whenREF01=1K(Payor's Claim Number)
- JSON:
-
Tax ID: The billing provider's Tax Identification Number (TIN). Some payers need this identifier instead of the NPI to find the right claim. You can add the tax ID in:
- JSON:
providers.taxId - X12:
Loop 2100C NM109(Provider Identifier) whenNM108is set toFI(Federal Taxpayer's Identification Number)
- JSON:
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:
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:
- JSON:
encounter.beginningDateOfServiceandencounter.endDateOfService - X12:
Loop 2200D DTP(Claim Service Date)
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.
You can adjust the NPI in:
- JSON:
providers.npi - X12:
Loop 2100C NM109(Provider Identifier)
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.
The following example shows an eligibility check response with an AAA error 75, indicating the payer couldn't find the subscriber in their system. In this case, you'd want to check the patient's demographic details to ensure they're correct. You may also want to reach out to your billing department to confirm whether the final claim was submitted to a different payer.
{
"subscriber": {
"memberId": "123456789",
"firstName": "JANE",
"lastName": "DOE",
"entityIdentifier": "Insured or Subscriber",
"entityType": "Person",
"dateOfBirth": "19001103",
"aaaErrors": [
{
"field": "AAA",
"code": "75",
"description": "Subscriber/Insured Not Found",
"followupAction": "Please Correct and Resubmit",
"location": "Loop 2100C",
"possibleResolutions": "- Subscriber was not found."
}
]
}
}Step 3: Retry for unavailable payers
If the payer continues returning status codes indicating that they are unavailable, we recommend implementing the following automated retry strategy:
- Wait 1 minute to perform the first retry.
- Exponentially increase the wait time between subsequent retries to up to 30 minutes.
- Retry for at least 8 hours, though the retry window should be based on your business workflows.
Step 4: 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.