What is electronic remittance advice (ERA)?

Key takeaways

An electronic remittance advice (ERA) is the file a health plan sends to explain how it processed each of your claims.

The ERA is the explanation sent to you, the EOB is the version the patient gets, and the EFT is the money.

Every ERA carries the paid amount per service line, the adjustments with their CARC codes, and the amount left with the patient.

ERAs are not automatic. You enroll for them payer by payer, and every plan runs its own process.

Posting software reads the 835 and settles claims for you, so the day’s remittances become a worklist of exceptions.

An electronic remittance advice (ERA) is the electronic file a health plan sends to explain how it processed your claims. Its standard format is the HIPAA 835, which is why ERA and 835 file get used interchangeably. CMS puts it plainly, as an explanation from a health plan to a provider about a claim payment.

After a claim goes out, one question decides everything downstream. What did the payer do with it? The ERA answers that per claim and per service line, in standard codes every plan has to use. Plenty of practices still get the same answer by logging into payer portals one plan at a time.

This guide covers what an ERA contains, how it differs from an EOB and an EFT, and how to read one line by line. It also covers the enrollment step that has to happen before any of it turns up.

ERA, EOB, and EFT: What’s the difference?

The ERA is the explanation sent to the provider, the EOB is the explanation sent to the patient, and the EFT is the money. All three describe the same claim. They arrive separately, in different places, and often on different days.

The terminology has one wrinkle worth knowing. In the standards themselves, the provider’s remittance is sometimes called an explanation of benefits, so the two terms overlap. In everyday US billing, EOB means the patient’s copy and ERA means yours.

The reconciliation problem is that the file and the deposit travel apart. CMS calls pairing them re-association. Both carry the same trace number, in the 835’s TRN segment and in the addenda record attached to the ACH payment. Match on that number rather than on the amount, because one deposit often covers many claims.

This is where practices lose hours. A deposit that doesn’t equal the sum of the claims sends somebody hunting through the file for the difference. Usually it’s a provider-level adjustment, and the annotated example below has one in it.

What’s inside an ERA

An ERA carries the payer’s full decision on a batch of claims, from the payment total down to the individual service line. Underneath the X12 jargon, it holds seven things.

• Who paid, and who is being paid. Payer and payee identification, at the top of the file.
• The payment itself. The total amount, the method (ACH or check), the date, and the trace number.
• One block per claim. A claim status code, plus the billed, paid, and patient-responsibility totals.
• One block per service line. The procedure code, and what was billed, allowed, and paid on that line.
• Adjustments. Each one is a group code, a claim adjustment reason code (CARC), and an amount.
• Remark codes. A remittance advice remark code (RARC) adds the detail a reason code can’t carry on its own.
• Provider-level adjustments. Recoupments, interest, and penalties that change the deposit without belonging to any single claim.

Read the group code first, because it decides who absorbs the money. CO is contractual obligation, which you write off. PR is patient responsibility, which you bill. OA and PI cover other adjustments and payer-initiated reductions.

Payers can’t invent their own reasons for any of this. Under HIPAA, every payer including Medicare has to use CARCs and RARCs approved by the X12-recognized code list maintainers. The same code means the same thing at every plan you bill, which is what makes automatic posting possible at all.

In medical billing, the ERA holds the same information as the paper remittance, structured so software can act on it. CMS even publishes free software called Medicare Remit Easy Print. It turns an 835 into a readable report for practices without a system that reads one.

How to read an ERA: An annotated example

Take one claim with two service lines. The figures below are illustrative. The codes, the group codes, and the arithmetic are exactly how a real 835 behaves.

Start with the line that paid. Here is what each number on it means.

• Billed $150.00. What you charged for the office visit.
• Allowed $92.00. What your contract with the plan says that service is worth.
• CO-45, $58.00. X12 defines code 45 as a charge above the fee schedule or contracted amount. The CO group code makes it contractual, so you write it off and never bill the patient.
• Plan paid $73.60. Eighty percent of the allowed amount, in this example.
• PR-2, $18.40. Code 2 is coinsurance, and PR assigns it to the patient. This is the figure that belongs on their statement.

The arithmetic closes on every claim, which is how you check your own posting. Billed $150.00, less the $58.00 contractual adjustment, leaves the $92.00 allowed. Of that, $73.60 comes from the plan and $18.40 comes from the patient.

Spotting a denial in the file

A denial looks like $0.00 paid, with a CO, PI, or OA adjustment carrying the reason. The second line in the example is one. You billed $95.00 for a joint injection, the plan paid nothing, and the adjustment is CO-197 for the full amount.

X12 defines code 197 as precertification, authorization, notification, or pre-treatment absent. That single code tells you the coding was fine and the authorization was missing. It also tells you the patient can’t be billed for it, because the group code is CO.

