Interpret claim status

Claim status codes tell you where a claim is in its lifecycle, such as accepted, rejected, pending, or finalized as paid or denied. Each status contains up to three codes:

Code type	What it tells you	Example
Claim Status Category Code	The broad state of a submission, claim, or service line.	`A7` (Rejected for Invalid Information)
Claim Status Code	A more specific state. For rejections and denials, it typically gives the reason.	`562` (Entity's National Provider Identifier (NPI))
Entity Identifier Code	The person, organization, or location related to the status. Not every status includes one.	`85` (Billing Provider)

This page explains where to find the codes in 277CA claim acknowledgments and claim status responses, how they differ from the statuses in the Stedi portal, and how to interpret the codes you're most likely to receive.

Find claim status codes

The codes on this page come from X12, the standard that HIPAA requires for healthcare transactions. Payers and Stedi send these codes in 277CA claim acknowledgments and real-time claim status responses. The codes explain the details of a claim's status, including why Stedi or the payer rejected it. They can also pinpoint problems with specific parts of the claim, such as a service line or the billing provider's information.

Stedi also assigns each claim its own processing status, such as Rejected or Processed, in the Stedi portal's claims view. These Stedi statuses are different from the X12 codes on this page. They summarize where the claim is in its lifecycle, based on the 277CAs for the claim's latest submission and its 835 ERAs.

To learn what each of Stedi's claim processing statuses means, visit Claim processing status in the claims view documentation. When you review 277CAs or claim status checks directly, use the codes and guidance on this page.

277CA claim acknowledgments

Stedi and payers send 277CA claim acknowledgments after you submit a claim to tell you whether they accepted or rejected it for processing. These statuses don't indicate whether the payer approves or denies the claim. A 277CA can include statuses at the information receiver, provider, claim, and service line levels.

Information receiver statuses

Information receiver statuses apply to the entire submission, not to a specific claim. Use these statuses to confirm that Stedi or the payer received the submission. An information receiver status can show an accepted submission even when another level shows a rejection. For example:

Claim accepted: When Stedi accepts a claim and forwards it to the payer, the information receiver status contains category code A1 (Receipt) and status code 19 (Entity acknowledges receipt of claim/encounter).
Claim rejected: When Stedi rejects a claim because of a problem with the claim's data, the information receiver status can still contain category code A1 and status code 20 (Accepted for processing). The rejection appears at the level with the problem, such as the claim-level or provider-level status.
Submitter rejected: When Stedi rejects a claim because of a problem with the submitter or receiver information, the rejection is in the information receiver status.

In the 277CA report response, the following properties are in each object in the transactions[].payers[].claimStatusTransactions[].providerClaimStatuses[].providerStatuses array.

Code type	Location
Claim Status Category Code	JSON: `healthCareClaimStatusCategoryCode` X12 EDI: `Loop 2200B STC01-01` (Health Care Claim Status Category Code)
Claim Status Code	JSON: `statusCode` X12 EDI: `Loop 2200B STC01-02` (Status Code)
Entity Identifier Code	JSON: `entityIdentifierCode` X12 EDI: `Loop 2200B STC01-03` (Entity Identifier Code)

The following example shows an information receiver status from a 277CA where Stedi rejected a claim because of a problem with the billing provider's NPI. The submitter and receiver information passed Stedi's claim edits, so the information receiver status contains category code A1 (Receipt) and status code 20 (Accepted for processing), with no entity identifier code. The rejection is in the provider-level status, shown in the next example.

"providerClaimStatuses": [
  {
    "providerStatuses": [
      {
        "healthCareClaimStatusCategoryCode": "A1",
        "healthCareClaimStatusCategoryCodeValue": "Acknowledgement/Receipt - The claim/encounter has been received. This does not mean that the claim has been accepted for adjudication.",
        "statusCode": "20",
        "statusCodeValue": "Accepted for processing."
      }
    ],
    "statusInformationEffectiveDate": "20250101"
  }
]

STC*A1`20*20250101*WQ*150.00~

Provider-level statuses

Provider-level statuses apply to all the claims for one billing provider in the submission. Use these statuses to identify problems that affect all of a billing provider's claims, such as invalid billing provider information. A single 837 transaction can contain claims for multiple billing providers, and each provider can have its own provider-level status.

Stedi's 277CAs: Only include a provider-level status when Stedi rejects a claim because of a problem with the billing provider's information.
Payers' 277CAs: Payers may include a provider-level status for each billing provider in the submission.

In the 277CA report response, the following properties are in each object in the transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].serviceProviderClaimStatuses[].serviceProviderStatuses array.

Code type	Location
Claim Status Category Code	JSON: `healthCareClaimStatusCategoryCode` X12 EDI: `Loop 2200C STC01-01` (Health Care Claim Status Category Code)
Claim Status Code	JSON: `statusCode` X12 EDI: `Loop 2200C STC01-02` (Status Code)
Entity Identifier Code	JSON: `entityIdentifierCode` X12 EDI: `Loop 2200C STC01-03` (Entity Identifier Code)

The following example shows the provider-level status from the same 277CA as the information receiver example. It contains category code A7 (Rejected for Invalid Information), status code 562 (Entity's National Provider Identifier (NPI)), and entity identifier code 85 (Billing Provider). The provider-level status has no effective date.

"serviceProviderClaimStatuses": [
  {
    "serviceProviderStatuses": [
      {
        "entityIdentifierCode": "85",
        "entityIdentifierCodeValue": "Billing Provider",
        "healthCareClaimStatusCategoryCode": "A7",
        "healthCareClaimStatusCategoryCodeValue": "Acknowledgement/Rejected for Invalid Information - The claim/encounter has invalid information as specified in the Status details and has been rejected.",
        "statusCode": "562",
        "statusCodeValue": "Entity's National Provider Identifier (NPI)."
      }
    ]
  }
]

STC*A7`562`85**U*150.00~

Claim-level statuses

Claim-level statuses apply to the entire claim. Use these statuses to learn whether Stedi or the payer rejected the claim because of a problem with the claim's information, and why. When Stedi rejects a claim because of a problem elsewhere, such as with the billing provider or a service line, the claim-level status still contains A1 (Receipt) and 20 (Accepted for processing), and the rejection appears at that level. A rejection includes codes for each problem and can include an explanatory message in statusMessage (STC12 in X12 EDI).

In the 277CA report response, the following properties are in each object in the transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails[].claims[].claimStatus.informationClaimStatuses[].informationStatuses array.

Code type	Location
Claim Status Category Code	JSON: `healthCareClaimStatusCategoryCode` X12 EDI: `Loop 2200D STC01-01` (Health Care Claim Status Category Code)
Claim Status Code	JSON: `statusCode` X12 EDI: `Loop 2200D STC01-02` (Status Code)
Entity Identifier Code	JSON: `entityIdentifierCode` X12 EDI: `Loop 2200D STC01-03` (Entity Identifier Code)

The following example shows a claim-level status from a 277CA where the payer rejected a claim because of a problem with the billing provider's NPI. It contains category code A3 (Returned as Unprocessable Claim), status code 562 (Entity's National Provider Identifier (NPI)), entity identifier code 85 (Billing Provider), and the payer's explanatory message.

"informationClaimStatuses": [
  {
    "informationStatuses": [
      {
        "entityIdentifierCode": "85",
        "entityIdentifierCodeValue": "Billing Provider",
        "healthCareClaimStatusCategoryCode": "A3",
        "healthCareClaimStatusCategoryCodeValue": "Acknowledgement/Returned as unprocessable claim - The claim/encounter has been rejected and has not been entered into the adjudication system.",
        "statusCode": "562",
        "statusCodeValue": "Entity's National Provider Identifier (NPI)."
      }
    ],
    "statusInformationActionCode": "U",
    "statusInformationActionCodeValue": "Reject",
    "statusInformationEffectiveDate": "20260702",
    "statusMessage": "ACK,RETURND AS UNPRCESSBLE CLM-REJECT & RETURN TO PROVIDER:ENTITY'S NATIONAL PROVIDER IDENTIFIER - NPI:BILLING PROVIDER",
    "totalClaimChargeAmount": "148"
  }
]

STC*A3`562`85*20260702*U*148********ACK,RETURND AS UNPRCESSBLE CLM-REJECT & RETURN TO PROVIDER:ENTITY'S NATIONAL PROVIDER IDENTIFIER - NPI:BILLING PROVIDER~

Service line statuses

Service line statuses apply to a specific service line. Use these statuses to identify which service lines caused a rejection. Stedi's 277CAs only include them when Stedi rejects the claim because of a problem with service line information. Payers may include them in other cases.

In the 277CA report response, the following properties are in each object in the transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails[].claims[].serviceLines[].serviceClaimStatuses[].serviceStatuses array.

Code type	Location
Claim Status Category Code	JSON: `healthCareClaimStatusCategoryCode` X12 EDI: `Loop 2220D STC01-01` (Health Care Claim Status Category Code)
Claim Status Code	JSON: `statusCode` X12 EDI: `Loop 2220D STC01-02` (Status Code)
Entity Identifier Code	JSON: `entityIdentifierCode` X12 EDI: `Loop 2220D STC01-03` (Entity Identifier Code)

The following example shows a service line status from a 277CA where Stedi rejected a service line because of an invalid procedure code. It contains category code A7 (Rejected for Invalid Information), status code 454 (Procedure code for services rendered), and an explanatory message, with no entity identifier code.

"serviceClaimStatuses": [
  {
    "serviceStatuses": [
      {
        "healthCareClaimStatusCategoryCode": "A7",
        "healthCareClaimStatusCategoryCodeValue": "Acknowledgement/Rejected for Invalid Information - The claim/encounter has invalid information as specified in the Status details and has been rejected.",
        "statusCode": "454",
        "statusCodeValue": "Procedure code for services rendered."
      }
    ],
    "statusMessage": "Procedure code is invalid 99213. Correct and resubmit."
  }
]

STC*A7`454**U*********Procedure code is invalid 99213. Correct and resubmit.~

Real-time claim status checks

A real-time claim status check returns the payer's current status for a claim that's in adjudication or has been adjudicated. The response can include statuses at the claim level and at the service line level.

Claim-level statuses

Claim-level statuses apply to the entire claim. Use these statuses to learn whether the claim is pending or finalized as paid or denied.

In JSON, the following properties are in the claims[].claimStatus object.

Code type	Location
Claim Status Category Code	JSON: `statusCategoryCode` X12 EDI: `Loop 2200D STC01-01`, or `Loop 2200E STC01-01` for dependents, (Health Care Claim Status Category Code)
Claim Status Code	JSON: `statusCode` X12 EDI: `Loop 2200D STC01-02`, or `Loop 2200E STC01-02` for dependents, (Status Code)
Entity Identifier Code	JSON: `entityCode` X12 EDI: `Loop 2200D STC01-03`, or `Loop 2200E STC01-03` for dependents, (Entity Identifier Code)

The following example shows a response where the payer couldn't find the patient in their system. It contains category code D0 (Data Search Unsuccessful), status code 97 (Patient eligibility not found with entity), and entity identifier code IN (Insurer).

{
  "claims": [
    {
      "claimStatus": {
        "amountPaid": "0",
        "claimServiceDate": "20250526-20250601",
        "effectiveDate": "2025-08-25",
        "entity": "Insurer",
        "entityCode": "IN",
        "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.",
        "submittedAmount": "0",
        "trackingNumber": "123456789"
      }
    }
  ]
}

TRN*2*123456789~
STC*D0`97`IN*20250825**0*0~
DTP*472*RD8*20250526-20250601~

Service line statuses

Service line statuses apply to a specific service line. Use these statuses to learn the status of each service line, such as which lines the payer denied.

In JSON, the following properties are in each object in the claims[].serviceDetails[].status array.

Code type	Location
Claim Status Category Code	JSON: `statusCategoryCode` X12 EDI: `Loop 2220D STC01-01`, or `Loop 2220E STC01-01` for dependents, (Health Care Claim Status Category Code)
Claim Status Code	JSON: `statusCode` X12 EDI: `Loop 2220D STC01-02`, or `Loop 2220E STC01-02` for dependents, (Status Code)
Entity Identifier Code	JSON: `entityCode` X12 EDI: `Loop 2220D STC01-03`, or `Loop 2220E STC01-03` for dependents, (Entity Identifier Code)

The following example shows a service line that the payer denied. It contains category code F2 (Finalized/Denial) and status code 585 (Denied Charge or Non-covered Charge), with no entity identifier code.

{
  "claims": [
    {
      "serviceDetails": [
        {
          "service": {
            "amountPaid": "0",
            "procedureId": "90800",
            "serviceIdQualifier": "Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes",
            "serviceIdQualifierCode": "HC",
            "submittedAmount": "200.02",
            "submittedUnits": "1"
          },
          "status": [
            {
              "effectiveDate": "2024-11-10",
              "statusCategoryCode": "F2",
              "statusCategoryCodeValue": "Finalized/Denial - The claim/line has been denied.",
              "statusCode": "585",
              "statusCodeValue": "Denied Charge or Non-covered Charge."
            }
          ]
        }
      ]
    }
  ]
}

SVC*HC`90800*200.02*0****1~
STC*F2`585*20241110~

Error statuses

Error statuses explain why Stedi or the payer couldn't process the claim status check, such as when the payer is unavailable. The response's errorResponse.errors array contains:

Request and provider errors: In X12, Loop 2200B (Information Receiver Trace Identifier) and Loop 2200C (Provider of Service Trace Identifier) only contain an STC (Status Information) segment when there's a problem with the whole request or with the provider. Stedi puts these statuses in errorResponse.errors, not in claims. Stedi returns its own 484, 562, 667, and 689 codes in Loop 2200B.
Claim-level errors: Claim-level statuses with an E0–E4 category code. These include the codes Stedi returns when the claim status request is missing information the payer requires, such as the service date.

The following example shows a provider status where the payer couldn't return a claim status because of a problem with the provider's name. It contains category code D0 (Data Search Unsuccessful), status code 125 (Entity's name), and entity identifier code 1P (Provider).

{
  "errorResponse": {
    "errors": [
      {
        "code": "D0",
        "description": "Provider information requires correction",
        "field": "STC",
        "followupAction": "Please Correct and Resubmit",
        "location": "Loop 2200C",
        "value": "Data Search Unsuccessful - The payer is unable to return status on the requested claim(s) based on the submitted search criteria."
      },
      {
        "code": "125",
        "description": "Provider information requires correction",
        "field": "STC",
        "followupAction": "Please Correct and Resubmit",
        "location": "Loop 2200C",
        "value": "Entity's name."
      },
      {
        "code": "1P",
        "description": "Provider information requires correction",
        "field": "STC",
        "followupAction": "Please Correct and Resubmit",
        "location": "Loop 2200C",
        "value": "1P"
      }
    ]
  }
}

STC*D0`125`1P*20251223~

Common codes and next steps

The following sections explain how to handle the codes you're most likely to receive:

Category codes: Which codes mean the claim moved forward, which mean the payer needs more information, and which signal a problem.
Status codes: What each code means and the next steps to take.
Entity identifier codes: The person, organization, or location related to the status.

Each section links to the full code list.

Category codes

The category code tells you the broad state of a submission, claim, or service line. For the full list, visit Claim Status Category Codes in the X12 documentation.

Prefixes

Every category code starts with a prefix of one or more letters, such as the A in A7 or the DR in DR01. The prefix indicates the high-level state.

277CAs typically contain only A category codes. Claim status responses typically contain other prefixes, including P and F codes for pending and finalized claims, D codes when the payer can't find a matching claim, and E codes when the payer can't process the request.

Codes with the same prefix can mean different things, so build your logic on the full category code. Category codes can have one of the following prefixes:

Prefix	Family	Meaning
`A`	Acknowledgment	Stedi or the payer received the claim and processed it to some stage. `A0`–`A2` and `A5` mean the claim moves forward. The other `A` codes signal a problem.
`P`	Pending	The claim is in adjudication, or it's on hold because the payer requested more information.
`F`	Finalized	Adjudication is complete, usually with a payment or a denial.
`R`	Request for additional information	The payer needs more information from you.
`DR`	Data reporting acknowledgment	The payer acknowledged a data reporting submission.
`E`	Error	Stedi or the payer couldn't process the request.
`D`	Data	The payer couldn't find a claim that matches the submitted data.

Claim moved forward

Category code	Meaning
`A0`–`A2`, `A5`	Stedi or the payer acknowledged the claim, and it moves forward.
`P0`–`P2`, `P5`	The claim is in adjudication.
`F0`–`F4`	Adjudication is complete, usually with a payment or a denial.

Payer needs more information

Category code	Meaning
`P3`	The payer is waiting for information that it already requested from the provider. The status code identifies the requested information.
`P4`	The payer is waiting for information that it already requested from the patient. The status code identifies the requested information.

Problem with the claim or request

Category code	Meaning
`A3`	Stedi or the payer returned the claim as unprocessable. The claim doesn't move forward.
`A4`	The payer has no matching claim. Typically returned for claim status checks.
`A6`	Stedi or the payer rejected the claim for missing information.
`A7`	Stedi or the payer rejected the claim for invalid information.
`A8`	Stedi or the payer rejected the claim because fields in the claim conflict with each other.
`D0`	The payer couldn't match a claim to the claim status check.
`E0`–`E4`	Stedi or the payer couldn't process the request. Typically returned for claim status checks. `E1` and `E2` typically mean the payer's system is unavailable. `E0`, `E3`, and `E4` typically mean there's a problem with the information you sent.

Status codes

The following table lists common status codes and their next steps, in numerical order. Most indicate a problem, but some also appear on accepted or finalized claims. Many status codes name a field or entity, so combine them with the category code and entity identifier code to identify the problem.

For the full list, visit Claim Status Codes in the X12 documentation.

Status code	Meaning	What to do
`0`	Cannot provide further status electronically.	The payer won't return more detail electronically. Check the Electronic Remittance Advice (ERA), Explanation of Benefits (EOB), or Explanation of Payment (EOP) if you have one. Otherwise, contact the payer.
`21`	Missing or invalid information.	Look for a second status code that identifies the missing or invalid field. Correct the claim and resubmit.
`25`	Entity not approved.	The payer hasn't approved the entity, typically the billing provider. Check the provider's credentialing and enrollment status with the payer.
`26`	Entity not found.	The entity, typically the billing provider, isn't on file with the payer. Check the provider's NPI, Tax Identification Number (TIN), or other identifiers with the payer.
`31`	Subscriber and policyholder name mismatched.	The subscriber's name doesn't match the payer's records. Run an eligibility check to see the name the payer has on file, then resubmit with that name.
`33`	Subscriber and subscriber ID not found.	The subscriber's information and member ID don't match. Run an eligibility check to see the information the payer has on file, then resubmit with that information.
`35`	Claim/encounter not found.	The payer couldn't find a claim that matches the claim status check. Follow the claim status troubleshooting steps.
`88`	Entity not eligible for benefits for submitted dates of service.	The entity wasn't eligible on the dates of service. Run an eligibility check to confirm coverage on those dates.
`96`	No agreement with entity.	The entity, typically the billing provider, doesn't have an agreement with the payer. Check the provider's status with the payer.
`97`	Patient eligibility not found with entity.	The payer doesn't list the patient as eligible. Run an eligibility check to confirm coverage. For claim status checks, verify the patient demographics in the request.
`109`	Entity not eligible.	The entity, typically the patient, isn't listed as eligible with the payer. Run an eligibility check to confirm coverage.
`116`	Claim submitted to incorrect payer.	For claim status checks, check the provider's credentialing for claim status checks with the payer. Otherwise, confirm the patient's payer with an eligibility check.
`125`	Entity's name.	The entity's name is missing or doesn't match the payer's records. If the entity is the patient, run an eligibility check to see the name the payer has on file. Then correct and resubmit.
`158`	Entity's date of birth.	The entity's date of birth, typically the patient's, is missing or doesn't match the payer's records. If the entity is the patient, run an eligibility check to see the date of birth the payer has on file. Then correct and resubmit.
`187`	Date(s) of service.	The dates of service are missing or invalid. Check the dates and resubmit.
`454`	Procedure code for services rendered.	A procedure code is missing or invalid. Check the procedure codes and resubmit.
`484`	Business application currently not available.	Typically returned for claim status checks. Stedi returns this code with an HTTP `429` error when your account exceeds its concurrency limit, and without one when the payer limits the request rate. A payer can also return it when its system is temporarily unavailable. In all cases, retry later.
`485`	More information available than can be returned in real-time mode. Narrow your current search criteria.	Too many claims matched the claim status check. Add properties such as the submitted amount, Payer Claim Control Number (PCCN), and TIN, then resubmit.
`494`	Real-time requests not supported by the information holder, resubmit as batch request.	The payer doesn't support real-time claim status checks. Don't retry. Confirm the payer's support for claim status checks in the Payer Network or the Payers API.
`505`	Entity's first name.	The entity's first name is missing or doesn't match the payer's records. If the entity is the patient, run an eligibility check to see the name the payer has on file. Then correct and resubmit.
`562`	Entity's National Provider Identifier (NPI).	The NPI for the entity, typically the billing or rendering provider, is missing or doesn't match the payer's records. For claim status checks, Stedi also returns this code when the NPI in the request isn't a valid NPI. Check the NPI and resubmit. For claim status checks, check the billing provider NPI.
`667`	Real-time requests not supported by the information holder, do not resubmit.	Don't retry. Payers return this code when they don't support real-time claim status checks, and Stedi returns it when it can't route the request to the payer. Confirm the payer's support for claim status checks in the Payer Network or the Payers API.
`689`	Entity was unable to respond within the expected time frame.	The payer timed out. Typically returned for claim status checks. Retry the check.

Entity identifier codes

The entity identifier code identifies the person, organization, or location related to the status. For example, when category code A7 and status code 562 come with entity identifier code 85, the NPI problem is with the billing provider.

Code	Entity
`1P`	Provider
`77`	Service location
`82`	Rendering provider
`85`	Billing provider
`DN`	Referring provider
`IL`	Insured or subscriber
`PR`	Payer
`QC`	Patient

For the full list, visit Entity identifier in the claims code lists.

Build workflow logic

Use the category code, status code, and entity identifier code together to understand a claim's status. For example, category code A7, status code 562, and entity identifier code 85 together mean a rejection for a problem with the billing provider's NPI.

The same status code can appear under different category codes, so we recommend building logic on the category code and status code together. For example, status code 21 (Missing or invalid information) can come with category code A6 (Rejected for Missing Information) or A7 (Rejected for Invalid Information).

Each transaction includes several types of statuses. Base your logic on the statuses for each claim:

Real-time claim status checks: Use the claim-level status and, when the response includes them, the service line statuses.
277CA claim acknowledgments: Check the statuses at every level. A rejection at any level means Stedi or the payer rejected the claim, even when the claim-level status contains A1 and 20. In Stedi's 277CAs, the rejection appears at the level with the problem: the information receiver status for submitter information, the provider-level status for billing provider information, the claim-level status for claim information, or the service line status for a specific service line.

Start with the category code to determine the claim's status, then use the status code and entity identifier code to decide on next steps.

Claim status	Category codes	Next steps
Acknowledged	`A0`–`A2`, `A5`	The claim moves forward. Wait for the payer's next 277CA or check its status later.
Pending	`P0`–`P2`, `P5`	The claim is in adjudication. Check again later.
Waiting for information	`P3`, `P4`	Use the status code to identify the information the payer requested.
Finalized	`F0`–`F4`	Adjudication is complete, usually with a payment or a denial. Stop checking. The payer typically sends an 835 ERA or EOB that explains the result.
Request for additional information	`R` codes	Send the payer the requested documentation.
Error	`E0`–`E4`	For `E1` and `E2`, retry. For `E0`, `E3`, and `E4`, correct the request before resending. Some payers send `E1` when the request is incorrect, so check the request if retries keep failing.
Rejected	`A3`, `A6`, `A7`, `A8`	Use the status code and entity identifier code to find the field to correct, then correct the claim and resubmit it.
Not found	`A4`, `D0`	The payer couldn't match a claim to the claim status check. Follow the claim status troubleshooting steps.

Interpret claim status

On this page