Five steps of ERA processing: receive the 835 file, validate it, match it to the deposit, post it, and flag exceptions

ERA processing explained

ERA processing is the workflow healthcare providers use to turn electronic remittance advice files (X12 835 transactions from payers) into posted, reconciled payments. It runs in five steps: receive the 835, validate the file, reassociate it with the bank deposit, match payments to open claims and post them, then work the exceptions that remain.

What is ERA processing?

ERA processing is the back-office workflow that converts a payer’s electronic remittance advice into posted, balanced payments in the patient accounting system. The ERA itself is the ASC X12N 835 Health Care Claim Payment/Advice, the HIPAA-mandated transaction a health plan uses to explain how it adjudicated and paid a claim.

An ERA carries the same information as a paper explanation of benefits (EOB), in a format software can read. Every adjustment on an 835 must be expressed through standardized Claim Adjustment Reason Codes (CARCs) and Remittance Advice Remark Codes (RARCs); HIPAA prohibits proprietary payer codes. That standardization is what makes automated posting possible. It is also why Revenue Management Solutions has built its entire business on this workflow since 2006: standardized inputs reward disciplined, repeatable processing at scale.

Where the 835 sits in the payment workflow

The 835 is the payer’s answer to the provider’s claim. The provider submits an 837 claim transaction; the payer adjudicates it and responds with an 835 explaining the payment decision. The 835 is never a claim; it is a payment transaction.

A single 835 always corresponds to one payment (one check or one EFT deposit), but it can report decisions on many claims. Inside the file:

  • The BPR segment carries the payment amount and method.
  • The TRN segment carries the reassociation trace number that ties the file to the bank deposit.
  • CLP loops carry per-claim detail: billed, paid, adjusted, patient responsibility.
  • CARC and RARC codes explain each adjustment, grouped as CO (contractual obligation), PR (patient responsibility), OA (other adjustment), or PI (payer-initiated).
  • The PLB segment carries provider-level adjustments such as interest, recoupments, and forwarding balances, which apply to the payment as a whole rather than to any single claim.

PLB activity is the most common reason an 835 does not balance to the deposit. More on that in step five.

The five steps of ERA processing

ERA processing follows five sequential steps: receive the 835, validate it, reassociate it with the payment, match and post to claims, and reconcile exceptions.

Step 1: Receive the 835

ERAs arrive through a clearinghouse or direct payer connections, but only after enrollment. ERA delivery must be set up payer by payer, and ERA and EFT are separate enrollments; completing one does not trigger the other. Medicare delivers 835s through its MACs via EDI. Enrollment gaps are the biggest reason remittances still arrive on paper, and a systematic enrollment program beats ad hoc signups.

Step 2: Validate the file

Validation confirms the 835 is structurally sound and internally balanced before anything posts: syntax checks against the 5010 standard and, more importantly, balancing. The sum of claim-level payments in the CLP loops, adjusted for PLB activity, must equal the BPR payment amount. A file that does not balance never auto-posts; it belongs in the exception queue.

Step 3: Reassociate payment and remittance

Reassociation matches the money in the bank to the data in the 835. For EFT payments, the payer places the 835’s TRN trace number into the addenda record of the NACHA CCD+ deposit; matching the two TRNs ties funds to remittance data, per CMS guidance on EFT and ERA reassociation. Timing is regulated too: under CAQH CORE Rule 370, mandatory since January 1, 2014, a health plan must release the 835 within three business days of the EFT effective date, either side. When money arrives without a remit, or a remit without money, that window tells you when to escalate.

Step 4: Match to claims and post

Posting applies each CLP loop to the matching open claim in the patient accounting system. The posting engine records the payment, writes contractual adjustments (CO group codes) against the expected allowance, moves PR amounts to patient responsibility, and flags anything coded OA or PI for review. High-confidence matches post automatically; low-confidence matches route to a person. This step is where revenue leakage hides. In client engagements at RMS, we’ve seen misapplied adjustment codes quietly write off collectible dollars, a pattern we detail in what goes wrong in payment posting.

Step 5: Reconcile exceptions

Exception reconciliation resolves everything the automated path could not: PLB adjustments such as interest and recoupments that make the 835 total differ from the claim-level detail; claims on the 835 that match no open receivable; one payment split across deposits; and duplicate postings when a payer delivers the same remit through both a portal and an 835, a dual-delivery risk CAQH flags explicitly.

