ERA and Payment Posting Explained (835)

An ERA is the X12 835 file a payer sends after it adjudicates your claims. It states what was paid on each service line, what was adjusted and why, and what the patient owes. Posting is slow because the 835 explains decisions in codes, and every code that is not a plain payment needs a human decision.

Quick answer:

An ERA is not a payment. It is the explanation alongside one, in a fixed format, and the money usually lands in the bank on a different day.
Auto-posting handles the easy majority: line-level payments, contractual write-offs, the patient share. It stops at anything needing a decision.
Practices underestimate ERA volume by counting payments instead of adjudicated claims. Every corrected resubmission that adjudicates again counts again.

What an ERA is, and what it is not

Three documents get confused here. The claim is what you send: in an outpatient practice, the electronic cousin of the CMS-1500 form. The EOB is what the patient receives, written for a human, no fixed machine format. The ERA is what the practice receives: the payer's decision as structured data.

CMS states that all ERAs sent by Medicare contractors are currently in the X12 835 version 5010 format adopted as the national HIPAA ERA standard. Commercial payers use the same transaction.

Because the format is fixed, software can read it. Because the format is fixed, it is also unforgiving. The payer is not writing you a note, it is emitting codes, and the codes mean exactly what the code list says.

What is inside an 835

An 835 is a payment, then claims, then service lines, then adjustments under those.

The payment header. The total paid, the method, and a trace number identifying the payment. That number matters more than it looks, and the next section explains why.

The claim level. What was billed, allowed and paid, plus the payer's own control number, which is the field a payer's phone representative asks for.

The service lines. The same arithmetic per procedure code. A claim can be paid in full at claim level and still hold a line reduced to zero. If you read only claim totals, that is the money you lose.

The adjustments. Every dollar billed but not paid carries a group code plus a reason code. X12 maintains four active group codes: CO for contractual obligation, PR for patient responsibility, PI for payer initiated reduction, OA for other adjustment. The group code decides what happens next. CO you write off, because you agreed to. PR you bill to the patient. PI and OA mean someone reads further.

The reason and remark codes. Claim Adjustment Reason Codes, or CARCs, in the words of X12, describe why a claim or service line was paid differently than it was billed. Remittance Advice Remark Codes, or RARCs, add detail, and X12 splits them in two: supplemental ones explain an adjustment already described by a CARC, informational ones, called Alerts, convey information about remittance processing and are never tied to an adjustment. Both lists change, which is why a rule written against a reason code two years ago may quietly stop matching.

Why the money and the explanation arrive separately

This surprises anyone who assumed an ERA is a receipt. The payment moves over the banking rails as an electronic funds transfer. The explanation moves over the healthcare rails as an 835. Two journeys, arriving apart, so something has to match them. The mechanism has a name: reassociation.

CMS describes it directly. The trace number in the addenda record of the bank transfer should be the same as the trace number in the associated ERA that describes the payment, and using the same trace number helps match the payment to the correct remittance advice. Operating rules for electronic funds transfer and ERA became mandatory on 1 January 2014, which is what made this reliable enough to automate at all.

In practice the bank shows a deposit with no breakdown, the ERA a breakdown with no deposit, and until they are matched your books hold cash you cannot attribute. The lag is normal.

What auto-posting can do

The mechanical part is genuinely solved. CMS states the capability in one sentence: the amount payable for each line and/or claim as well as each adjustment applied to a line or claim can be automatically posted.

That covers the large majority of lines on a normal day:

The allowed and paid amounts land against the right service line on the right claim.
CO adjustments become contractual write-offs without anyone deciding, because the contract already decided.
PR adjustments become the patient's balance, the number the front desk and the statement both need.
The claim moves to paid and leaves everyone's follow-up list.

If most of your remittance lines are clean, most of your posting disappears. That is why moving from paper EOBs to ERAs is the largest efficiency step many billing teams ever take. It is also where the honest part of this article starts.

What auto-posting cannot do

Every remaining category has the same shape. The file states a fact; a person decides what it means here.

Zero-pay and denial lines. The 835 says a line was denied and gives the reason code. It cannot say whether to appeal, rebill with a corrected code, bill the patient, or write it off. That judgement is the biggest consumer of billing time.

