837P vs 835 Explained: What Each EDI File Does

If you work in medical billing, these four numbers describe your entire revenue pipeline. The 837 goes out with your claims; the 835 comes back with your money and your denials. Understanding what each file does — and what can go wrong with each — is foundational to running a clean operation.

The 837P: claims going out

The 837P (P = Professional) is the HIPAA-mandated electronic format for physician and supplier claims — the electronic equivalent of the paper CMS-1500 form. The current version is 005010X222A1. Each file contains one or more claims, and each claim carries structured "loops" of data: the billing provider, the rendering provider, the patient/subscriber, diagnoses (ICD-10), procedures (CPT/HCPCS), charges, and dates of service.

Its sibling, the 837I (Institutional), serves hospitals and facilities — the electronic UB-04. Same transaction family, different data loops suited to facility billing.

Key facts about the 837P:

Direction: provider (or clearinghouse) → payer.
Control numbers (in the ISA/GS/ST envelopes) uniquely identify each file and must increment — duplicate control numbers cause rejections.
Balancing matters: line-item charges must sum to the claim total, and the transaction trailer counts must match the actual segments — structural errors here get the whole file rejected.
Most practices send 837s through a clearinghouse, which validates and forwards them to each payer.

The 835: payment answers coming back

The 835 is the Electronic Remittance Advice (ERA) — the payer's itemized response to your claims. For every claim it reports: amount paid, adjustments, and the reason for each adjustment via Claim Adjustment Reason Codes (CARCs) with Remittance Advice Remark Codes (RARCs) adding detail. This is where denials arrive (see our guide to the 7 most common denial reasons) and where your appeal workflow begins (see how to appeal a denied claim).

Direction: payer → provider.
Drives payment posting — matching each payment and adjustment to the right claim and line.
A single 835 can cover many claims and include both payments and zero-pay (denied) lines.

The acknowledgments: 999 and 277CA

Between the 837 going out and the 835 coming back, two acknowledgment files tell you whether your claims actually made it in:

File	Full name	What it tells you
999	Functional Acknowledgment	Whether the 837 file's structure was valid — accepted, accepted with errors, or rejected. A rejected 999 means fix the file and resend.
277CA	Claim Acknowledgment	Per-claim status: accepted into the payer's adjudication system or rejected up front, with reason codes. This is your proof the payer received each claim.

The 277CA deserves special attention: it is your proof of timely submission. If a payer later denies for timely filing, the 277CA showing receipt within the window is your appeal evidence. Keep every acknowledgment.

How they fit together

1You build the 837P — claims are created, scrubbed for errors, and batched.

2Transmit to the payer — directly or via clearinghouse (SFTP, API, or manual upload).

3999 arrives — confirms the file was structurally readable.

4277CA arrives — confirms each claim entered adjudication (or was rejected, with reasons).

5835 arrives — payment and denial detail per claim. Post payments, work denials.

What goes wrong (and how to catch it)

File rejected at the 999: structural errors — bad control numbers, segment count mismatches, invalid envelopes. Fix and resend the batch.
Claims rejected at the 277CA: front-end rejections (bad member ID, provider not enrolled). These never entered adjudication — fix and resubmit quickly; the timely-filing clock is running.
835 never arrives: the claim may be stuck. Follow up with the payer using the claim's trace numbers.
835 adjustments you don't understand: look up the CARC/RARC combination — the codes are standardized precisely so you don't have to guess.

Inside the 837P: the loops that matter

An 837P file is organized into hierarchical "loops," each carrying a specific data set. You don't need to memorize them, but knowing the structure helps when debugging rejections:

1000A / 1000B: submitter and receiver identification — who sent the file and who it's for.
2010AA: billing provider — name, NPI, address, taxonomy. A mismatch here against the payer's enrollment records causes front-end rejections.
2010BA / 2010CA: subscriber (policyholder) and patient — member IDs, demographics. Most eligibility-related 277CA rejections trace to these loops.
2300: claim information — dates, place of service, diagnosis codes, claim amounts, prior authorization numbers.
2400: service lines — each CPT/HCPCS line with its own diagnosis pointers, modifiers, charges, and rendering provider.
SE trailer: segment counts that must exactly match the file contents — a common source of 999 rejections when hand-built files miscount.

Common 999 rejections and what they mean

When the 999 comes back rejected, the problem is structural, not clinical. The usual suspects:

Duplicate control numbers: the ISA13/GS06/ST02 identifiers must be unique per file. Resending a file with the same numbers looks like a duplicate submission.
Segment count mismatch: the SE trailer's count doesn't match the actual segments — often from a file builder bug.
Invalid envelopes: wrong sender/receiver IDs in the ISA segment, so the payer's system can't route the file.
Version mismatch: the GS08 version identifier doesn't match what the payer expects (should be 005010X222A1 for 837P).

None of these involve medical judgment — they're plumbing. Fix the file generation and resend; the timely-filing clock is running from the date of service, not from when you get the plumbing right.

Reading an 835: payment posting basics

When the 835 arrives, each claim line carries the financial outcome in a standard structure worth understanding:

Paid amount vs. billed amount: the difference is explained by the adjustment codes that follow — never just "the payer short-paid us."
Adjustment group codes: CO (contractual obligation — you absorb it), PR (patient responsibility — billable to the patient), OA (other adjustments). Posting to the wrong bucket creates compliance problems.
CARC + RARC pairs: the reason code plus the remark code is the complete story. Post both to the claim record — your denial analytics depend on it.
Zero-pay lines: a line with $0 paid and a CARC is a denial, not a pending claim. Route it to the denial workflow immediately — see how to appeal.

Clean payment posting is what turns the 835 from a confusing file into the data source your whole revenue cycle runs on.

Illustration of electronic healthcare data exchange

One file sends claims out. The other brings payment answers back. Know both, and the revenue cycle stops being a black box.

Frequently asked questions

What is an 837P file?

The 837P is the standard electronic format for submitting professional (physician/supplier) healthcare claims to payers. The current HIPAA-mandated version is 005010X222A1. It carries patient, provider, diagnosis, procedure, and charge data for each claim.

What is an 835 file?

The 835 is the Electronic Remittance Advice (ERA) — the payer's electronic response to your claims. It reports what was paid, what was denied, and why, using Claim Adjustment Reason Codes (CARCs) and Remittance Advice Remark Codes (RARCs).

What is the difference between 837P and 837I?

The 837P is for professional claims (physicians, suppliers, clinics billing on the CMS-1500/837P format). The 837I is for institutional claims (hospitals, facilities billing on the UB-04/837I format). They carry different data loops suited to each claim type.

What is a 277CA acknowledgment?

The 277CA (Claim Acknowledgment) is the payer's confirmation that your 837 claim file was received and whether each claim was accepted into adjudication or rejected up front. It is your proof of timely submission — keep it for every batch.