What the 277CA is
The 277CA is the X12 Health Care Claim Acknowledgment, implementation guide 005010X214. A payer, a clearinghouse, or CMS returns one after you send an 837, and it reports on every claim in the file: accepted for adjudication, or rejected before adjudication ever started.
Nobody asks for a 277CA. It is unsolicited, triggered by the submission itself, and it is the first response in the chain that talks about individual claims rather than about the file they arrived in.
For Medicare Advantage encounter data the 277CA comes from the CMS Encounter Data Front-End System (EDFES). Files that clear the front end pass to the Encounter Data Processing System (EDPS), which returns the MAO-001 duplicates report, the MAO-002 processing status report, and the MAO-004 diagnosis filtering report. A claim rejected on the 277CA reaches none of them.
Where the 277CA sits: 837, 999, 277CA
One 837 submission produces three acknowledgments, and each answers a different question.
- TA1, the interchange acknowledgment. Did the envelope parse? ISA and GS segment problems surface here, and a bad envelope stops everything behind it.
- 999, the implementation acknowledgment. Does the file meet the syntax and structure rules of the implementation guide? A file that fails the 999 never reaches claim-level editing.
- 277CA, the claim acknowledgment. For each claim inside a file that passed the 999, was it accepted or rejected at pre-adjudication?
The sequence matters because of what a clean response actually proves. A clean 999 proves the file was well formed. It tells you nothing about any individual claim. A submitter who checks the 999 and moves on is reading a receipt for the envelope and calling it proof of delivery.
Accepted or rejected, before adjudication
Status lives in the STC segment, and the 277CA reports it at two levels. The patient level (loop 2000D) is where a member ID or demographic mismatch lands. The claim level (loop 2200D) is where the claim data itself fails. The distinction is the fastest triage you get: a wall of 2000D rejections is an eligibility or enrollment problem, not a coding problem.
Every STC carries a claim status category code, which is the verdict, plus one or more claim status codes that explain it. The category codes come from X12 external code list 507.
| Category code | X12 description | What it means for you |
|---|---|---|
| A0 | Acknowledgement/Forwarded | The claim went to another entity. Not a decision. |
| A1 | Acknowledgement/Receipt. Does not mean the claim has been accepted for adjudication. | Received. Nothing more. |
| A2 | Acknowledgement/Acceptance into adjudication system | The claim is in. This is the only accept verdict. |
| A3 | Acknowledgement/Returned as unprocessable claim. Rejected and not entered into the adjudication system. | Fix and resubmit. The claim does not exist downstream. |
| A4 | Acknowledgement/Not Found | The claim cannot be located in the adjudication system. |
| A5 | Acknowledgement/Split Claim | The claim was split on acceptance. Expect more than one downstream record. |
| A6 | Acknowledgement/Rejected for Missing Information | Something required is absent. The status code names it. |
| A7 | Acknowledgement/Rejected for Invalid Information | Something present is wrong. |
| A8 | Acknowledgement/Rejected for relational field in error | Two fields that have to agree do not. |
A2 is the accept. A1 is a receipt and X12 spells out that it does not mean acceptance, which is the single most common misread of a 277CA. Everything from A3 down is work.
Common 277CA rejection codes
The category code says the claim was rejected. The claim status code, from X12 external code list 508, says what was wrong. The NM1 segment paired with the STC names the entity at fault: QC for the patient, IL for the subscriber, 82 for the rendering provider, 85 for the billing provider.
| Status code | X12 description | Usual cause |
|---|---|---|
| 21 | Missing or invalid information | A container code. X12 requires at least one other status code with it to identify what is missing. |
| 33 | Subscriber and subscriber id not found | Member ID, name, or date of birth does not match the payer's enrollment record for that date of service. |
| 116 | Claim submitted to incorrect payer | Wrong payer ID, or the member moved to another plan mid-period. |
| 145 | Entity's specialty/taxonomy code | Taxonomy missing or not valid for the entity named in the paired NM1. |
| 187 | Date(s) of service | Service date outside coverage, in the future, or inconsistent with the statement dates. |
| 500 | Entity's Postal/Zip Code | A nine-digit ZIP is required for the service facility or billing address and a five-digit one was sent. |
| 562 | Entity's National Provider Identifier (NPI) | NPI missing, invalid, or not on file with that payer for the entity in the NM1. |
Codes 145, 500, and 562 all require an entity code, which is why a report that counts "562" without the NM1 is not actionable. A3/562/85 is a billing provider NPI problem and A3/562/82 is a rendering provider NPI problem. Those are different fixes, usually owned by different people.
Why encounter teams have to work 277CA rejects
A rejected encounter never reaches the EDPS. No MAO-002 line, no MAO-004 line, no diagnosis eligible for risk adjustment. CMS calculates the member's risk score as though the visit did not happen.
The loss is silent. Nothing is denied, no remittance arrives, and no revenue-cycle metric moves, because an encounter is not a payment claim. The only record of it is a file most teams treat as a log rather than a queue.
This is a documented gap, not a hypothetical one. The HHS Office of Inspector General reported that CMS had not tracked whether Medicare Advantage organizations respond when the submission process rejects their data, and a follow-on review found ordering provider NPIs missing from 63 percent of MA encounter records for durable medical equipment, laboratory, imaging, and home health services.
There is also a hard clock. A diagnosis counts only if its encounter is accepted before the risk adjustment data submission deadline for that payment year. The PY2027 initial run closes September 4, 2026, and the PY2026 final run closes February 1, 2027. After a final deadline CMS processes deletes only, so a late correction can lower a risk score but can never raise one, under 42 CFR 422.310(g).
277CA vs 277 vs 999
Three transactions share overlapping names and answer completely different questions. Mixing them up is how a team ends up certain that claims landed when they did not.
| 999 | 277CA | 277 (paired with 276) | |
|---|---|---|---|
| What triggers it | You submitted a file | You submitted an 837 | You sent a 276 status inquiry |
| Solicited? | No | No | Yes |
| What it reports | File syntax and structure against the implementation guide | Accept or reject for each claim, before adjudication | Where a claim already in the system stands |
| Level | File and transaction set | Patient and claim | Claim and service line |
| Guide version | 005010 implementation acknowledgment | 005010X214 | 005010X212 |
X12 is strict about the pairing: a 276 in version 005010X212 is always answered by the matching 277 in that version, and the 277CA is never used to answer a 276. A third transaction adds to the confusion. The 277RFAI is a payer's request for additional information on a claim it has already taken in, which is the opposite situation from a 277CA rejection.
Common mistakes with the 277CA
- Treating a clean 999 as proof the claims landed. The 999 clears the file. Claims are cleared one at a time on the 277CA.
- Counting rejections without the entity code. Status codes 145, 500, and 562 mean nothing until you read the NM1 that goes with them.
- Working encounter rejects out of the revenue cycle queue. That queue is usually sorted by expected payment, and an encounter reject has no dollar attached, so it sinks to the bottom and stays there.
- Resending the same file. A rejected claim has to be corrected first. A straight resubmission earns the same rejection or a duplicate.
- Reading the file monthly. The 277CA usually comes back the same day or the next one. Batching it into a monthly reconciliation throws away the one advantage it has, which is speed.
- Assuming A2 means the diagnosis counts. Acceptance into the encounter system is not risk-adjustment eligibility. That verdict comes later, on the MAO-004.
How Pelica handles 277CA rejections
Pelica's Risk Adjustment Copilot follows every submitted encounter through the whole chain on one record: the 999, the 277CA, the MAO-002, the MAO-004, and on to the MMR and MOR. Rejections are grouped by status code, entity, and source system, so a taxonomy problem that shows up on one EHR feed reads as one fix instead of four hundred tickets. Each reject carries its own submission-deadline clock, and the ones that still have recoverable revenue behind them sort to the top. Plans and IPAs run this across 350,000+ members, and a new deployment is live in two weeks.
Related terms
MAO-004 is the next file in the chain: it tells you which diagnoses on accepted encounters are eligible for risk adjustment. RAPS vs EDPS explains why this acknowledgment chain exists at all and what replaced it. MMR reports the per-member payment CMS is actually making, and MOR details the HCCs behind each member's score.
Sources
- X12: Claim Status Category Codes (external code list 507)
- X12: Claim Status Codes (external code list 508)
- CMS: Acknowledgement Transactions (TA1, 999, 277CA)
- CSSC Operations: 277CA Acknowledgement Report resource guide
- HHS OIG: Medicare Advantage Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (2018)
- HHS OIG: CMS's Encounter Data Lack Essential Information That Medicare Advantage Organizations Have the Ability To Collect (2020)
- CMS HPMS memo: Deadline for Submitting Risk Adjustment Data for Payment Years 2025, 2026, and 2027 (April 28, 2025)
- eCFR: 42 CFR 422.310, Risk adjustment data