A 276 · Claim Status Inquiry asks a payer what happened to a claim that was already submitted, and the 277 · Claim Status Response is the payer's answer — pending, paid, denied, or needing more information, with the category and reason codes that explain why. It is the transaction that replaces the phone call, the portal hunt, and the "we have no record of that" dead end.
I run SignalEDI. This series has walked the healthcare chain in order: the 270 · Eligibility Inquiry / 271 · Eligibility Response that checks coverage before care, the 837 · Claim that asks for payment, and the 835 · Healthcare Benefit Payment / Remittance Advice that explains a payment after it is made. The 276/277 sits between the 837 and the 835. A claim has gone out, no remittance has come back yet, and somebody — usually a biller staring at an aging report — needs to know where it stands.
What is a 276 · Claim Status Inquiry and a 277 · Claim Status Response?
The 276 is the question. It identifies the claim — by the payer's claim number if you have it, or by the combination of provider, patient, dates of service, and charged amount if you do not — and asks for its current status. The 277 is the answer: a status category that says where the claim is in the payer's process, and, when something is wrong, status codes that say what is wrong and who has to fix it.
Like the 270/271 pair, 276/277 is designed to work in near real time as well as in batch. A single inquiry from a billing screen and a nightly sweep across every claim older than a chosen threshold are the same transaction used at different scales. The second use is where most of the money is, because it turns status checking from a reaction into a routine.
Why do claims disappear into a black hole?
Because submission is not receipt, and receipt is not acceptance. A claim can be received by a clearinghouse and rejected before it ever reaches the payer. It can reach the payer and pend for review. It can be denied for a reason that was knowable before submission. In each case, silence looks identical from the sender's side: nothing has come back.
Teams without a status routine fill that silence with labor. They wait a fixed number of days, then call, or log into one payer portal at a time, or — worst of all — rebill the claim blind, which creates a duplicate that slows down the original. The 276 exists precisely to replace that guessing with a dated, coded answer, early enough that the fix is still cheap.
What does a good 277 actually tell you — and what does it not?
A useful response separates two things that are often collapsed into one vague "denied." The status category tells you the stage: is the claim received, pending, finalized, or returned for information? The finer status codes then tell you the reason at the level of the claim or the individual service line — a missing element, an authorization problem, a coding issue, information requested from the provider or the patient.
What it does not tell you is the payment detail. That is the 835's job, once a claim is finalized and paid. The 277 is a status report, not a remittance. Confusing the two leads teams to post payments from a status response, or to ignore a status response because "no money moved." Both are errors. The 277's value is time: it tells you today what the 835 would otherwise reveal weeks from now, when the timely-filing clock has much less slack.
Where do 276/277 workflows usually break?
The first break is asking too late. If the first status check happens at day 45, a claim rejected on day 2 has already lost six weeks of its filing window. Mature workflows ask on a schedule keyed to the payer's normal processing time — early enough to catch a rejection while it is still a correction, not an appeal.
The second break is asking without the identifiers that make an answer possible. A status inquiry that cannot be matched to a claim comes back as not found, which teams misread as "the payer lost it." Usually the match failed on data the sender controlled: a claim number transcribed wrong, a date of service that differs from the 837 as submitted. Capture the identifiers from the claim as sent, not from a re-keyed summary.
The third break is receiving the answer and doing nothing structured with it. If a 277 lands as a note in a queue with no owner, no category, and no next step, the black hole has simply moved inside your own system. Route by category: rejections to correction, information requests to whoever holds the document, denials to appeal review — and record the response with the claim, because "we checked on this date and the payer said this" is evidence in every later dispute.
Frequently asked questions
Is a 276/277 the same as an eligibility check?
No. The 270 · Eligibility Inquiry / 271 · Eligibility Response asks about coverage before or around care. The 276/277 asks about a specific claim that was already submitted on an 837 · Claim.
How is a 277 different from an 835?
The 277 · Claim Status Response reports where a claim stands and what is wrong with it. The 835 · Healthcare Benefit Payment / Remittance Advice reports a finalized payment — amounts paid, adjusted, and owed. Status comes first; remittance closes the loop.
Can one 276 ask about more than one claim?
Yes — inquiries can be batched, and a nightly sweep across many aging claims is a common pattern. The discipline is in reading and routing each response per claim, not treating the batch as one answer.
The pattern across this series holds here too: each EDI document answers exactly one question well. The 276 asks it and the 277 answers it — "what happened to the claim we already sent, and what has to happen next?" Asking early, with the right identifiers, and routing the answer to an owner is the discipline we build SignalEDI around.
— Chris, founder of SignalEDI
