Claim status codes in plain English

When you submit a claim, healthcare clearinghouses – like Stedi – and payers use claim status codes to tell you where the claim is in its lifecycle: accepted, rejected, paid, denied, etc.

The codes show up in two standard healthcare transactions:

• 277CA claim acknowledgments, which both clearinghouses and payers send back asynchronously after you submit a claim.

• Claim status checks, which you can run in real time to check a claim's status once it's in adjudication (processing) with the payer.

On their own, claim status codes are terse and easy to misread. But once you know how to interpret them, you can build logic and automated workflows that respond to each status.

If you're building AI agents or applications that act based on claim status codes, this guide is for you. It covers what the codes are, how to interpret them, and how to act on the most common ones.

What are claim status codes?

Claim acknowledgments and claim status check responses include codes that describe the claim's status: a claim status category code and a claim status code.

Some also include an entity identifier code that tells you who or what the status relates to.

Together, these codes show where the claim stands.

Written out, the codes are often separated by a colon (:). The example above reads A7:562:85 – rejected because of a problem with the billing provider's NPI. Without an entity identifier, you might see A7:31 – rejected because the subscriber's name doesn't match the policyholder's.

While certain category and status codes often appear together, the pairings aren't fixed. The same status code can appear under different category codes. 21 (missing or invalid information) might come back as A6:21 (rejected for missing information) or A7:21 (rejected for invalid information). Read the category and status codes together; don't build logic on the status code alone.

Clearinghouse acknowledgments

Claim acknowledgments can come from the provider's clearinghouse (like Stedi), an intermediary healthcare clearinghouse that's needed to reach the payer, or the payer itself.

For example, Stedi returns a claim acknowledgment after a claim passes our claim edits and is forwarded to the payer. We also send an acknowledgment if a claim fails our edits and is rejected.

We use A1:16:PR to indicate a claim passed our edits and was forwarded. If a claim is rejected because it fails our edits, the claim acknowledgment we send includes category codes, claim status codes, entity identifiers (when applicable), and an error message that tells you why – and how to fix it.

The claim status codes we send are identical to those that may be sent by the payer or an intermediary clearinghouse. It's the sender – not the code – that tells you who accepted, forwarded, or rejected the claim. A claim that's accepted or forwarded by Stedi may still later be rejected by the payer.

Where to find claim status codes

Here are the fields where these codes show up in Stedi's JSON API responses:

For example, here's how a rejection looks in a Real-Time Claim Status JSON response:

{
  "claims": [
    {
      "claimStatus": {
        "statusCategoryCode": "A7", // Rejected for invalid information.
        "statusCode": "562", // Problem with the entity's NPI.
        "entityCode": "85", // The entity is the billing provider.
        "trackingNumber": "0123456789",
        "tradingPartnerClaimNumber": "0123456789",
        ...
      },
      ...
    }
  ],
  ...
}

The same codes appear in raw X12, in the STC (Claim Level Status Information) segment of Loop 2200D (Claim Status Tracking Number). They make up the composite element STC01: STC01-01 is the category code, STC01-02 the status code, and STC01-03 the entity identifier. Both the 277 status response (X212) and the 277CA acknowledgment (X214) contain the composite element.

For example, here's how a rejection from a Stedi claim edit looks in an X12 claim acknowledgment:

STC*A7>562>85*[DATE]*U*[AMOUNT]********Provider NPI is inactive. The NPI submitted, 1255328415, is inactive according to the National Plan and Provider Enumeration System (NPPES). An active NPI is required for claim submission. Correct and resubmit.~

Stedi uses > as the component separator, so A7>562>85 is the same as the A7:562:85 grouping described above.

Note: A claim acknowledgment or claim status response can include information about more than one claim, and a single claim can carry more than one set of codes.

What do the letter prefixes in claim status category codes mean?

Every claim status category code starts with one or more letters. For example, the A in A7 or the DR in DR01. The letters indicate the claim's highest-level state at a glance.

Use the prefix for an initial read of the claim's state, but don't treat it as the final word. Build your logic on the full category code, not the prefix alone.

For example, most A codes mean the claim is moving forward, but a few are rejections.

Note: Claim acknowledgments return category codes with an A prefix – or an E code if the payer's system is temporarily down.

Common claim status category codes

The category code shows where the claim is in the processing lifecycle. The following tables list the category codes you're most likely to see.

For the full list, see the X12 claim status category codes.

Category codes that mean the claim moved forward

Category codes that signal a problem

Common claim status codes

The following table outlines claim status codes we're commonly asked about at Stedi. Many of these codes commonly show up as errors, though a few also appear on accepted or finalized claims.

We've provided next steps where applicable. Codes are listed in numerical order for easier lookup. Many name a field or entity, so read them alongside the category and entity identifier codes.

For the full list of claim status codes, see the X12 claim status codes.

Common entity identifier codes

The entity identifier code names who or what a status refers to. It qualifies the status code: A7:562:85 means the NPI problem is with the billing provider.

For the full list, see the X12 entity identifier codes.

Turn codes into workflow logic

If you're building workflows or logic for claim statuses, we recommend reading the codes in order:

1. Category code
2. Status code
3. Entity identifier code

The category code decides the branch:

• Finalized (F) – adjudication is done. Record the result and stop checking.
• Pending (P) – still in process. Wait, then check again later.
• Needs more information (R) – send the payer the requested documentation.
• Error (E) – the payer couldn't process the request. E1 and E2 usually mean downtime, so retry. E0, E3, and E4 mean a bad request, so fix it before resending.
• Rejected or not found (A4, A6, A7, A8, D0) – read the status code to see which field is wrong, correct it, and resubmit.

The status code and entity identifier decide the next steps.

Handling claim status check errors

A claim status check searches for a claim rather than reporting on one you just submitted. It can return category codes you won't see on an acknowledgment: D0 (data search unsuccessful) and the E category codes (response not possible).

For example, a check might return D0:35 (claim not found) when the payer can't match your search, or E1 when the payer's system is temporarily down.

A D0 or E category code usually comes down to one of these issues:

• Wrong data: The check contains an incorrect patient detail, NPI, or date of service. Double-check the request against what you submitted on the claim. If you don't have the claim submission, run an eligibility check.

• Missing data: Start with the recommended base request. Extra data increases the chance the check won't match a claim. If the base request finds no match, add fields like the submitted amount, payer claim control number (PCCN), and tax ID. Some payers require these fields.

• Payer limitation: The payer is down or doesn't support real-time claim status checks – either at all or for certain claim types, like dental. The category codes are E1 and E2, and the status codes that flag it (484, 494, 667, 689) are in the common codes table above. Confirm the payer supports real-time claim status checks using the Payers API or the Stedi Payer Network, then retry.

For detailed step-by-step troubleshooting, see Troubleshoot claim status checks in our docs.

Get started with Stedi

You can submit claims, get claim acknowledgments, and run real-time claim status checks through Stedi's developer-friendly APIs.

To get started, sign up for a free sandbox account. It takes less than two minutes. No credit card is required.

When you're ready, upgrade to production on our pay-as-you-go plan. There are no monthly minimums or setup fees. You only pay for the transactions you use.