Provider-level adjustments. Some money in an 835 belongs to no claim in the file: a takeback for an overpayment four months old, withheld amounts, interest, a penalty. It reconciles against the bank, not a patient ledger. Automation can apply it. Only a person can explain it.

Bundling, and lines that moved. When a payer bundles one procedure into another, the money moved rather than vanished. Posting as stated leaves one line underpaid and another overpaid.

Coordination of benefits. When a primary payer finishes, the balance is often the secondary payer's, not the patient's. Auto-posting a PR adjustment onto a statement there earns a complaint, sometimes a refund, always a phone call.

Patient balances that already moved. If you collected an estimated copay at the desk, the real patient share may be higher or lower. The balance reopens, or the patient is owed money back.

Partial and split payments. A claim can be paid across two remittances. Until the second arrives, the gap looks like a denial.

Where a person still reconciles

A working list to hand to whoever owns billing:

The bank against the file. Deposits matched to remittances by trace number, anything unmatched aged and chased.
The denial queue. Every zero-pay line triaged into appeal, correct and resubmit, bill the patient, or write off, with the payer's reason code attached to the decision.
The rejection queue, kept separate. A rejection never reached adjudication, so it produces no ERA at all. Fix and resend rather than appeal.
Provider-level adjustments. Takebacks and interest reconciled monthly, not left to distort a revenue report.
Patient responsibility, after the fact. Estimates collected up front compared against the payer's actual patient share, then invoiced or refunded.

How ERAs work inside Ona

Ona is a general ambulatory EHR that scales from solo clinicians to multi-location groups and enterprise systems, as its own homepage FAQ puts it: Ona scales from solo clinics to enterprise systems. The honest exclusion is inpatient and hospital workflows. The cycle below is the same at one clinician or thirty.

The claim is assembled from clinical work rather than retyped. Services and diagnoses charted on the visit become the line items and linked codes, a signed note is required before the visit can be billed, and the completed visit produces a frozen, CMS-1500-style superbill that becomes the basis of the claim. How claims move through Ona documents each gate.

After submission the claim sits in the claims queue on two independent axes. Status is what the payer thinks: Draft, Submitted, Acknowledged, Accepted, Rejected, Denied, Paid. Bucket is what your team is doing: Untriaged, Review, Hold, Payments, Pending, Settled, Patient Billing, Closed. That split exists because a claim can be adjudicated and still be work. The History tab holds the timestamped audit trail, and View response opens the payer's raw response with the reason code in it.

On the money side, insurance posts patient responsibility as a balance after adjudication, and invoices and patient payments covers the case this article keeps returning to. Where a copay was collected before adjudication, the invoice reads as collected and awaiting insurance until the remittance arrives, and the remittance then replaces the estimate with the payer's actual patient share: if the patient owes more the balance reopens, if less the invoice shows a credit to refund.

Two things Ona does not pretend about. Denial decisions are still yours, which is why the queue is built for triage rather than for hiding the problem. And the fastest way to cut posting work is to prevent rejections, which is what billing rules and claim scrubbing are for.

How to size an ERA allowance

Clearing house plans are sized by transactions, and ERAs are the one practices estimate worst, because they count payments received rather than claims adjudicated. One 835 file can carry many claims, and clearing house plans meter the claim responses inside it rather than the files, so two corrected resubmissions that both reach adjudication consume two.

A usable estimate:

Count billable insured visits in a normal month. Cash-pay visits generate no claims.
Multiply by claims per visit, which for most outpatient practices is one.
Add your resubmission rate. If one claim in ten comes back corrected, add ten per cent.
Size eligibility higher. Checks run before the visit, including for patients who cancel.

Ona Clearing House plans pair claims and ERAs one to one, with more headroom on eligibility: Starter $69 covers 100 claims, 100 ERAs, 200 checks; Core $149 covers 250, 250, 500; Practice $249 covers 500, 500, 750; Growth $499 covers 1,000, 1,000, 1,500; Scale $1,099 covers 2,500, 2,500, 3,750. Every plan includes unlimited providers and payer enrollments, higher volumes are quoted individually, cash-pay practices need no plan, and annual billing takes 10% off.

Where the 835 lands: platforms compared

One axis only: how far the 835 travels before a person has to re-key something. It is not a quality ranking and not a price ranking. Everything below was checked on each vendor's own site in September 2026.

