835 Remittance Advice: Reconcile Payments Faster

Smarter Billing. Stronger Practice.

discover how we help you!

The 835 remittance advice is the ASC X12 Healthcare Claim Payment/Advice transaction (formally known as the Electronic Remittance Advice, or ERA) that a payer sends to a provider after adjudicating a claim. It explains exactly what was paid, what was adjusted, and why. For billing teams, the 835 is the single source of truth for auto-posting, EFT deposit reconciliation, and denial triage. Without it, every payment becomes a manual puzzle.

Pro Tip: When a deposit doesn’t balance, go straight to the TRN and PLB segments first. The TRN ties the ERA to the EFT deposit, and unposted PLB entries are the most common reason the numbers don’t add up.

Key Takeaways

The 835 ERA is the authoritative source for payment posting and reconciliation; correct TRN reassociation, PLB balancing, and CARC/RARC mapping are the three operational controls that determine whether cash posts cleanly or piles up in exceptions.

Point	Details
TRN is the reconciliation anchor	Match TRN02 in the 835 to the CCD+ addenda trace number before processing any claim data.
PLB breaks most tie-outs	BPR02 must equal the sum of CLP04 payments ± PLB adjustments; unposted PLB is the leading cause of deposit mismatches.
CARC/RARC must be standardized	HIPAA prohibits proprietary adjustment codes; maintain a current mapping table per payer companion guide.
V5010 and CORE rules are mandatory	ASC X12 835 V5010 and CAQH CORE EFT & ERA operating rules have been required for covered entities since January 1, 2014.
One For All Medical Billing	Provides full ERA/EFT enrollment, mapping, auto-post configuration, and exception management for practices nationwide.

What does an 835 remittance advice contain?

The 835 transaction set is built around a layered envelope structure. Understanding each layer tells you exactly where to look when something goes wrong.

The outer envelope: ISA, GS, and ST segments

Every 835 file opens with ISA (Interchange Control Header), GS (Functional Group Header), and ST (Transaction Set Header) segments. The control numbers embedded here are your integrity check. If a file is reprocessed or duplicated, mismatched control numbers will flag it before bad data reaches your ledger.

Payment header: BPR and TRN

The BPR segment carries the core payment details: payment method, payment amount (BPR02), payment date, and payer/payee financial routing information. Directly after BPR, the TRN (Reassociation Trace Number) segment holds the check or EFT trace number. This is the value that links the 835 to the corresponding CCD+ addenda record from the bank, making TRN the linchpin of automated reconciliation. CMS confirms that using the same TRN in both the CCD+ addenda and the ERA is what enables reliable auto-posting.

Claim-level data: CLP and CAS

The CLP segment opens each claim block. CLP02 carries the claim status code, which drives your posting decision:

Code 1 = processed as primary
Code 2 = processed as secondary
Code 3 = processed as tertiary
Code 4 = denied
Code 19 = processed as primary, forwarded to additional payer(s)

CLP04 is the actual payment amount for that claim. The CAS (Claim Adjustment) segment follows, listing each adjustment with a Claim Adjustment Reason Code (CARC) and dollar amount. CARCs explain why the payer paid less (or nothing), and they must be standardized codes, not proprietary ones, under HIPAA.

Service-line detail: SVC and REF*6R

SVC segments break the payment down to individual procedure lines. Each SVC line can carry its own CAS adjustments, giving you line-level denial detail rather than just a claim-level summary. The REF segment with qualifier 6R carries the line item control number from the original 837 claim, which is how your system matches each ERA service line back to the billed charge. Missing or swapped REF*6R values are a frequent cause of posting mismatches in PM systems.

Provider-level adjustments: PLB

The PLB (Provider-Level Adjustment) segment sits outside the claim loops and captures adjustments that apply to the provider as a whole: interest, recoupments, capitation payments, or prior-period corrections. Because PLB entries are not tied to a specific claim, homegrown parsers often overlook them, and that omission is the most common reason an ERA deposit fails to tie out to posted claim payments.

How do the 837 and 835 work together in the revenue cycle?

The 837 and 835 are two sides of the same transaction: the 837 is what you send, and the 835 is what comes back.

The 837 (Health Care Claim) carries everything the payer needs to adjudicate: patient demographics, diagnosis codes, procedure codes, billed charges, and provider identifiers. The 835 returns the adjudication result: what was allowed, what was adjusted, and what was denied. Think of the 837 as the question and the 835 as the answer.

A standard workflow runs like this:

Eligibility verification confirms coverage before the encounter.
The 837 claim is submitted to the payer (directly or via clearinghouse).
The payer adjudicates the claim against its contract and coverage rules.
On the next payment run, the payer generates an 835 ERA and, if paying electronically, an EFT deposit.
Your system receives the 835, matches it to the EFT using the TRN, and posts the payment.

The identifiers that travel between transactions are what make reconciliation possible. The payer’s claim control number (ICN or DCN) appears in both the 837 acknowledgment and the 835 CLP segment. The patient control number (your internal claim ID) appears in CLP01. The line item control number in REF*6R maps back to the 837 SV1 line. Consistent, accurate mapping of these identifiers across your PM system is what separates a clean auto-post from a manual exception queue.

