EFT and ERA Reassociation

When a payer pays electronically, it sends two things by two routes: the money as an EFT — an electronic transfer through the banking system — and the explanation as the 835, the electronic remittance advice that itemizes which claims the money paid and how. They do not arrive together the way a paper check once arrived stapled to its paper remittance. Reassociation is the act of putting the two back together: matching a specific deposit to the specific remittance that accounts for it.

It sits between three articles it is easy to confuse it with. Enrolling so a payer sends both electronically is ERA and EFT Enrollment; where the trace lives inside the file's structure is part of How to Read an 835; proving that nothing is missing across every deposit is Payment Reconciliation. This article is the narrow mechanical question in the middle — how one number rides both networks, and why it so often does not arrive.

The remittance and the money never share a path. The 835 moves through the health-care data channel — from the payer to the practice directly or by way of a clearinghouse. The money moves through the Automated Clearing House (ACH) banking network: the payer instructs its own bank, which hands the transfer to an ACH operator, which routes it to the practice's bank, which posts it to the account. Because the two paths are independent, the deposit and the remittance routinely land on different days — which is the entire reason a linking number has to exist.

The payer assigns one reassociation trace number and writes it into both transmissions. In the 835 it is the TRN segment. On the deposit it rides inside the payment format the banking system uses for these payments — a CCD+, an ACH corporate credit that carries a single addenda record — and that addenda holds the same 835 TRN segment. So the number printed in the 835's trace and the number tucked into the deposit's addenda are, by design, identical. Matching those two numbers is reassociation; everything else in this article is about whether the number actually survives the trip.

The value that does the matching is the trace number itself — conceptually the EFT's own reference number, and for a payment that still arrives as a check, the check number. It works as a key because a single 835 corresponds to exactly one payment: one remittance, one deposit, one number joining them. That one-to-one relationship is what makes a mechanical lookup possible instead of a hunt for a deposit that looks about the right size.

None of this is a convention each payer invented on its own. Under Section 1104 of the Affordable Care Act, the Department of Health and Human Services adopted a federal standard for the health-care EFT — the ACH CCD+ carrying the X12 835 TRN segment — together with a set of operating rules for the EFT and ERA transactions, authored by CAQH CORE and required of HIPAA-covered health plans. One of those, the EFT and ERA Reassociation rule, exists for no other purpose than to make the trace usable.

What it puts on the health plan is specific. The plan must carry a matching trace number on both transmissions, so the deposit and the 835 can be joined. It must release the 835 in step with the deposit's effective date, so the two do not drift so far apart in time that nobody connects them. It must give providers written procedures for researching a late or missing EFT or ERA. And — the requirement that matters most to a practice — it must tell the provider, at the point of enrollment, that the provider will need to arrange with its own bank to actually receive the trace.

Follow the trace and it survives every leg but one. The payer writes it into the deposit's addenda and into the 835. It rides the ACH network, through the payer's bank and the ACH operator, to the practice's bank, still attached to the payment. Then comes the last hop — the practice's bank telling the practice a deposit arrived — and there is no adopted standard for that step at all. What the practice sees in a bank statement, an online-banking screen, or a downloaded file is whatever the practice and its bank happened to arrange. The payment-related information in the addenda may or may not be shown, depending on the bank's capabilities and how the practice looks.

So the trace can travel correctly all the way to the practice's bank and still never reach the practice, because the bank does not pass the addenda along. The deposit then shows up as a bare dollar amount with no trace; the 835 shows up with a trace that now has nothing to match; and reassociation quietly reverts to the amount-and-date search the trace was designed to eliminate. This is the documented reason the operating rule requires plans to warn providers about their banks in the first place — most practices do not know the information has to be requested.

Timing is the second, milder failure. Even when the trace is present, the deposit and the 835 can arrive far enough apart that a practice is forced to choose between posting the remittance before the money is confirmed and holding it while the receivable ages. Keeping that gap small is the reason the rule ties the 835's release to the deposit's effective date, but a gap is normal, and the trace is what lets the two be paired whenever each one turns up.

Because the failure is on the receiving side, the fix is something a practice arranges rather than waits for. The step the operating rule points to is to ask the bank to deliver the ACH addenda — the payment-related information that carries the trace — for incoming health-care deposits, whether that comes as a bank report, through a treasury or cash-management portal, or as a file the practice or its clearinghouse can ingest. Banks differ in what they offer and in what they call it, so the reliable request is specific: the addenda record, not merely a deposit total.

Many practices receive the trace by a different route entirely — through a clearinghouse or lockbox service that pairs the 835 to the deposit on the practice's behalf and returns an already-matched file. Either way the requirement is the same: the trace has to reach the system that does the payment posting, because without it posting has nothing to match a deposit against.

When a deposit and remittance still fail to pair after the trace is being delivered, the payer's own written late-or-missing procedures are the next step — the rule requires the plan to provide them. The distinction to hold onto is which problem is in front of you: a trace that is not arriving is a receiving-side gap to fix with the bank, while a transaction that is genuinely late or missing is a payer-side question to take to the plan.

Reassociation is invisible when it works and expensive when it does not. A matched deposit-and-remittance pair is what posting consumes and what reconciliation proves. A failed match is an unposted deposit: money sitting in the bank credited to no claim, while the very claims it paid still look open and keep getting worked, followed up, refiled as duplicates, and argued over with a payer that correctly says it already paid.

That is why a topic that reads like banking trivia earns its place in the Payments & Posting section. The trace is a small thing — one number written in two places — doing a large job, and the single most useful fact about it is where it fails: not usually in the payer's file, but in whether the practice ever arranged with its bank to receive the number in the first place.