277 Claim Status Codes: How to Read Accepted, Pending, Rejected, and Finalized Claims

A 277 claim status response tells a provider where a claim sits in the payer's process, using two separate X12 code lists: Claim Status Category Codes (list 507) for the broad state of the claim, and Claim Status Codes (list 508) for the specific detail. A category might say the claim was accepted, rejected, is pending or has been finalized; the status code explains the particular circumstance. Treating every "277 code" as the same kind of code makes automated claim status data much harder to interpret.

X12 describes the 508 list as codes that convey the status of an entire claim or a specific service line, and the 507 list as codes that organize those statuses into logical groupings. A useful mental model is simple. The category code answers "what broad state is the claim in?" and the status code answers "what specifically is happening?" A revenue cycle system that stores only one layer throws away information it will later need.

276 asks; 277 answers

In the standard claim status workflow, the provider or its clearinghouse sends a 276 Health Care Claim Status Request, and the payer responds with a 277. X12's implementation guide describes the 276 as the transaction used to request the status of a health care claim and the 277 as the transaction used to respond with information about the specified claim.

That is different from the 835 electronic remittance advice. The 277 reports status; the 835 carries the adjudication results and payment information used to post patient accounts. X12 has made this distinction explicit, noting that reporting finalized claims is a function of the 835 and that a list of finalized claims sent as a 277 would not include adjudication results. A finalized 277 status is therefore a signal to look for the remittance, not a substitute for it. Our guide to reading a remittance advice covers the 835 side.

Category groups answer the first question: where is the claim?

X12 organizes the category codes into groups, and five matter most for claim status work: A codes for acknowledgements, P codes for pending claims, F codes for finalized claims, E codes for errors and D codes for searches. X12 also maintains R codes for requests for additional information, but as explained below, they do not appear in an ordinary claim status response.

Within each group, the specific category carries the meaning. A1, A2 and A3 look similar but describe three very different situations, and the rest of this guide walks through the distinctions that change what a team should do next.

"Received" is not the same as "accepted"

A1 is one of the easiest responses to overinterpret. X12 defines it as acknowledgement of receipt, meaning the claim has been received, and states plainly that this does not mean the claim has been accepted for adjudication. A2 is stronger: the claim has been accepted into the adjudication system.

An organization monitoring submissions should never collapse A1 and A2 into one internal status. If the only evidence is transmission or receipt and the claim never shows acceptance into adjudication, it needs different follow-up from a claim the payer is already processing. Keeping the two apart also makes reconciliation between clearinghouse reports and payer records much cleaner.

A3, A6, A7 and A8 mean the claim was rejected, not denied

Several acknowledgement categories describe claims that never proceeded normally. A3 means the claim was returned as unprocessable: it was rejected and has not been entered into the adjudication system. A6 means it was rejected because information specified in the status details is missing, A7 means information specified in the status details is invalid, and A8 means it was rejected for a relational field in error.

These responses should be handled differently from adjudicated denials. A rejected claim never entered adjudication, so it has not been reviewed and denied the way an accepted claim is. That affects the correction strategy, the filing-deadline risk (a rejected claim still has to be corrected and resubmitted within the timely filing window) and how the organization measures its denial rate. Other acknowledgement codes are worth recognizing too: A4 means the claim cannot be found in the adjudication system, A5 means it was split on acceptance, and A0 means it was forwarded to another entity.

Pending categories explain why payment has not happened yet

The P categories mean the claim is still in process rather than finalized, and the specific code says why. P1 means the claim is in the adjudication system. P2 means it is suspended pending payer review, with X12 giving medical review, repricing and third-party administrator processing as examples. P3 means the claim is waiting for information that has already been requested from the provider, P4 means it is waiting for information already requested from the patient, and P5 indicates a payer administrative or system hold.

This detail is what turns claim status from a passive report into a work queue. "Pending" alone tells staff to wait; P3 tells them the payer is waiting on them. X12 requires a P3 or P4 response to carry a status code identifying the type of information requested, so the response itself points to what needs to be sent. Store both the category and the status code rather than reducing every P response to one internal value. (For claims stuck in payer review, see our explainer on what "pending medical review" means.)

Finalized does not always mean paid

The F categories mean adjudication is complete, but the outcome varies. F1 means the claim or line has been paid, F2 that it has been denied, F3 that adjudication information has been revised, and F4 that adjudication is complete and no payment is forthcoming. Two more codes cover coordination: F3F means processing is complete and the claim has been forwarded to a subsequent entity, such as a secondary payer, and F3N means it has not been forwarded.

A generic "finalized" status is not enough for a billing team, which needs to know whether finalization produced payment, denial, a revision, forwarding or no further payment. The financial detail itself still belongs to the 835 and the remittance workflow.

Where requests for additional information fit

X12's R categories describe requests for additional information: general requests, entity-specific information, claim or line details, supporting documentation (R4, with certification, x-rays and notes as examples), regulatory requirements, medical necessity (R9), prepayment review (R11) and several others. They are easy to mistake for claim status responses because they sit in the same category list.