What standards and operating rules govern the 835?

Compliance here is not optional, and the deadlines have already passed.

The adopted X12 standard

HHS designates the ERA content standard as ASC X12N 835 Version 005010X221 (V5010). This is the technical specification that defines every segment, loop, data element, and situational rule in a compliant ERA file. The X12 publication is the authoritative reference for implementation.

CAQH CORE operating rules and the January 1, 2014 mandate

CAQH CORE’s EFT & ERA operating rules cover infrastructure requirements, reassociation procedures, CARC/RARC usage, and provider enrollment practices. These rules were adopted by CMS and became mandatory for covered entities on January 1, 2014. The mandate requires that the TRN segment be present in the CCD+ addenda to support EFT-to-ERA reassociation. If your payer enrollments predate 2014 and were never updated, it’s worth confirming TRN linkage is active.

Key compliance figure: EFT & ERA operating rules became mandatory January 1, 2014, requiring TRN presence in CCD+ addenda for all covered entities.

CARC and RARC requirements under HIPAA

HIPAA prohibits payers from using proprietary adjustment codes in ERAs. Every adjustment must be explained using CARCs maintained by X12 and RARCs (Remittance Advice Remark Codes) maintained by CMS. This standardization is what makes cross-payer CARC mapping possible in your PM system. When you encounter an unfamiliar code, the HIPAA compliance framework requires it to be a published X12 or CMS code, not a payer invention.

Pro Tip: Even with full V5010 compliance, payers retain latitude on situational data elements. Always pull the payer’s companion guide before going live with a new trading partner. A staging test with real sample files will surface mapping gaps that no spec document predicts.

How do you use TRN reassociation and automation to post payments reliably?

Reassociation is the process of matching the TRN in the 835 to the trace number in the bank’s CCD+ addenda record, confirming that a specific ERA corresponds to a specific EFT deposit. It is the highest-impact automation step you can implement for reducing manual deposit reconciliation.

Here is the step-by-step process:

Confirm BPR02 and TRN02. When the 835 arrives, read BPR02 for the total payment amount and TRN02 for the trace number. These are your anchor values.
Match TRN02 to the CCD+ addenda. Your bank’s ACH addenda record carries the same trace number. Confirm the match before processing any claim-level data.
Parse CLP, SVC, and CAS values. Work through each claim block: read CLP04 for the payment, CAS for adjustments, and SVC for line-level detail.
Apply contract and patient-responsibility logic. Contractual adjustments (CARC CO-45, for example) reduce the balance to zero; patient-responsibility amounts (CARC PR-1, PR-2, PR-3) move to the patient ledger.
Account for PLB before posting totals. Sum all CLP04 values, then add or subtract PLB entries. The result must equal BPR02. If it doesn’t, stop and investigate PLB before posting.

The balancing rule in plain terms: BPR02 (total EFT payment) = sum of all CLP04 payments ± PLB adjustments. Missing PLB entries are the most common cause of ERA-to-deposit non-tie-outs.

Pro Tip: Route PLB entries and unmatched TRN cases to a dedicated low-volume exception queue rather than halting the entire posting run. Most of your volume will post cleanly; the exception queue keeps exceptions visible without creating a bottleneck.

For your implementation checklist:

Confirm payer enrollments include TRN linkage in the CCD+ addenda.
Test with a minimum of five sample remittances per payer before going live.
Validate all CARC/RARC mappings in a staging environment.
Set a baseline auto-post rate and track it weekly after go-live.
Monitor for new payer pattern changes with a daily exception report.

What causes 835 reconciliation failures and how do you fix them?

Most reconciliation problems trace back to a handful of repeating patterns. Knowing the pattern tells you exactly where to look.

Missing TRN in the CCD+ addenda. The ERA arrives but the bank record has no trace number, so reassociation fails. The fix is to contact the payer’s EDI team and request that TRN be included in the addenda per the CAQH CORE operating rules. Document the request; payers are required to comply.

Mismatched deposit totals. BPR02 doesn’t equal your sum of posted claims. Before assuming a data error, search the 835 for PLB segments. A single recoupment or interest entry can account for the entire discrepancy.

Unexpected CARC or RARC codes. A new code appears that your system maps to “unknown,” and the posting logic stalls. Pull the payer’s companion guide and the current CMS RARC list to identify the code, then update your mapping table before the next remittance cycle.

REF*6R mismatches. The line item control number in the ERA doesn’t match what your 837 sent. This usually means the clearinghouse or PM system altered the control number in transit. Trace the value from the original 837 through the 999 acknowledgment to the 835 to find where it changed.

Pro Tip: Add an automated validation check on every 835 import that flags files where BPR02 does not equal the sum of CLP04 values plus PLB. Running this check at ingestion, before any data reaches the ledger, catches structural problems in seconds rather than hours.

For a quick investigation checklist:

