835 transaction

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

The 835 explains adjudication after a claim

An ABA practice commonly sends a professional claim in an 837P transaction. The payer adjudicates it and may return an 835 electronic remittance advice, or ERA, describing what happened. The 835 can carry information at the claim, service-line, and provider level. It may accompany payment, a zero-payment result, a denial, or an adjustment.

The current CMS payment and remittance page describes an ERA as the health plan's explanation to a provider about claim payment. CMS says CARCs and RARCs are standard code sets used to explain adjustments and bars payers from substituting proprietary adjustment codes under HIPAA. The public page also explains the matching trace used for payment-remittance reassociation.

The X12 public 835 overview identifies the transaction set as Health Care Claim Payment/Advice for electronic data interchange. Detailed loops, segments, situational rules, and data dictionaries belong to the applicable licensed X12 implementation guide and adopted version. A blog, screenshot, or copied sample should not replace that source.

ERA and EFT are linked but distinct

Electronic remittance advice (ERA) explains adjudication. Electronic funds transfer (EFT) moves money through a financial network. One can arrive before the other, and an 835 can explain a claim with no payment. A bank deposit alone lacks the claim and adjustment detail needed for posting.

CMS's current adopted-standards table lists X12N 835 Version 5010 for electronic remittance advice and the ACH CCD+ Addenda plus the X12 835 reassociation trace content for health care EFT. Verify the current rule and effective date rather than assuming a newer X12 publication is already the adopted HIPAA transaction.

The matching trace in the EFT addenda should agree with the corresponding ERA trace. CMS's EFT and ERA guidance calls this reassociation and explains why it is necessary for accounts-receivable posting. Reassociation connects the deposit and remittance; it does not prove every claim line posted correctly.

Key information needs separate posting rules

An 835 may communicate:

• payer, payee, transaction, and payment identifiers
• claim and service-line adjudication amounts
• Claim Adjustment Group Codes, or group codes
• Claim Adjustment Reason Codes, or CARCs
• Remittance Advice Remark Codes, or RARCs
• patient-responsibility amounts reported by the payer
• Provider-Level Balance, or PLB, adjustments not assigned to one claim

The CMS Medicare remittance page explains that claim and line adjustments can use group codes, CARCs, and RARCs, while provider-level adjustments use PLB reason codes. It also notes that one Medicare ERA or paper remit often reports multiple claims and that an ERA can support automated posting. Medicare-specific billing statements on that page should not be generalized to every commercial or Medicaid product.

Codes need context. A contractual-obligation group code does not authorize an undocumented write-off, and a patient-responsibility group code alone does not establish that the practice may bill the family. Apply the governing plan, contract, benefit design, notice, coordination-of-benefits result, payer policy, and law. Route unclear, conflicting, or unsupported combinations for review.

Build a controlled 835 workflow

A dependable workflow has seven stages:

1. Receive and validate. Confirm the expected trading partner, transmission integrity, control totals, adopted version, and duplicate status.
2. Reassociate. Match the ERA to the EFT or other payment using the trace and payer evidence.
3. Match. Resolve payer claim and service-line identifiers to the correct patient account, claim version, service date, and ledger item.
4. Post. Apply payments and approved adjustment categories under versioned mapping rules.
5. Route exceptions. Queue denials, unmatched lines, ambiguous responsibility, PLBs, reversals or corrections, and contract variances with an owner and due date.
6. Reconcile. Tie claim-line payments and provider-level adjustments to the ERA payment total, deposit, and general ledger.
7. Preserve evidence. Retain the original file, transmission record, posting batch, mapping version, user or automation actions, corrections, and final resolution.

Make ingestion idempotent. A file hash, payer identity, transaction identifiers, payment trace, and amount can help detect duplicates, but the rule must allow legitimate payer corrections. Never silently overwrite a prior posting. Reverse or correct through an auditable workflow tied to the source transaction.

Enrollment and delivery also vary by payer and clearinghouse. The CMS operating-rules FAQ describes requirements for covered entities, including a limited dual-delivery period during initial testing. Confirm the payer's current enrollment, delivery route, companion guide, testing process, and support channel.

A fictional remittance shows the controls

A fictional 835 contains 12 service lines with $8,000 in line-level payer payments. Ten lines, totaling $6,400, match automatically. Two lines, totaling $1,600, enter the unmatched queue. The file also contains a negative $500 PLB adjustment, so the net ERA payment is $7,500. The associated EFT deposit is $7,500.

The line match rate is 10 ÷ 12 = 83.3%. The unmatched payment-dollar rate is $1,600 ÷ $8,000 = 20%. Deposit reassociation is complete because the $7,500 EFT matches the net ERA payment. Ledger posting is incomplete because two line payments remain unmatched. The $500 PLB stays in a separate provider-level workflow; it is not allocated to a client balance without valid supporting evidence.

This example is arithmetic, not a benchmark. Report counts and dollars together. A high auto-post percentage can conceal a large unmatched dollar, and a reconciled bank deposit can coexist with claim-level posting errors.

Monitor exceptions and correction quality

Useful measures include:

• 835 receipt coverage: expected ERA-eligible remittances received divided by expected ERA-eligible remittances
• first-pass line match rate: lines matched without manual intervention divided by eligible 835 claim lines
• unmatched payment-dollar rate: unmatched line-payment dollars divided by total line-payment dollars received
• deposit reassociation rate: payments tied to the correct ERA and deposit divided by payments requiring reassociation
• exception aging: open items by age from receipt, owner, payer, reason, and dollar exposure
• correction recurrence: repeated mapping or posting errors divided by remittances exposed to that rule version

Define test files, duplicates, reversals, zero-pay remittances, and PLBs before setting denominators. Segment by payer, product, delivery route, and mapping version. Pair speed with accuracy, patient-balance safeguards, refund or recoupment control, and audit findings.