EDI Transaction Map: 837, 835, 270, 271, 277CA, and 999

Electronic data interchange, or EDI, allows providers, clearinghouses, and payers to exchange standardized health care transactions. For CBCS billing and reimbursement, the most important EDI concept is that different transactions serve different purposes in the revenue cycle. A claim submission is not the same as a remittance advice. An eligibility response is not the same as a guarantee of payment. An acknowledgment is not the same as adjudication.

Key Concepts

Understanding that map helps a billing specialist know where a claim is in the process and what action to take next. The 837 transaction is the electronic health care claim.

It carries claim data from a provider or clearinghouse to a payer. There are different versions by claim type. The 837P is used for professional claims and generally corresponds to CMS-1500 claim logic. The 837I is used for institutional claims and generally corresponds to UB-04 claim logic. The 837D is used for dental claims. The 837 includes patient, subscriber, payer, provider, diagnosis, procedure, charge, unit, date, authorization, and coordination of benefits data as required by the claim type.

In daily billing, staff may not see raw EDI segments, because the practice management system or clearinghouse translates screen fields into an 837 file. Still, errors in ordinary claim fields become EDI problems when required loops, segments, or data elements are missing or inconsistent. The 835 transaction is the electronic remittance advice. It reports how the payer adjudicated claims and usually accompanies or supports electronic funds transfer.

The 835 includes payment amounts, allowed amounts, contractual adjustments, denials, coinsurance, copay, deductible, payer control numbers, claim adjustment reason codes, remittance advice remark codes, and provider-level adjustments when applicable. Payment posting staff use the 835 to post payments and adjustments, transfer balances to secondary payers or patients, and identify denials needing follow-up. The 835 is not a claim submission transaction. It is the payer's response after adjudication or financial processing. The 270 and 271 transactions support eligibility and benefit verification.

A provider or clearinghouse sends a 270 eligibility inquiry to ask whether a patient has coverage and what benefits may apply. The payer returns a 271 eligibility response with coverage information, benefit status, plan details, copay or deductible information when available, and sometimes service-type limitations. The 271 is useful but not absolute. It can be incomplete, broad, or subject to change. It does not guarantee payment because payment still depends on correct claim submission, medical necessity, authorization, coverage rules, payer order, patient status, and benefits at adjudication.

Workflow and Documentation

The 276 and 277 transactions support claim status inquiry and response. A provider can send a 276 to ask about a claim's status, and the payer can return a 277 response. The 277CA, or claim acknowledgment, is especially important in electronic claim workflows. It reports whether claims were accepted or rejected at the payer or clearinghouse front end before full adjudication. A 277CA may show that a claim was accepted into the payer's system, rejected because a required data element was invalid, or accepted with warnings. A claim accepted on a 277CA still may later deny after adjudication.

A rejected claim usually needs correction and resubmission; it may not count as filed for timely filing. The 999 implementation acknowledgment reports whether an EDI file or transaction set was syntactically accepted, accepted with errors, or rejected based on implementation guide rules. It is more about EDI structure than clinical or benefit adjudication. For example, a 999 may reject an entire file if required loops or segments are invalid. The 277CA may then operate at claim or service-line acknowledgment level after front-end payer edits.

Some trading partners also use TA1 interchange acknowledgments for envelope-level problems.

CBCS candidates do not need to parse raw X12 loops, but they should understand that acknowledgments tell the biller whether the electronic message was received in a usable format and whether claims moved forward. The transaction map supports practical workflows. Before service, eligibility staff may send 270 inquiries and review 271 responses. After charge capture and claim creation, the system generates 837P or 837I files. The clearinghouse may run edits, send the file to the payer, and return acknowledgments such as 999 and 277CA. If a claim is rejected, billing staff correct the problem and resubmit.

Exam Application

If the claim is accepted, staff monitor adjudication and payment. After the payer processes the claim, the provider receives an 835 and posts payments, adjustments, denials, and patient responsibility. If payment is delayed, staff may use claim status tools or transactions to determine whether the claim is pending, denied, rejected, paid, or not on file. This sequence is central to Domain 4 because it connects electronic submission, payer edits, payment review, remittance interpretation, denials, resubmission, aging, and data analysis.

A strong CBCS candidate can explain the purpose of each transaction without confusing acceptance with payment.

High-Yield Checkpoints

• HIPAA EDI transactions standardize common revenue cycle exchanges between providers, clearinghouses, and payers.
• The 837 carries claim data, with 837P for professional claims, 837I for institutional claims, and 837D for dental claims.
• The 835 reports electronic remittance advice, including payment, adjustment, denial, and patient responsibility information.
• The 270 and 271 support eligibility inquiry and response, while the 276 and 277 support claim status inquiry and response.
• The 999 and 277CA help identify whether an EDI file or claim was syntactically accepted, rejected, or acknowledged before adjudication.