The 276/277 Claim Status Transaction
Payers do not narrate progress, so status is a question you ask rather than a signal you receive. The claim status transaction is how the question gets asked at the scale of a receivable — and it is worth understanding precisely, because it answers where, not why.
Updated 8 min read
On this page
Key takeaways
- It is an adopted standard, not a payer courtesy. Regulation defines the transaction and adopts both the format and operating rules for it.
- That is what makes portfolio-scale follow-up possible: a batch inquiry can ask about the whole workable book, which no phone call can.
- The response reports a position in the payer's process. It is not a decision, not an explanation, and not a promise about the outcome.
- “No record of this claim” is the answer worth the whole exercise — and it is not a slow claim, it is an absent one, with a filing clock still running.
- A claim status response is not a submission acknowledgment. They answer different questions at different moments, and confusing them wastes a follow-up cycle.
A standard, not a courtesy
The transaction has a definition in federal regulation rather than in a payer's provider manual. Under 45 CFR 162.1401 (opens in a new tab), the health care claim status transaction is the transmission of either an inquiry from a health care provider to a health plan to determine the status of a health care claim, or a response from a health plan to a provider about that status. The inquiry is the 276; the response is the 277.
Two further sections matter operationally. 45 CFR 162.1402 (opens in a new tab) adopts the ASC X12 technical standard for the request and response, so the format is fixed rather than negotiated per payer. And 45 CFR 162.1403 (opens in a new tab) adopts operating rules for the transaction — rules about how it runs, not only about how it is shaped.
Why that framing changes how a practice behaves
What the response actually tells you
A 277 reports where a claim sits in the payer's process. It is a position report, and reading it as anything else is the most common way the transaction disappoints the people using it.
- It is not a decision
- A claim reported as in process is not a claim that will be paid; a claim reported as finalized is not necessarily a claim that was paid. The decision, its reasons, and the money arrive on the remittance, which is a different transaction answering a different question.
- It is not an explanation
- The response tells you the state, not the reasoning that produced it. Where a claim is pending for additional information, the response can say that something is needed without the response being where the practice learns what to send.
- It is a category plus a code
- The response reports status as a category together with a more specific code, and the pairing is what carries the meaning — the same structural pattern as a group code and a reason code on a remittance. Their published wording is licensed, so a practice reads them through its own system's translation rather than from a table copied off a website.
The answer that is worth the whole exercise
It is not a submission acknowledgment
This is the boundary most worth getting right, because the two look similar, arrive from similar-sounding transactions, and answer completely different questions.
| Acknowledgment | Claim status response | |
|---|---|---|
| The question | Did the claim arrive and pass structural checks? | Where has the claim reached in adjudication? |
| When | Immediately after submission, without anyone asking — it is pushed back through the submission channel. | Whenever the practice asks, and only then. Nothing arrives unprompted. |
| What a bad answer means | The claim was rejected before adjudication and, for most purposes, was never received. It is not a denial and there is nothing to appeal. | The claim is somewhere unexpected in the payer's process — or nowhere, which is the case worth finding. |
The acknowledgment layer and how to read it belongs to reading claim submission acknowledgments. A claim that failed there should never reach a status inquiry, because there is nothing at the payer to ask about.
Which is why unacknowledged claims are not a follow-up problem
Using it as the backbone of follow-up
The design that gets the most out of the transaction is the one that treats it as the first pass over the whole workable set rather than as a lookup for one claim someone is already worried about.
Ask in batch, across the workable set
Whatever the practice's follow-up criteria produce, ask about all of it. The marginal cost of one more claim in a batch inquiry is close to nothing, which is the opposite of the economics of a phone call and the reason the batch view should be the default.Triage the responses, do not read them one by one
Most answers need no human at all — a claim progressing normally is a claim to ask about again later. The value of the pass is the minority that come back as absent, as needing something, or as finalized without a remittance the practice has posted.Route each exception to a different place
Absent claims go to submission evidence and refiling. Pending-for-information claims go to whoever can produce the information. Finalized-but-unposted claims go to posting or reconciliation, not to a payer call — the money may already be in the bank.Reserve human contact for what a status cannot resolve
A response that says a claim is in process, repeatedly, past the point where that payer's claims usually finalize, is the case a call is for. Calling before the transaction has been asked is spending the expensive channel on a question the cheap one would have answered.
Whatever the answer, write down who said it
What it will not do
Three limits are worth stating plainly, because each one is a reason practices abandon the transaction after expecting the wrong thing from it.
- It will not tell you why a payer will decide as it does. A pending claim is pending; the reasoning arrives with the decision, and reading it is a different skill covered in reading a denial.
- It will not make a stalled claim move. Asking about a claim is not an action on it. A claim that has been in the same state across several passes needs an intervention, and the transaction's job was to identify it, not to fix it.
- It will not replace the remittance. A claim reported as finalized has been decided, not necessarily paid, and certainly not posted. Treating a finalized status as a resolution is how an account leaves a follow-up queue without the money ever arriving.
Its real value is negative information
Common questions
What is the difference between a 277 and a 277CA?
They answer different questions at different moments. An acknowledgment tells you whether a claim arrived and passed the payer's front-end checks, and it comes back through the submission channel without anyone asking. A claim status response tells you where a claim has reached in adjudication, and only ever when the practice asks. A claim that failed at the acknowledgment layer should not be in a status-inquiry queue at all, because there is nothing at the payer to ask about.
The status says the claim is in process. Is that useful?
Yes, as a negative: it is not lost, not waiting on you, and not finalized without your knowledge. That is enough to leave it alone and ask again later. It becomes a signal only when it persists past the point where that payer's claims usually finalize — which is a threshold from your own history rather than a published number, and is the case where human contact is worth spending.
Should we still call payers?
For the cases the transaction cannot resolve, yes. A claim repeatedly reported in the same state, a dispute about what was received, an escalation — those need a person. What is worth changing is the order: ask electronically across the whole workable set first, then spend calls on what is left. Calling first caps the whole function at the size of the team, which is what most practices experience as not being able to get to all of it.
Can we read the status codes without a system that translates them?
The structure is readable — a status is reported as a category together with a more specific code, and the pairing carries the meaning, much as a group code and a reason code do on a remittance. The published wording of those codes is licensed material, so the practical route is your system's own translation of them rather than a table copied from a website, and that is also why no code text appears on this page.
Key terms in this article
Defined once, on their own pages.
Continue learning
The process it serves, and the layers either side of it.
Designing an A/R Follow-Up Process
The process this transaction is the backbone of — what enters the work, and who does it.
Reading Claim Submission Acknowledgments
The layer before this one: did the claim arrive at all, and did it pass the front-end checks?
Tracking a Claim: Status, Aging, and Follow-Up
What to do with the answers, one claim at a time.
What an A/R Aging Bucket Hides
Why the report that finds these claims cannot tell you which of them is which.
A/R & Follow-Up
The cluster: segmenting, working, and proving the receivable.
Authoritative sources
- 45 CFR § 162.1401 — Health care claim status transaction (opens in a new tab)
Defines the transaction as the transmission of either an inquiry from a health care provider to a health plan to determine the status of a health care claim, or a response from a health plan to a provider about that status.
- 45 CFR § 162.1402 — Standards for health care claim status transaction (opens in a new tab)
Adopts the ASC X12 Standards for Electronic Data Interchange Technical Report Type 3 — Health Care Claim Status Request and Response (276/277) — as the standard for the transaction, which is why its format is fixed rather than negotiated payer by payer.
- 45 CFR § 162.1403 — Operating rules for the health care claim status transaction (opens in a new tab)
Adopts CAQH CORE operating rules for the claim status transaction — adopted rules governing how the transaction operates, not only how it is formatted.