Electronic remittance advice

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

ERA explains adjudication while EFT moves funds

The required CMS EFT and ERA guidance distinguishes the two transactions. An ERA explains how a health plan processed claims and adjustments. An electronic funds transfer, or EFT, moves money. Payment posting applies validated remittance results and matched funds to claim, accounts-receivable, and patient-ledger records.

An ERA can include paid claims, partial payments, denied claims, zero-payment results, contractual adjustments, other payer actions, and patient-responsibility information. A single remittance can cover many claims and service lines. The payment can arrive through a separate channel or at a different time.

For Medicare, the current CMS payment-and-remittance page gives one program example in which one check or EFT represents benefits for claims itemized in the ERA or standard paper remittance. Other payers can batch and route remittances differently.

The standard electronic form is an 835 transaction

CMS's current adopted standards table lists X12 835 Version 5010 for electronic remittance advice. The ERA is the business document. The 835 is its standard electronic transaction format. A portal PDF, proprietary report, or paper explanation may carry related information without being the standard ERA transaction.

The CMS EFT and ERA operating-rules page explains that HIPAA-covered payers use standard adjustment codes rather than proprietary adjustment codes. X12's CARC list says a Claim Adjustment Reason Code explains why a claim or service line was paid differently, while its two-character group code generally assigns adjustment responsibility. X12's RARC list distinguishes supplemental RARCs, which add CARC detail, from Alert RARCs, which convey processing information and are not tied to a specific adjustment. Interpret the current group, CARC, and RARC combination at its claim or line location with the source claim, payer policy, and contract. A PR group code alone does not prove that a patient balance is collectible.

Reassociate the ERA with the payment

For ACH EFT, CMS's reassociation guide explains that the payer includes a unique reassociation trace number, or TRN, in payment initiation and a matching TRN in the corresponding ERA. The payment and ERA use different formats and may arrive at different times. Match the CCD+ Addenda TRN to the 835 TRN before treating the deposit as that ERA's settlement. For non-retail claims, the adopted CORE 370 rule requires the health plan to release the ERA no sooner than three business days before and no later than three business days after the EFT Effective Entry Date; that is a release window, not guaranteed receipt. Checks and other payment channels need their own documented match method.

For each ERA, record:

• payer, payee, payment date, payment amount, payment method, and TRN
• claim identifiers, patient control numbers, payer control numbers, and service dates
• billed, allowed, paid, claim-level adjustment, patient-responsibility, PLB, interest, withholding, and transaction-payment amounts
• claim and service-line statuses, group codes, reason codes, remark codes, and quantities
• reversal, correction, recoupment, refund, forwarding, secondary-payer, and appeal indicators
• matched bank deposit or check, match method, variance, owner, age, and resolution
• posting batch, approval, ledger changes, patient-balance review, and close date

An 835 can contain Provider-Level Balance (PLB) adjustments that are not tied to one claim. X12's official interpretation confirms the transaction balance: claim payments minus PLB adjustments equal the total payment amount. A positive PLB reduces the settlement and a negative PLB increases it. Post each PLB to the appropriate provider ledger; do not force it onto a patient claim.

Quarantine the whole transaction for an unknown payer, wrong payee, duplicate transaction, transaction-level imbalance, or unresolved settlement mismatch. Route a missing claim, unsupported patient responsibility, authorization conflict, coding issue, or reversal at the affected claim or service line; do not block validated outcomes unless an approved control requires a batch hold. Preserve the raw 835 and its readable rendering.

Posting requires source and contract checks

An ERA reports the payer's adjudication. Before posting, compare it with the submitted claim, authorization evidence when applicable, payer policy, contract terms, prior remittance history, and the actual bank result. Route coding or documentation conflicts to the qualified owner rather than changing clinical facts or forcing a balance.

Contractual adjustment, payer denial, patient responsibility, refund, and write-off are different ledger states. Assign each through an approved reason taxonomy. If a payer changes a prior result, retain the original and correction instead of overwriting history.

The current CMS operating-rules FAQs require specified CARC and RARC combinations for four business scenarios. Outside those scenarios, payers may use other combinations of standard CARCs and RARCs when they do not conflict. Current code meaning, group, transaction level, payer product, contract, and applicable patient-billing rules still control posting.

A fictional ERA has twenty separate outcomes

A fictional 835 ERA covers 20 claims. Seventeen claim-payment amounts total $12,480.50. Two claims are denied with no payment, and one has a zero-payment adjudication with adjustment and patient-responsibility information. Assume this example has no PLB adjustment. The 835 transaction-payment amount and associated ACH EFT are both $12,480.50, with matching TRNs.

Transaction balance is $12,480.50 in claim payments minus $0 in PLBs = $12,480.50. Deposit variance is $12,480.50 EFT minus $12,480.50 ERA payment amount = $0. Trace match and amount match are each 1 of 1, or 100%. Claim-result completeness is 20 of 20 after every claim maps and its service lines balance. The positive-payment claim rate is 17 of 20, or 85%.

A zero total variance can hide offsetting claim or PLB errors. It does not prove every adjustment is correct or every patient balance is collectible. Route each exception through its coding, authorization, contract, appeal, or patient-billing workflow.

Measure receipt, matching, and posting independently

Useful measures include:

• ERA receipt completeness: adjudicated claim outcomes received on ERA divided by all adjudicated outcomes in the same matured, ERA-enrolled cohort
• claim mapping: ERA claim outcomes mapped to exactly one submitted claim version divided by all claim outcomes on received ERAs in that cohort
• transaction balance: balanced 835 transactions divided by mature 835 transactions received
• EFT reassociation: ACH-EFT-associated ERAs with matching TRNs divided by mature ACH-EFT-associated ERAs received
• deposit reconciliation: reassociated EFT and ERA pairs with zero unresolved variance divided by all reassociated pairs in the same mature cohort
• posting completeness: claim and line outcomes fully posted and reconciled divided by outcomes due for posting in that cohort
• exception aging: median and 90th-percentile days from the defined exception event to verified closure
• reversal integrity: matured reversals and corrections linked to prior remittance and ledger entries divided by all matured reversals and corrections received

Define payer, product, route, ERA enrollment, transaction, claim, line, maturity window, match, variance tolerance, clock, and final disposition. Report positive payments, partial payments, zero-pay results, denials, patient responsibility, PLBs, recoupments, refunds, and unresolved remittances separately.