Verify BPR02 against the sum of all CLP04 amounts.
Search the full file for PLB segments and account for each entry.
Match REF control numbers back to the originating 837 line items.
Pull the payer companion guide for any situational rules affecting the affected claims.
Review the CGS Medicare companion guide as a reference model for access controls and trading partner responsibilities.

What features should your ERA/EFT software actually have?

Evaluating a PM system, clearinghouse, or RCM hub for 835 handling comes down to a specific feature set. Generic “ERA support” is not enough.

Core parsing and posting capabilities:

TRN-based EFT reassociation with automatic match confirmation
Full PLB parsing and ledger posting (not just claim-level data)
CLP/CAS/SVC parsing with a maintained CARC/RARC code mapping table
REF*6R line-level matching back to the originating 837
Audit trail with rollback capability for corrected postings

Integration and testing requirements:

A staging or sandbox environment for payer-specific testing before production
Companion-guide support per payer, with a process for updating situational rules
Exception routing with configurable workflows (PLB queue, unmatched TRN queue)
Reconciliation dashboards showing auto-post rates, exception volumes, and daily tie-out status

Security and compliance controls:

Encryption in transit (TLS) and at rest for all ERA files
Role-based access controls limiting ERA data to authorized billing staff
A signed Business Associate Agreement (BAA) with any vendor that handles ERA files under HIPAA
Audit logs that satisfy the HIPAA Security Rule’s access and integrity requirements

Pro Tip: Ask any vendor for their auto-post rate benchmarks across their client base and how they handle payer companion-guide updates. A vendor that pushes mapping updates proactively is worth more than one that waits for you to report a problem.

For ERA enrollment and compliance guidance, the setup process matters as much as the software itself.

Why correct ERA handling is the difference between cash flow and chaos

From One For All Medical Billing’s perspective, the 835 is where revenue cycle management either works or quietly fails. We’ve seen practices with technically compliant 837 submissions and solid denial management still struggle with cash flow, and in most cases the root cause is downstream: ERAs arriving without TRN linkage, PLB entries sitting unposted, or CARC mappings that haven’t been updated since a payer changed its companion guide two years ago.

The practices that post payments fastest are not necessarily the ones with the most sophisticated PM systems. They are the ones that treat the 835 as a structured data file to be parsed precisely, not a PDF to be read manually. With over 20 years of experience in revenue cycle management, One For All Medical Billing has deployed TRN reassociation and PLB handling across practices of every size, from single-provider clinics to multi-site health systems. The result is consistently fewer posting exceptions, faster cash application, and a cleaner A/R picture.

The operational discipline required here is not glamorous, but it is precise. Getting the EFT authorization and enrollment right from the start prevents most of the problems described in this guide.

How One For All Medical Billing handles ERA/EFT automation for you

Practices that want faster cash posting without building an internal EDI team have a direct path forward. One For All Medical Billing manages the full ERA/EFT automation cycle: payer enrollment with TRN linkage confirmed, CARC/RARC mapping built and maintained per payer companion guide, auto-post configuration tested in staging before production, and daily reconciliation with a managed exception workflow for PLB and unmatched TRN cases.

The result for providers is measurable: lower manual posting hours, same-day cash application on clean remittances, and denial routing that starts from accurate adjustment codes rather than guesswork. With specialty-specific billing expertise across Oklahoma and nationwide, the team understands the payer patterns that trip up generic automation. Contact One For All Medical Billing to discuss ERA/EFT enrollment and get your reconciliation process running at full speed.

Sources

For technical specifications, operating rules, and implementation guidance, these are the primary references:

FAQ

What is an 835 remittance advice?

An 835 remittance advice is the HIPAA-standard X12 transaction (ASC X12 835 V5010) that a health plan sends to a provider to explain how a claim was paid, adjusted, or denied. It is the electronic equivalent of an Explanation of Benefits for providers, and it drives payment posting and reconciliation in the revenue cycle.

What is the difference between an 837 and an 835 in medical billing?

The 837 is the claim transaction a provider submits to a payer with billed charges and clinical data; the 835 is the adjudication response the payer returns with payment amounts, adjustments, and denial reasons. They are linked by shared identifiers including the payer claim control number and the patient control number.

What type of information does an 835 transaction contain?

An 835 contains the total EFT payment amount (BPR02), the reassociation trace number (TRN), claim-level status and payment data (CLP), line-level service adjustments (SVC/CAS), standardized CARC and RARC codes explaining each adjustment, and provider-level adjustments (PLB) for items like recoupments or interest.

Is remittance advice legally required under HIPAA?

Covered entities are required to use the ASC X12 835 V5010 standard for electronic remittance advice transactions under HIPAA, and the CAQH CORE EFT & ERA operating rules, mandatory since January 1, 2014, require TRN linkage in CCD+ addenda. Providers are not required to accept payment electronically, but payers who pay electronically must comply with these standards.

Why does my ERA deposit not match my posted payments?

The most common cause is unposted PLB entries. The balancing rule requires that BPR02 equals the sum of all CLP04 claim payments plus or minus any PLB adjustments. Search the full 835 file for PLB segments and account for each before concluding there is a data error.