EDI 277 Claim Status Response and 277CA Guide

The EDI 277 tells a billing team what happened to a claim in a code they can route. It answers a 276 claim status request, and every claim in it carries an STC segment with a status category (finalized, pending, acknowledged, rejected) and a more specific status code. Read STC correctly and you know whether to wait for the 835, send records, fix and resubmit, or appeal.

This guide covers the 277's structure, the STC segment element by element, the most common category and status codes, the 277CA claim acknowledgment that shares the 277 number, a live example built from fictional data, and the mistakes teams make acting on 277s. It describes the X12 structure only; it is not legal, billing or compliance advice.

What Is an EDI 277?

An EDI 277 is the Health Care Claim Status Response transaction set defined by ASC X12, used by a health plan to report the status of claims a provider asked about. For HIPAA covered entities, 45 CFR 162.1402 adopts the X12 276/277 Technical Report Type 3 005010X212 (with its errata 005010X212E1) as the claim status standard. The 277 response carries 005010X212 in GS08 and ST03, and its functional group code in GS01 is HN.

Authoritative references for 277 work:

• The X12 005010X212 examples show a 277 answering three claims: one pending, one finalized, one denied at the line level
• X12 maintains the code lists the STC segment uses: the Claim Status Category Codes and the Claim Status Codes. Both are updated on a regular cycle, so load them from the source rather than hard-coding a copy
• HHS adopted CAQH CORE operating rules for the claim status transaction, listed in 45 CFR 162.920, with compliance from January 1, 2013 per CMS
• The 277CA has its own TR3, 005010X214, with examples on X12's 005010X214 page

Who sends it? The health plan, or its claims vendor. A 277CA can also come from a clearinghouse.

Who receives it? The information receiver named in the 276, usually the clearinghouse or billing service, which passes it to the provider.

When is it sent? In reply to each 276: real time or batch. A 277CA is sent after an 837 is received, without a request.

The 277 and the 277CA: Same Number, Different Jobs

Both are X12 277 transaction sets, but they follow different implementation guides and answer different questions.

The order on the claim side is: 837 sent, 999 back (file-level syntax), 277CA back (claim-level acceptance), then 835 or 277 later. A claim rejected on a 277CA never entered adjudication, so a 276 about it will usually come back "not found." Fix and resubmit it instead.

In the 277CA, STC03 also carries an action code: the X12 example uses WQ (accept) on accepted claims and U (reject) on rejected ones.

Interactive Example: 277 With a Paid Claim and a Pending Claim

The fictional health plan answers the fictional practice's 276 for two claims. JOHN SAMPLE's claim is finalized and paid: STC*F1:65 with the $285.00 charge, a $198.40 payment, the adjudication date, payment by ACH, the EFT effective date and an EFT trace number. JANE SAMPLE's claim is pending payer review: STC*P2:46 (internal review/audit). Both carry the payer's claim control number in REF*1K. Every name, ID and amount is fictional, and ISA15 is T (test).

Use the Plain English tab for a readable summary, or click any segment to break it down element by element.

277 Structure at a Glance

The 277 mirrors the 276 hierarchy (BHT01 = 0010) and adds status at each claim.

Key Segments Explained

TRN: Matching the Answer to the Question

TRN*2*SMPCLM1001~

TRN01 = 2 (referenced transaction trace number) and TRN02 is the trace you sent in the 276. Match each claim's status to your open claim on this value.

STC: Status Information

STC*F1:65*20261104**285*198.4*20261104*ACH*20261106*TESTEFT0001234~

STC01 is a composite, separated by the component separator from ISA16 (: in this sample). Read the category and the status code together. F2:88:QC in the X12 example means finalized/denial, "entity not eligible for benefits for submitted dates of service," and the entity is the patient (QC).

Claim Status Category Codes

Claim Status Codes You Will See Often

There are hundreds of status codes, and X12 adds, changes and retires them on its maintenance cycle. Load the current list from X12 rather than freezing a table in your code.

REF: The Payer's Claim Number

REF*1K*TESTPCN0000001~
REF*EJ*SMPCLM1001~

REF*1K is the payer's claim control number. Save it on the claim: it is the best key for future 276s, appeals, corrected claims and phone calls. REF*EJ echoes your patient control number.

SVC: Line-Level Status

SVC*HC:99203*150*0****1~
STC*F2:88:QC*20050612~

When a payer reports status by line, each 2220 loop starts with SVC (procedure composite, line charge, line payment) and carries its own STC. The X12 example above shows a line that was billed at $150, paid $0, and denied with the same reason as the claim.

Where the 277 Sits in the Claim Cycle

1. Provider sends the 837 claim.
2. Clearinghouse or payer returns a 999 for the file and a 277CA for each claim.
3. Provider sends a 276 for claims still open after the expected window.
4. Payer returns the 277 with STC status for each claim.
5. Payer sends the 835 with payment and adjustment detail for finalized claims.

Eligibility problems that show up as F2 denials, such as status code 88, are cheaper to catch earlier with a 270 and 271, and services that need authorization go through the 278 before the visit.

Common 277 Errors and How to Prevent Them

277 Implementation Checklist

• Accept GS01 = HN groups with 005010X212 and, if you receive them, 005010X214 for 277CAs
• Route 277 and 277CA to different queues: status follow-up versus intake rejections
• Parse STC01, STC10 and STC11 composites at claim and line level
• Match on TRN02, and store REF*1K
• Load current claim status category and status codes from X12
• Map each category to a work queue: wait, fix and resubmit, send records, appeal, post
• Keep the raw 277 with the claim for audit
• Test finalized-paid, finalized-denied, pending, not-found and 277CA reject scenarios

For an introduction to X12 structure, see our essential guide to EDI, and for the other transaction sets, the EDI document types reference.

Where OrderSync Fits

OrderSync's product is built for supplier order flows: it reads inbound purchase orders in any format (EDI 850 and 875, PDF, email, spreadsheets), matches customers, items and units, and outputs ERP data or valid X12.

For healthcare EDI teams, the useful piece is the free EDI inspector, which parses any X12 file, 277s and 277CAs included. Paste a test file to see each claim's STC status explained in plain English, segment by segment. Follow your organization's policies on protected health information before pasting a production file; test files with fictional data work just as well for checking structure.

Frequently Asked Questions