In an ordinary 276/277 exchange, however, they are not used. X12's published interpretation of the 276/277 states that it allows all category codes except the R codes, and Medicare's 276/277 companion guide likewise returns any valid category except R. When a payer is waiting on the provider during claim status, the response will typically show a pending category such as P3 with a status code naming the missing information. Teams building status logic should not design around R codes arriving in 277 responses.

When the payer can't find the claim

The D group covers searches. D0, "Data Search Unsuccessful," means the payer is unable to return status on the requested claims based on the submitted search criteria, which often points to a mismatch in the identifiers or dates on the 276 request. Payers implement this differently, though. Medicare's companion guide, for example, returns category A4 with status code 35, "Claim/encounter not found," when it cannot locate the claim.

Either way, a "not found" response should not be treated as a final answer. It calls for checking the search criteria, the clearinghouse acceptance reports and the submission history before assuming the claim was lost, and it is one of the cases where a portal check or a call to the payer is often faster than resubmitting.

Do not confuse a 277 response with the 277CA acknowledgment

The 277CA is a separate transaction: a claim acknowledgment used for pre-adjudication claim editing, returned after a claim is submitted rather than in response to a status request. Its allowed categories are much narrower. X12's interpretations state that the 277CA uses only the acknowledgement category codes (A0 through A8) and error category codes (E1 through E4), with the error category limited to real-time use when the system is unavailable, and that using F, P or R categories in a 277CA is not compliant. X12 also notes there is no 277CA code for "accepted with errors or warnings."

Medicare's companion guide adds that a 277CA will never be used to respond to a 276 request. The practical implication is to store and analyze the two separately: a 277CA tells you whether the claim got into the payer's system, while a 277 status response tells you what has happened to it since.

A claim status response should produce a next action

The value of automated claim status is not collecting more codes; it is turning payer responses into work. An organization might map responses into a handful of operational classes: no action for claims accepted and processing normally; correction needed for rejections for missing, invalid or relational information; documentation needed when the payer is waiting on provider information; investigate when the payer cannot find the claim or the search failed; and post remittance when the claim is finalized and the 835 should be reconciled.

Keep the underlying X12 codes alongside the mapped class, so staff can see the source status and the mapping can be audited. Our guide to getting faster claim status updates from insurers covers the wider workflow, and our claim status automation reference covers how teams scale it.

Structured status is most useful when it knows its limits

Claim follow-up has historically meant staff logging into portals or calling payers simply to ask where an account sits. Standard 276/277 transactions answer part of that question electronically, but portals and phone calls are still needed when the response lacks enough detail, such as a pending status with no clear reason or a "not found" that contradicts the provider's records. SuperDial is designed for claim status work across EDI, APIs, portals and phone, returning structured outputs with source evidence, so the same record holds the answer regardless of which channel produced it.

The sensible architecture is not to replace every payer interaction with a 277. It is to use structured status when it answers the question and escalate to another channel when it does not.

The code is only useful if it changes the work

The 277 gives providers a standard vocabulary for where claims are in the payer's process. Acknowledgement codes show whether the claim reached adjudication, pending codes explain why processing has not finished, and finalized codes show that adjudication has concluded. The advantage comes from keeping enough detail to tell those states apart and routing each one to the right next action. A dashboard full of 277 codes is not the goal; fewer unnecessary status calls and faster resolution of actionable claims is.

FAQ

What is a 277 claim status response?

A 277 is the X12 transaction payers use to return claim status information, usually in response to a 276 claim status request. It reports the status using a claim status category code and a more specific claim status code.

What does A1 mean in a 277 response?

A1 means the claim has been received. X12 states that this does not mean it has been accepted for adjudication. A2 means it has been accepted into the adjudication system.

What does P3 mean?

P3 means the claim is pending because the payer is waiting for information it has already requested from the provider. X12 requires a status code identifying the type of information requested to accompany it.

What is the difference between a 277 and a 277CA?

A 277 is a claim status response to a 276 request. A 277CA is a claim acknowledgment sent after submission, and it uses only acknowledgement (A) codes and, in limited real-time cases, error (E) codes.

Is a 277 the same as an 835 remittance?

No. A 277 communicates claim status. An 835 communicates the payment and adjudication details needed to post the remittance.

Sources

All retrieved October 6, 2026.

• X12, "Claim Status Category Codes" (external code list 507): https://x12.org/codes/claim-status-category-codes
• X12, "Claim Status Codes" (external code list 508): https://x12.org/codes/claim-status-codes
• X12, "Health Care Claim Status Request and Response (005010X212)": https://ecommerce.x12.org/products/health-care-claim-status-request-and-response-005010-x212
• X12, RFI 2087, "Unsolicited Finalized 277s": https://x12.org/resources/requests-for-interpretation/rfi-2087-unsolicited-finalized-277s
• X12, RFI 1942, "Clarification STC01-1 in 277CA": https://x12.org/resources/requests-for-interpretation/rfi-1942-clarification-stc01-1-277ca
• X12, RFI 2203, "277CA: non-rejecting issues": https://x12.org/resources/requests-for-interpretation/rfi-2203-277ca-non-rejecting-issues
• CMS/CGS, "276/277 Version 005010 Companion Guide," Version 8.0 (August 2026): https://www.cgsmedicare.com/pdf/edi/276_277_compguide.pdf