The ERA tells you what happened. Somebody still has to read it.
Electronic remittance advice is the payer's line-by-line explanation of how it adjudicated your claims — what it allowed, what it paid, and why the rest went missing. Auto-posting makes the money appear without anyone looking at the reasons, which is efficient right up to the point where it is expensive.
An ERA is the HIPAA-standard 835 transaction: a structured electronic file the payer sends the provider after adjudicating a batch of claims. It is the counterpart to the 837 claim you submitted, and it is machine-readable, which is what makes automatic payment posting possible.
ERA is not EOB
They describe the same adjudication and go to different people.
| ERA (835) | EOB | |
|---|---|---|
| Sent to | The provider | The member |
| Format | Structured electronic file | Human-readable statement |
| Purpose | Payment posting and reconciliation | Explaining member responsibility |
| Detail | Adjustment codes per line | Summarised |
Clients frequently bring an EOB to a session convinced they have been billed for something they should not have been. The ERA is what lets you tell them what actually happened.
What is in an ERA line
- Billed amount — what you charged.
- Allowed amount — the contracted rate for that code under that plan.
- Paid amount — what the payer sent.
- Patient responsibility — copay, coinsurance or deductible.
- Adjustments, each with a code and an amount.
Billed minus allowed is the contractual adjustment — the discount you agreed to as a participating provider, which is written off rather than billed to the client. Confusing that write-off with a denial, or billing it to the client, is the most consequential misreading of an ERA and in most contracts a violation.
CARC and RARC
Two code sets carry the reasons.
CARC — Claim Adjustment Reason Codes — say why an amount was adjusted, prefixed
by a group code: CO for contractual obligation (provider absorbs), PR for
patient responsibility (bill the client), OA for other adjustment, PI for
payer-initiated.
That prefix matters more than the number. CO means write it off; PR
means bill the client. Getting this backwards either loses money or bills clients for amounts they
do not owe.
| Code | Meaning | Action |
|---|---|---|
| CO-45 | Charge exceeds fee schedule | Contractual write-off, expected |
| PR-1 | Deductible | Bill the client |
| PR-2 / PR-3 | Coinsurance / copay | Bill the client |
| CO-16 | Missing or invalid information | Correct and resubmit; check the RARC |
| CO-29 | Timely filing expired | Usually unrecoverable |
| CO-50 | Not deemed medically necessary | Appeal with documentation |
| CO-97 | Bundled into another service | Check coding; sometimes appealable |
| CO-197 | Authorisation absent | See prior authorisation |
RARC — Remittance Advice Remark Codes — supplement the CARC with specifics. A
bare CO-16 tells you something is missing; the accompanying RARC tells you what.
Working a CO-16 without reading its RARC is guessing.
Auto-posting and the denial that disappears
Auto-posting reads the 835 and updates balances without human intervention. For a practice with volume it is close to essential.
The failure mode is specific: payments post, balances update, the bank reconciles, and nobody ever
reads the adjustment codes. Denials sit in the system as zero-paid lines that look, on a revenue
dashboard, indistinguishable from claims still processing. Practices discover this when they finally
age their receivables and find a year of CO-197 denials past appeal.
The control that catches it. Auto-post the payments and route every non-zero adjustment that is not a straightforward contractual write-off into a work queue with an owner and a deadline. The point of automation is to remove the clerical work, not the review.
EFT and enrolment
ERAs usually accompany electronic funds transfer, and the two are enrolled for separately with each payer — a genuinely tedious process that has to be repeated per payer and updated whenever banking details or the tax ID change.
Two practical points. Reconciliation depends on matching the ERA to the deposit via a trace number that appears in both; without it you are matching by amount, which fails as soon as two payers send similar sums on the same day. And a single deposit frequently covers multiple ERAs, so one-deposit-one-remittance is not a safe assumption.
Retaining ERAs
Keep them. They are the evidence of what a payer said it was doing, and they are what an appeal, a reconciliation dispute or a post-payment review is argued from. A practice that lets its clearinghouse hold the only copy discovers the limits of that arrangement when it changes clearinghouses.
Reading a takeback on the remittance
ERAs are also how recoupments arrive. A payer recovering a previous overpayment frequently offsets it against the current payment, and the remittance shows a negative adjustment referencing the original claim rather than a separate demand letter.
This is easy to miss when a deposit is simply smaller than expected. If a payment does not reconcile and no claim is obviously denied, look for a prior-claim reference on the remittance — see recoupment for what to do when you find one.
Secondary claims and coordination
The ERA from a primary payer is not only a payment record; it is an input to the secondary claim. Most secondary payers require the primary's adjudication details — allowed amount, paid amount, adjustment codes — before they will consider the balance.
Where this is handled electronically the data flows from the 835 into the secondary 837 without rekeying. Where it is handled manually, it is a transcription task with predictable error rates, and secondary claims denied for mismatched primary payment details are a recurring and entirely avoidable category.
Reconciliation in practice
A workable monthly routine, which most small practices do not have and most would benefit from:
- Match deposits to remittances by trace number, not amount.
- Confirm every remittance posted — an 835 that failed to import silently is the most common cause of a receivables balance nobody can explain.
- Review contractual adjustments against the fee schedule. Payers do misprice claims, and an allowed amount below your contracted rate is appealable.
- Age the remaining balances by payer and by reason.
The third step is the one practices skip and the one that most often finds money. Underpayment is harder to notice than denial, because the claim shows as paid.
Keep the fee schedule where you can check it
Underpayment is invisible unless you can compare an allowed amount to what your contract says it should be. Most practices cannot, because the fee schedule lives in a signed PDF nobody has opened since credentialing.
Extracting your contracted rates for the codes you actually bill — usually fewer than a dozen — into something checkable is an hour of work that makes systematic underpayment detectable. Payers do load rates incorrectly, and a claim paid at the wrong contracted amount looks identical on a dashboard to one paid correctly.
Posting to the right client
A mundane failure with disproportionate consequences. Payments posted to the wrong client account create two errors at once: one client shows a balance they have paid, another shows a credit they have not earned.
These surface as billing disputes months later, usually with the client who was wrongly chased, and they are corrosive to trust in a way a straightforward billing error is not. Automated posting keyed on claim number rather than name largely prevents it; manual posting under time pressure is where it happens.
Verified 29 July 2026. Transaction standards (X12 270/271, 835, 837) are set federally under HIPAA; coverage, authorisation requirements, timely-filing windows and appeal rights are set by individual payers and by state law, and vary by contract. Figures described as typical are illustrative, not guarantees. Primary references: CMS billing guidance; X12 code lists; HHS HIPAA. This page is billing reference, not legal or coding advice.