Order	Platform	Where the 835 lands	What a person still does	What you contract for
1	Ona with Ona Clearing House	The same record that built the claim and holds the patient's invoice	Triages denials, handles provider-level adjustments and secondary billing, rebills or refunds when the remittance corrects a collected copay	One contract with Ona, clearing house running on Stedi with no separate account, contract or fee, unlimited providers and payer enrollments on every plan, and higher volumes quoted individually
2	Tebra	Its own billing platform, alongside the claims it submitted	The same triage work, in the same system	One contract with Tebra, whose own clearinghouse delivers the 835 into its billing platform
3	Claim.MD	A standalone clearing house account your EHR connects to	Triage in one place, posting wherever the ledger lives	A direct Claim.MD contract alongside your EHR, with the payer enrollments held by you
4	Availity Essentials	A multi-payer portal, separate from the system you chart in	Reads it there, then records the outcome elsewhere	An Availity Essentials portal account alongside the system you chart in
5	Stedi	As data, delivered to software you or your vendor build	Everything, unless your developers built the posting logic	A direct Stedi contract, with your own or your vendor's software consuming the transactions

Two honest notes. Stedi is also the engine underneath Ona Clearing House, which is the fair way to read row five: the same transactions, either as raw data someone handles or inside the record where the claim already lives. And what the Ona plan buys is that the file arrives where the claim, the note and the patient balance already are, with payer enrollments included and no second vendor to manage. If your team re-keys payer decisions from a portal into a ledger, that is worth a lot. If your systems already talk, it is worth less.

Ona also supports bringing your own Claim.MD account instead of Stedi, which matters if you already hold payer enrollments, since re-enrolling takes weeks per payer. Setting up your clearinghouse covers both routes.

Frequently asked questions

What is an ERA in medical billing?

An ERA is the file a health plan sends back after it adjudicates a claim. The format is the X12 835, and CMS states that all ERAs sent by Medicare contractors are currently in the X12 835 version 5010 format adopted as the national HIPAA ERA standard. It gives what was paid per service line, what was adjusted and under which reason code, and how much is now the patient's.

What is the difference between an ERA and an EOB?

Same decision, two audiences, two formats. The EOB is the human-readable statement, historically paper, that explains the outcome. The ERA is the machine-readable 835 sent to the practice so the numbers can be posted without anyone retyping them. A practice working from EOBs is reading a document; one working from ERAs is processing data.

Why does payment posting take so long?

Because most of the work is not the payment. Clean payment lines post in seconds. The time goes on the rest: zero-pay lines needing an appeal or write-off decision, provider-level adjustments that belong to no single claim, secondary billing, payments arriving on a different day from the file, and patient balances that changed after a copay was collected. Each one is a decision, not a keystroke.

Can ERAs be posted automatically?

Partly, and that is the honest answer. CMS describes the mechanism plainly: the amount payable for each line or claim, and each adjustment applied to it, can be automatically posted. What cannot be automated is judgement. A denial reason code can be read automatically but not answered automatically, and a takeback still has to be explained to whoever reconciles the bank.

How many ERAs does my practice need per month?

Start from adjudicated claims, because ERA allowances are metered on claim responses rather than on payments received. Count billable insured visits in a normal month, add the corrected claims you expect to resubmit, and size from there. Ona Clearing House plans pair the two one to one, from 100 claims and 100 ERAs on Starter at $69 a month to 2,500 and 2,500 on Scale at $1,099, with higher volumes quoted individually.

How does Ona handle ERAs and payment posting?

The claim is built from the signed note, submitted through the clearing house, and tracked in the claims queue through Draft, Submitted, Acknowledged, Accepted, Rejected, Denied and Paid, with the payer's raw response on the History tab. Patient responsibility posts as a balance after adjudication, and where a copay was collected up front the remittance replaces the estimate with the payer's actual patient share.

Next step

Bring one real remittance to a 15-minute demo, ideally with a denial and a takeback in it, and watch where each line lands. To read first: reduce claim denials and get paid faster covers prevention, real-time insurance eligibility and claims software covers the front of the cycle. The 14-day trial needs no credit card.

ERA and Payment Posting Explained: What the 835 Actually Does