Every claim a practice submits, every eligibility check it runs, and every electronic remittance it posts travels as an X12 EDI transaction, usually through a clearinghouse. Clinicians never see these files, and billers see only the practice management system's view of them, but the EMR administrator is often the person called when a batch of claims disappears or an eligibility check returns nothing. This guide explains the standard transactions, how the clearinghouse connection is built, and where to look when something breaks.
Why these transactions are standardized
The HIPAA Administrative Simplification provisions required HHS to adopt standard formats for common healthcare administrative transactions so that a provider could exchange them with any payer without a custom format for each. The adopted standards, codified in 45 CFR Part 162, are the ASC X12N transaction sets, currently in version 5010, plus the NCPDP standards for pharmacy. Covered entities that conduct these transactions electronically must use the standards; payers may not refuse a compliant standard transaction.
Standardization is why a clearinghouse can exist. The clearinghouse accepts one format from the practice, validates it, and forwards it to hundreds of payers, translating connection details and companion-guide quirks along the way. Most practices connect only to the clearinghouse and let it handle the payer side.
The transactions and what each carries
| Transaction | Direction | What it carries |
|---|---|---|
| 270 / 271 | Provider to payer, response back | Eligibility and benefits inquiry (270) and response (271): coverage status, copay, deductible, plan details |
| 837P / 837I | Provider to payer | Professional (P) and institutional (I) claims; also used for encounter reporting |
| 276 / 277 | Provider to payer, response back | Claim status inquiry (276) and response (277) |
| 277CA | Payer or clearinghouse to provider | Claim acknowledgment: accepted or rejected at the front end, before adjudication |
| 835 | Payer to provider | Electronic remittance advice: payments, adjustments, and denial reason codes for posting |
| 278 | Provider to payer, response back | Referral and prior authorization request and response |
| 999 / TA1 | Receiver to sender | Functional and interchange acknowledgments: did the file itself parse |
The 837 is the transaction administrators encounter most, because claim rejections are where the phone rings. It is a hierarchical file with loops for billing provider, subscriber, patient, claim, and service line, and a single missing element in the wrong loop can reject an entire batch. The 835 is the second most important, because remittance posting depends on the claim control numbers in the 835 matching the ones sent on the 837.
How the connection to the clearinghouse works
The practice management or EMR system generates the X12 file and transmits it to the clearinghouse over a secured connection. The most common methods are SFTP with key or password authentication, a vendor-specific web service or API, or a real-time connection for 270/271 and 276/277 where a response is expected within seconds. Batch transactions such as 837 and 835 typically move on a schedule, several times a day.
The clearinghouse runs its own edits on the incoming file, returns a 999 to say whether the file parsed and a 277CA or proprietary report to say which claims passed its scrubber, then forwards accepted claims to the payer. The payer returns its own 277CA, and later an 835, which the clearinghouse passes back to the practice for download and posting. Each hop has its own acknowledgment, and knowing which hop produced a rejection is the first step in fixing it.
Security note: the clearinghouse is a business associate. The connection credentials, the SFTP host key, and the IP allow list are all items that belong in the practice's asset inventory and risk analysis, and credentials should be rotated when staff who knew them leave.
Acknowledgments: 999, 277CA, and where claims get stuck
A claim can stop in four places, and each produces a different signal. If the file itself is malformed, the receiver returns a 999 rejection or a TA1, and nothing in the batch was processed. If the file parsed but individual claims failed the clearinghouse edits, the clearinghouse report or 277CA lists them by patient control number with a reason. If the clearinghouse accepted the claims but the payer's front end rejected them, the payer's 277CA arrives a day or two later with the payer's reason codes. And if the payer accepted the claim into adjudication and then denied it, the denial appears on the 835 with claim adjustment reason codes and remark codes.
Only the last of these is a true denial. The first three are rejections, and rejected claims are invisible to the payer for timely filing purposes. Administrators should make sure the practice management system imports every acknowledgment and surfaces rejections in a work queue, because a rejection that lands only in an SFTP folder nobody opens will age silently until the filing window closes.
Setup and enrollment tasks for the administrator
- Payer enrollment. Many payers require enrollment before they will accept electronic claims or send 835 remittances for a given provider and clearinghouse. Enrollment forms, sometimes with signatures, are managed through the clearinghouse and can take weeks. Track them by payer ID.
- Submitter IDs and payer IDs. The practice's submitter ID with the clearinghouse and the clearinghouse's payer ID for each insurer must be entered correctly in the practice management system. A wrong payer ID sends claims to the wrong insurer or into a black hole.
- Provider identifiers. Billing NPI, rendering NPI, taxonomy code, and tax ID must match what the payer has on file. Mismatches are the single most common cause of front-end rejections after an enrollment change.
- Connection credentials. SFTP account, keys, and any IP allow-listing on both sides. Document them in a secure location, not in a spreadsheet on a shared drive.
- File paths and schedules. Where outbound files are placed, where inbound acknowledgments and 835s are picked up, and how often the system polls. Confirm that the 835 auto-import is enabled and that the posting user reviews unposted remittances.
- Test transactions. Before going live with a new clearinghouse or a new practice management system, send test 837s and 270s and confirm acknowledgments return and are imported correctly.
Troubleshooting common failures
- Entire batch rejected with a 999. Usually a structural problem introduced by a recent system update or a corrupted file. Check the 999 error segment for the offending loop, re-generate the batch, and open a vendor ticket if it recurs.
- Eligibility returns nothing or times out. Real-time 270/271 depends on the payer's real-time gateway being up. Check the clearinghouse status page, then confirm the payer ID configured for eligibility matches the one for claims; some payers use different IDs.
- 835 files arrive but do not post. Almost always a claim control number mismatch or a payer sending remittances for a tax ID the system does not recognize. Compare the 835 claim identifier to the 837 patient control number and confirm enrollment was completed for the correct entity.
- Claims accepted by the clearinghouse but rejected by the payer. Read the payer's 277CA reason codes; the most frequent culprits are provider identifier mismatches, invalid member IDs, and missing referring provider information for services that require it.
- Sudden spike in rejections after an upgrade. Compare a rejected 837 to one from before the upgrade. Vendors occasionally change default values or loop population; the diff will show it.
Keeping a short runbook of these scenarios, with the specific screens and file locations for the practice's own systems, turns a stressful morning into a fifteen-minute fix. The transactions themselves rarely change. What changes is the configuration around them, and that is the administrator's domain.
Common questions
What is the difference between a claim rejection and a claim denial?
A rejection happens before adjudication, at the clearinghouse or payer front end, because the claim failed a format or identifier edit; the payer never processed it. A denial comes after adjudication and appears on the 835 with reason codes. Rejected claims do not count as filed for timely filing purposes.
Does a practice have to use a clearinghouse?
No. A practice can connect directly to payers that offer direct submission, but each direct connection requires its own enrollment, credentials, and companion guide. Most practices find a clearinghouse simpler and less expensive to maintain.
Which X12 version is currently required under HIPAA?
Version 005010 (5010) of the ASC X12N transaction sets is the adopted standard in 45 CFR Part 162. HHS has proposed newer versions in the past; check the current regulation for the adopted version.
Why do 835 remittances fail to post automatically?
Most often because the claim control number on the 835 does not match the patient control number sent on the 837, or because the remittance is for a tax ID or NPI the practice management system does not have configured. Enrollment errors are the usual root cause.