Don’t rely on the claim status code alone. A fully denied claim usually carries status 4, but a single line can be denied on a claim the payer marked as processed. Read the paid amount and the adjustment on every line, not just the claim total.

Two more patterns are worth recognizing on sight. CO-16 means the claim lacks information or has a billing error, and X12 requires a remark code alongside it. When that remark is MA130, the claim is unprocessable and carries no appeal rights, so the fix is a corrected claim rather than an appeal.

Claim status 22 is a reversal of a previous payment. The payer is taking money back. Reverse the original posting and restore the claim balance first, then work out whether the takeback is correct, because payers do reverse in error.

From there the code drives the work. Our guide to denial management in healthcare covers the choice between a corrected claim, an appeal, and a write-off.

How to get ERAs: enrollment

ERAs don’t arrive by default. You enroll for them payer by payer, and every plan runs its own process. This is the step competitors skip, and it’s the reason a practice can be fully electronic on submissions and still be reading paper remittances.

There is a standard behind the paperwork. The CAQH CORE operating rules for EFT and ERA have been in force since January 1, 2014. They cap the data a plan can ask you for, and they require every plan to offer a secure electronic way to send it. Paper forms are still allowed alongside.

Turnaround varies by plan. Pennsylvania’s Medicaid program, for one, quotes four weeks to process a paper ERA application, against a much faster route through its provider portal. Until enrollment clears, you’re back on portal logins and paper.

Note that the ERA and the EFT are two separate enrollments. CAQH CORE publishes a rule for each, with its own data set, and plans often run them as two forms. Getting the file without the deposit is a familiar way to end up reconciling by hand anyway.

A clearinghouse takes the tracking off you. Rather than chasing forms across dozens of plans, you enroll through one payer directory and watch each payer’s status in one place. Our guide to medical claims clearinghouses covers where the clearinghouse sits on a claim’s route.

Auto-posting: what software does with an ERA

Auto-posting is software reading the 835 and doing the posting for you. It matches each claim in the file to the claim in your system, then applies what the payer decided to each one.

In one pass it posts the paid amount against the invoice and writes off the contractual adjustments. It moves patient responsibility onto the patient’s balance, flags the denials with their codes attached, and reconciles the file total against the deposit.

Auto-posting isn’t unattended, though. Three things need a person on them every time.

• Unmatched payments. A claim the software can’t find, usually because the claim number changed or the claim was submitted outside the system.
• Partial pays. Paid less than allowed, or paid on some lines and denied on others. Both look settled in a total, and neither is.
• Takebacks and reversals. Status 22 claims and provider-level recoupments, which change the deposit without touching any claim’s balance.

So the question to ask of any system is what it does with those three. A worklist you can clear in ten minutes beats a posted batch that buries them.

How Pabau settles ERAs into your billing

Practice management software like Pabau takes the ERA off your desk entirely. Claims go out to US payers through our Claim.MD integration, and the 835s come back down the same connection automatically.

Each remittance settles its own claim. A paid claim moves to Paid, with the payment matched into Pabau billing against the invoice it came from. A denied claim moves to Denied, with the payer’s CARC codes attached to it.

That last detail is what saves the follow-up. The denial reason sits on the claim, next to the amounts and the payer, so whoever picks it up can see why it came back. Every submission, response, and change stays on the claim’s own activity history.

Enrollment lives in the same place. You browse the Claim.MD payer directory, link each payer to the insurer on your side, and track how far each enrollment has got. So the day’s remittances arrive as a settled ledger, and what’s left is the short list that came back with a problem.

Settle remittances without keying a single line

Pabau receives ERAs automatically through the Claim.MD integration, settles each claim to Paid or Denied, and matches the payment into your billing. Denial reasons arrive as CARC codes on the claim, so your team works the exceptions instead of reading files.

Book a demo

Conclusion

The ERA is the payer’s side of the conversation, and the only place a payer tells you exactly why. Read it the week it lands and you catch a denial while the fix is still cheap and the filing window is still open. Wait for a statement and you find out a month later.

Two things get you there. Enroll for ERAs with the payers you bill most, then put the file somewhere that posts it and hands you the exceptions. Neither is hard, and the second one turns a stack of remittances into ten minutes of review.

One trade-off is worth naming. Auto-posting hides the ordinary work, which is the whole point, so its value rests on somebody actually reading the exception list. Book a demo to see how Pabau settles ERAs against your claims and puts denial reasons where your team will find them.

Continue your research

Wondering how your claims reach payers in the first place? What is a medical claims clearinghouse? follows the route a claim takes out and the remittance takes back.

Got a denial off the ERA and need to work it? Denial management in healthcare sets out the five-step process and the corrected claim versus appeal decision.

Want fewer adjustments to read in the first place? What is a clean claim? covers the checks that stop a claim coming back at all.

Billing patients who claim reimbursement themselves? What is a superbill? covers the document out-of-network patients send to their own insurer.

Frequently asked questions