835 ERA Processing
Post-n-Track automates 835 ERA (Electronic Remittance Advice) processing with intelligent normalization and real-time cash posting: touchless reconciliation and real-time cash flow visibility.
How Post-n-Track Handles 835 Remittances
The 835 Electronic Remittance Advice is one of healthcare's most complex and inconsistently implemented transactions. Payers interpret the standard differently, resulting in ERA files that require significant manual interpretation. Reconciling 835s against 837 claims is a labor-intensive process that delays cash posting and obscures financial visibility.
Post-n-Track normalizes 835 ERA files from payers into a consistent, easily consumable format. We apply intelligent parsing logic that handles payer-specific variations, and we enable automated matching of remittance data to the corresponding 837 claims.
- Accelerated cash posting Normalized 835s post without manual interpretation of each payer's variations.
- Fewer days in accounts receivable Remittance data matched to the corresponding 837 claims automatically.
- Real-time visibility Payment status and denial patterns as the remittances arrive.
Reassociation Is the Hard Part
The X12 835 is the Electronic Remittance Advice: the payer's explanation of how a claim was adjudicated. The 835 arrives separately from the money. Matching them, called reassociation, is done by comparing the trace number in the 835's TRN02 element to the trace number in the ACH CCD+ addenda record accompanying the EFT (electronic funds transfer). When those do not match, cash goes unposted and reconciliation reverts to manual work.
Two streams, one match
A payer sends a healthcare payment as an ACH transfer and the corresponding explanation as an X12 835. These travel different paths: the money through the banking system, the 835 through the EDI path. They arrive at different times, sometimes days apart, and nothing about the banking transaction inherently identifies which remittance it belongs to.
The link is the trace number. CAQH CORE operating rules require the payer to carry a reassociation trace number in the CCD+ addenda record of the ACH payment, and the same value in the TRN02 element of the 835. Match the two and the payment posts automatically. Fail to match and someone opens a spreadsheet.
This is the routine mechanism by which healthcare cash gets posted, and it fails often enough that "unposted cash" is a standing line item in most revenue cycle operations.
Why reassociation fails
The failure modes are unglamorous and they compound.
The bank strips the addenda. Not every bank delivers the CCD+ addenda record to the depositor by default. Some deliver it only on request, in a separate report, or in a format the practice management system cannot ingest. The trace number exists; it just never reaches the person who needs it.
Aggregated payments. One EFT covering multiple 835s, or one 835 spanning multiple payments, breaks the one-to-one assumption most posting logic makes.
Trace number formatting variance. Leading zeros, prefixes, and truncation between the banking system and the EDI path can leave two values that represent the same trace but do not compare as equal.
Timing. The 835 arrives before the money, or well after. Posting logic that assumes same-day arrival creates a backlog it then treats as an exception queue.
Payer variance. Some payers' TRN02 practice does not match the operating rule cleanly, and the receiver absorbs the difference.
What the 835 actually tells you
Beyond the payment amount, the 835 carries the reasoning. CARC (Claim Adjustment Reason Codes) state why the paid amount differs from the billed amount. RARC (Remittance Advice Remark Codes) supply supplemental explanation. Together they are the raw material of denial management, and of the appeal decision.
The 835 also carries MSP (Medicare Secondary Payer) information where Medicare is secondary, and the adjustment detail a secondary claim needs. A secondary 837 that does not accurately carry forward the primary's payment and adjustment data from the 835 will be denied, and that denial will look like a coding problem when it is actually a data carry-forward problem.
This is why 835 handling and denial management are the same problem viewed from two ends. The remittance is where the payer told you exactly why, in a structured format, and most organizations reduce it to a dollar figure and a posting.
Enrollment is a separate obstacle
EFT and ERA enrollment are governed by the CAQH CORE EFT & ERA Enrollment Data Rule (vPR.2.0), which standardizes the data elements a payer may require. In practice, enrollment remains payer-by-payer, form-by-form, and is a common reason an organization has electronic remittance from some payers and paper from others years after going electronic.
This is administrative rather than technical work, and it is the reason ERA adoption rates lag ERA capability. Any migration plan that treats EFT/ERA enrollment as an afterthought will discover it on the critical path.
Reassociation without retention
Reassociation requires comparing two identifiers. It does not require retaining the remittance payload. PNT performs reassociation as a matching function on trace values and returns the match to the receiving organization, whose own system remains the system of record for the remittance itself.
Frequently Asked Questions
What is EFT/ERA reassociation?
Reassociation is matching an ACH healthcare payment (EFT) to its corresponding Electronic Remittance Advice (X12 835). The match is made by comparing the reassociation trace number in the ACH CCD+ addenda record to the TRN02 element of the 835. Successful reassociation allows automated payment posting; failure sends the payment to manual reconciliation.
What is TRN02 in an 835?
TRN02 is the reassociation trace number data element in the X12 835. Under CAQH CORE operating rules, its value must match the trace number carried in the CCD+ addenda record of the corresponding EFT, which is what makes automated payment-to-remittance matching possible.
Why does EFT/ERA reassociation fail?
The most common causes are: the bank does not deliver the CCD+ addenda record to the depositor; one EFT covers multiple 835s or vice versa, breaking one-to-one matching; trace number formatting drifts between the banking and EDI paths (leading zeros, prefixes, truncation); the payment and remittance arrive days apart; or payer-specific TRN02 practice varies from the operating rule.
What is a CCD+ addenda record?
CCD+ is the ACH format used for healthcare payments. Its addenda record carries the reassociation trace number that links the payment to its 835. If a bank does not pass the addenda through to the depositor, the trace number never reaches the organization that needs it, and reassociation cannot be automated regardless of what the payer did correctly.
How do CARC and RARC codes relate to denials?
CARC codes state why a payment differs from the billed amount; RARC codes add supplemental explanation. Both are carried in the 835. They are the structured record of the payer's reasoning and the basis for any appeal, which is why treating the 835 as a payment amount rather than an explanation discards the most useful denial-management data available.
Why do secondary claims get denied after a primary pays?
Frequently because the primary's payment and adjustment data from the 835 was not carried forward accurately into the secondary 837. The denial presents as a coding problem but originates as a data carry-forward problem between the remittance and the secondary claim.
Workflows and Industries
Ready to talk through your use case?
Talk to a Post-n-Track specialist about your data challenges. A direct conversation, starting with what you need.