The remittances that never arrive as 835s

Roughly one in ten remittances still arrives outside the 835 standard. According to the CAQH 2024 Index Report, 89% of medical remittance advice transactions were fully electronic in 2024. The remainder came through payer portals, paper, fax, or phone. For a health system posting across hundreds of payers, managing these manual methods is a daily operational reality.

Non-standard remits break the automation chain: someone has to key or capture them, they carry no TRN for clean reassociation, and portal remits create the duplicate-posting exposure noted above. The structural fix is EOB-to-ERA conversion: turning paper and portal remittances into postable 835 data so the entire remittance stream runs through one pipeline.

Where automation fits in ERA processing

Automation belongs in the first four steps; human judgment belongs in the fifth. Intake, validation, TRN reassociation, and high-confidence claim matching are deterministic work that software performs faster and more accurately than people. The economics are well documented: a manual remittance advice costs providers $4.76 per transaction versus $2.86 electronic, according to the CAQH 2023 Index Report, and providers save an average of four minutes per remittance transaction by handling it electronically, per the CAQH 2024 Index. Industry-wide, CAQH puts the remaining ERA adoption opportunity at $695 million per year for medical alone.

What automation should not do is guess. Recoupments, provider-level adjustments, and unmatched remittances need someone who understands payer behavior. At RMS, that split is the operating model: AI-driven capture, validation, and posting absorb the volume (200+ million transactions processed annually), while our 100% US-based analysts work the exceptions.

How to measure ERA processing performance

Four metrics tell you whether ERA processing is healthy: auto-post rate, exception rate, unposted cash aging, and days from deposit to posted.

  • Auto-post rate: the share of transactions posted with no human touch. Track it by payer; a low rate usually signals an enrollment or file-quality issue.
  • Exception rate: the share routed for manual review, broken out by cause.
  • Unposted cash aging: dollars received but not yet posted, aged in days. The number your controller watches at close.
  • Days from deposit to posted: end-to-end cycle time. CORE Rule 370’s three-day window sets the outer bound for when data should be in hand.

How RMS handles ERA processing

RMS has done exactly this work, and only this work, since 2006. We specialize in payment posting and reconciliation, EOB-to-ERA conversion, correspondence management, and ERA/EFT enrollments, integrated with Epic and the other major EHRs. RMS is HIPAA-compliant, entirely US-based and has over 1 billion healthcare transactions processed in the last 5 years. Our job is running this pipeline at health-system scale so your team only sees the exceptions that genuinely need them.

Frequently asked questions

What is ERA processing?

ERA processing is the workflow of receiving electronic remittance advice files (X12 835 transactions) from payers, validating them, matching each payment to the corresponding claims, posting payments and adjustments, and reconciling exceptions such as recoupments or unmatched remittances.

What is the difference between an ERA and an EOB?

An ERA and an EOB carry the same payment explanation in different formats. The ERA is the machine-readable X12 835 file that posting systems process automatically; the EOB is the human-readable paper or PDF version.

What does 835 mean in ERA processing?

835 is the ASC X12N transaction number for the Health Care Claim Payment/Advice, the HIPAA-mandated electronic format payers use to explain claim payments. One 835 can report decisions for many claims and always corresponds to a single payment.

How long after payment should an ERA arrive?

Within three business days. Under CAQH CORE Rule 370, a health plan must release the 835 no earlier than three business days before and no later than three business days after the EFT effective entry date.

Can ERA posting be fully automated?

Most of it can. Intake, validation, EFT reassociation, and high-confidence claim matching are reliably automated, and well-run operations auto-post the large majority of ERA transactions. Exceptions such as provider-level adjustments, recoupments, unmatched claims, and paper remittances still require trained review.

Talk to RMS about your ERA workflow

If unposted cash, exception backlogs, or paper remits are absorbing your posting team, we can map your ERA workflow against the five steps above and show where the gaps sit. Twenty years of specializing in remittance and reconciliation makes that assessment fast and specific. Schedule a consultation with RMS.

Sources cited: CAQH 2024 Index Report · CAQH 2023 Index Report · CAQH CORE Rule 370 · CMS guidance on EFT and ERA reassociation

‍