How to Read an ERA: Paid, Write-Offs, and What the Patient Owes

An ERA (Electronic Remittance Advice) is the file an insurance company sends a healthcare provider to explain a payment: which claims it covers, how much was paid on each, what was written off, and what the patient owes. Technically it is the HIPAA-standard X12 835 transaction — the provider-side twin of the EOB a patient gets in the mail. This guide walks through one real remit, line by line, in plain language.

Per the CAQH Index, 88% of medical remittances are now fully electronic, and each electronic remittance costs about $3.00 less to process than a manual one. But an ERA only saves money if your team can actually read it — and that is where most billing problems hide.

Watch: How to Read an 835 ERA: Billed vs Paid vs Adjusted, Explained for Engineers (9:29).

ERA vs EOB: Same Claim, Two Documents

When a payer processes a claim, it produces two versions of the same decision:

• EOB (Explanation of Benefits) — the human-readable summary mailed or portal-posted to the patient. It is not a bill.
• ERA (835 file) — the structured electronic file sent to the provider. Billing software posts it automatically instead of a person keying numbers from paper.

Same claim, same dollars — different audience and format. If your practice still posts from paper EOBs, every payment costs more to process and takes days longer to reconcile.

The Four Numbers That Matter on Every Remit

Every claim line on an ERA reconciles four numbers. Get these four straight and the rest of the file makes sense:

1. Billed amount — what you charged.
2. Allowed amount — what the payer's contract says the service is worth. This is the ceiling: payer payment + patient responsibility can never exceed it.
3. Paid amount — what the payer actually sent.
4. Patient responsibility — the deductible, copay, or coinsurance the patient owes you directly.

A worked example

The math always closes: Billed = Paid + Patient responsibility + Adjustments ($200 = $120 + $30 + $50), and Allowed = Paid + Patient responsibility ($150 = $120 + $30). If a line doesn't reconcile, something is wrong — and it's usually the adjustment handling.

Reading a Real Remit, Line by Line

Here is what those same numbers look like inside the actual 835 file your clearinghouse delivers. You don't need to be a developer — three segments carry almost everything:

1. The payer header — who paid you and how

BPR*I*146.89*C*ACH*...*20260824~
TRN*1*1512345678*1999999999~

BPR is the money summary: total payment amount, payment method (ACH, check), and the effective date. TRN is the trace number — the same number that appears on your bank deposit, which is how you match the file to the money.

2. The claim line — one line per claim

CLP*ACCT-2001*1*200*120*30*12*...~

Reading left to right: your account number, the claim status (1 = processed as primary; 4 = denied; 22 = reversal), billed $200, paid $120, patient owes $30. One segment tells you the outcome of the whole claim.

3. The adjustments — every dollar that wasn't paid, and why

CAS*CO*45*50~
CAS*PR*1*30~

Each CAS line pairs a group code (who absorbs the money) with a reason code (why). These two lines say: $50 is a contractual write-off because the charge exceeded the fee schedule (CO-45), and $30 is the patient's deductible (PR-1).

The group codes, in plain words

The full group-code definitions live on the official X12 code list. The most common trap we see: treating OA and PI amounts like CO and silently writing off money that should have been appealed.

Contractual Adjustments: What You Can Never Bill the Patient

The contractual adjustment (usually reason code CO-45) is the difference between your charge and the contracted rate. If you are in-network, you agreed to this discount when you signed the payer contract — billing the patient for it is balance billing, and it is not allowed. On most remits, CO-45 is the single largest adjustment, and it is completely normal. In an analysis we ran across roughly 1,800 claims for a behavioral-health group, contractual write-offs were by far the most frequent adjustment on the file — expected, boring, and correct. The dangerous lines are the unusual ones next to them.

When the ERA Shows a Denial

A denied claim arrives with status 4 in the CLP segment and $0.00 paid. The reason lives in the CAS line:

CLP*ACCT-2002*4*150*0*0*12*...~
CAS*CO*29*150~

That is a timely-filing denial (CO-29): the claim arrived after the payer's deadline, the full $150 is coded CO — meaning you cannot bill the patient, and the money is simply lost unless you can prove timely submission. Denials each have their own reason code; our guide to the most common denial codes covers what each one means and whether you can fight it.

The ERA is also the yardstick for patient cost estimates: our guide to Good Faith Estimate software shows how to compare estimates with the adjudicated result.

Posting an ERA: A 5-Step Checklist

1. Match the deposit. The BPR total and TRN trace number must match a bank deposit before anything posts.
2. Reconcile every claim line. Billed = paid + patient + adjustments, line by line.
3. Post CO amounts as write-offs. Automatically, no review needed for standard contractual codes.
4. Move PR amounts to patient balances. This drives the patient statement — get it wrong and you either over-bill patients or leak revenue.
5. Flag OA, PI, and every denial for a human. These are the lines where money is recoverable.

This is also where software earns its keep: a correctly built posting engine applies these rules to every line automatically and routes only the exceptions to your team. We have seen billing systems compute “remaining balance” as simply billed minus paid — ignoring the CAS adjustments entirely — which silently overstates what patients owe on every single claim. If your patient balances look inflated, this formula is the first thing to check.

Try it on a real remit: our free EDI Inspector decodes any ERA line by line — the plain-English mode narrates every segment exactly like this guide.

If your team is posting remits by hand, or your system's numbers don't reconcile, our revenue cycle management software development team builds and fixes exactly this layer — from 835 parsing to posting rules to denial routing. Talk to our team about a quick review of your remit-posting pipeline.