ERA and EFT Enrollment

When a payer decides a batch of claims it produces two things and sends them by two routes: the money, and an explanation of what the money was for. The explanation is the remittance advice — in electronic form, the ASC X12 835 transaction, usually called the ERA. The money, when it moves electronically, arrives as an EFT deposit. Neither is delivered electronically until the practice has told the payer to do so, and that instruction is the enrollment this article is about.

It is the on-ramp to the rest of the Payments & Posting section. An account cannot auto-post a remittance it never enrolled to receive, cannot reconcile a deposit it still gets by paper check, and works from a mailed explanation of benefits instead of a structured file. Enrollment is what turns the paper version of the money story into the electronic one that everything downstream assumes.

The single most useful thing to know is that ERA and EFT are separate authorizations that happen to be requested together. They answer different questions, and a practice can end up with one without the other.

EFT enrollment

Authorizes the payer to deposit the payment directly into a designated bank account. It travels the same automated clearing house network that handles direct deposit generally, and the authorization is deposit-only — the plan can credit the account, not withdraw from it. This is the enrollment that carries the practice's banking details.

ERA enrollment

Tells the payer to send the 835 electronically and where to deliver it — to the practice directly, or to a clearinghouse or billing service acting on its behalf. This is the enrollment that decides which system ends up holding the file that payment posting reads.

Because they are separate, they can be delivered to separate places — and often the point is to make sure they are not. The deposit lands in the bank; the remittance lands wherever ERA enrollment pointed it. If those two destinations are not coordinated, the practice has a deposit in one hand and, somewhere else entirely, the explanation of which claims it paid. Keeping the two enrollments aligned is what keeps the money and its explanation findable together.

There is no national registry that turns electronic payment on everywhere at once. Enrollment is per payer: a practice completes it with each health plan it bills, and a plan a practice has never enrolled with will keep paying by check and mailing paper remittances no matter how much of the rest of the practice is electronic.

That makes enrollment ongoing operational work rather than a one-time task. A new payer relationship is not fully live until its ERA and EFT are enrolled; a new bank account, a change of clearinghouse, or a reorganization can require re-enrolling with payers that were already set up. The enrollments are tied to the practice's identifiers — its NPI and tax identification number — so when those or the banking details change, the enrollments built on them have to be revisited.

An EFT enrollment collects the banking information a deposit needs — the account and routing numbers — tied to the practice's identity, and the rule text's own example of elements requested together is a bank account number alongside a taxpayer identification number. An ERA enrollment collects where the 835 should be delivered and the identifiers the payer will match it against. Historically every payer asked for this in its own way, with its own form and its own names for the same fields, which made enrolling across many payers slow and error-prone.

A federal operating rule set narrowed that variance. Under Section 1104 of the Affordable Care Act, the Department of Health and Human Services adopted operating rules for the EFT and ERA transactions — authored by CAQH CORE and mandatory for HIPAA-covered health plans — and two of them, the EFT Enrollment Data Rule and the ERA Enrollment Data Rule, define a maximum standard set of data elements a plan may require to enroll a provider. The set is a ceiling, not a single national form: a plan may ask for the standard elements and no more, but it still runs its own enrollment process, so the forms are more alike than they used to be without being identical.

Because the enrollment carries real banking details, the account is validated before money starts flowing. CMS, for its own program, describes a verification period in which the bank account is confirmed by the financial institution before any direct deposits are made — a check that the account exists and belongs to the payee, done once, up front. Exactly how and how long each payer verifies varies, so the thing to know is that a live-looking enrollment is not the same as a verified one, and the first real deposit is the confirmation that the account cleared.

Medicare shows the general shape in concrete form. EFT is set up on the CMS-588 Electronic Funds Transfer Authorization Agreement, which authorizes the program to deposit payments into the practice's account — and, again, is explicitly not provider enrollment. For Medicare it is not optional: federal regulation requires providers and suppliers to receive payment by EFT at enrollment and revalidation, and the CMS-588 is uploaded through PECOS or sent to the Medicare contractor, with one on file for each contractor a practice bills.

The ERA side of Medicare is handled through that same Medicare Administrative Contractor — its electronic data interchange department — where a practice enrolls to receive the 835 and designates whether it arrives directly or through a clearinghouse or billing agent. The specific form names and steps differ by contractor, so the reliable move is to start from the MAC that serves the practice's jurisdiction rather than a single national instruction. Which contractor that is can be found with the MAC jurisdiction lookup.

The payment and its explanation travel separately — the EFT to the bank, the 835 to wherever ERA enrollment sent it — and they have to be put back together before either is fully useful. That pairing is the reason to enroll for both, and to enroll for them as a matched set: the 835 carries a reassociation trace number, and the same number rides with the EFT deposit, so the remittance and the money can be matched mechanically rather than by hunting for a deposit that looks about the right size.

Enrolling for EFT without ERA, or for ERA without EFT, or sending each to a place that never sees the other, is what defeats that trace. The deposit arrives with no structured explanation to post against, or the remittance arrives with no matching deposit to prove, and the reconciliation that should take a moment becomes a search. Using that trace to tie the two together — and what to do when they do not pair — is Payment Reconciliation's subject; where the trace lives inside the file is part of How to Read an 835; and the trace itself — how one number rides both the deposit and the 835, and why it most often fails to reach the practice at all — is EFT and ERA Reassociation. The point here is only that both enrollments, aimed at the same place, are what make that pairing possible in the first place.

Get the two enrollments right and the rest of the section has something to work with: a structured remittance to post, a deposit to reconcile it against, and — for the patient's side of the same decision — the EOB that the plan sends the member. Enrollment is the quiet first step that decides whether all of that arrives as data or as paper.