EFT and ERA Enrollment in Medical Billing: How to Get Paid Electronically

Direct answer: EFT and ERA enrollment is the payer-by-payer process that switches a practice from paper checks and paper remittances to electronic payment and electronic remittance. EFT, electronic funds transfer, is the money: the payer deposits payment directly into the practice's bank account as an ACH credit. ERA, electronic remittance advice, is the explanation: the payer sends an X12 835 file that says what was paid, what was adjusted, and what was denied, line by line, in a format billing software can post automatically. Each one is a separate enrollment, and each payer needs its own. A practice can be enrolled in EFT with a payer while its remittances from that same payer still arrive on paper, and that half-finished state is the most common enrollment mistake: the money lands in the bank, but posting stays manual because the explanation never arrived electronically.

EDI, ERA, AND EFT: THREE PIPES, THREE ENROLLMENTS

The three names sound interchangeable, and that confusion is where most setup trouble starts. EDI, electronic data interchange, is the umbrella term for exchanging health care transactions in standard electronic formats. The claim itself is the 837 file. Eligibility checks travel as a 270 inquiry and come back as a 271 response. Claim status checks are the 276/277 pair. When people say a practice is "on EDI," they usually mean it can send 837 claims electronically through a clearinghouse. ERA is one specific returning transaction: the 835 file, the electronic version of the paper explanation of benefits. EFT is the money movement alone. Enrolling for one does not enroll you for the others. EDI enrollment registers your practice, identified by its NPI and tax ID, as an electronic trading partner, usually through your clearinghouse. ERA enrollment tells the payer to stop mailing paper remittances and deliver the 835 file to your clearinghouse or software vendor instead. EFT enrollment gives the payer your bank routing and account details, plus authorization to deposit claim payments electronically. All three pay off only together: the claim leaves electronically, its outcome returns electronically, and the money lands electronically, with a traceable record at every step.

HOW AN EFT PAYMENT ACTUALLY TRAVELS

A health care EFT is an ACH credit governed by NACHA's operating rules, and the CMS reassociation fact sheet describes it in three stages. Stage 1 is the health plan initiating payment: the plan, or its business associate, instructs its financial institution to send the payment through the ACH network. This is the stage HIPAA standardizes. The adopted format is the NACHA CCD+, a Corporate Credit or Deposit entry with an addenda record, and field 3 of that addenda record carries the X12 835 TRN Reassociation Trace Number, as set out in 45 CFR 162.1602. The plan must put the same TRN on the corresponding 835. Stage 2 is bank to bank: the plan's financial institution moves the payment to yours across the ACH network, governed by NACHA's rules. Stage 3 is your bank telling you the funds were deposited. HHS adopted no standard for Stages 2 and 3, and CMS says so directly: HIPAA rules do not require financial institutions to deliver the CORE-required minimum CCD+ data in their Stage 3 deposit notification. The format of that notification is whatever you and your bank agree. Separately, the plan sends the 835, which travels its own path to your clearinghouse or directly to you, carrying the matching TRN. Your system then reassociates the two: it matches the deposit to the remittance, posts the payment, and updates the patient accounts.

THE RULES BEHIND THE FORMS

The operating rules are routinely described as "the 2014 CAQH CORE rules." More precisely, CAQH CORE approved the Phase III EFT and ERA rule set in June 2012, and the Department of Health and Human Services adopted it by regulation for use on and after 1 January 2014, under 45 CFR 162.1603. The set HHS named includes the CORE 380 EFT Enrollment Data Rule, the CORE 382 ERA Enrollment Data Rule, the CORE 360 rule on uniform use of CARCs and RARCs, the CORE 370 EFT and ERA Reassociation (CCD+/835) Rule, and the CORE 350 835 infrastructure rule. Two parts of that framework matter most at enrollment. First, CORE 380 and 382 define the maximum standard data set a health plan may require for EFT and ERA enrollment, which is why enrollment forms look broadly alike even though every plan still runs its own process. A form demanding unusual extra fields is worth questioning. Second, under 45 CFR 162.925, if an entity requests a health plan to conduct a transaction as a standard transaction, the health plan must do so, and a plan may not delay, reject, or penalize a transaction because it is a standard transaction. That obligation runs to HIPAA-covered health plans. Workers' compensation carriers, auto insurers, and liability insurers are not HIPAA covered entities, which is why a workers' comp payer can still insist on paper. Ask anyway, since many pay electronically by choice, but do not treat a refusal as a compliance failure.

THE ENROLLMENT CHECKLIST, PER PAYER

Every payer enrollment follows roughly the same sequence, even though the forms look different. Work through it in order, because the most common cause of rejection is submitting incomplete paperwork and waiting weeks to find out. First, gather your documents before you start: a current W-9, your Tax ID (TIN), a list of every NPI tied to that TIN, your practice address, and proof of your bank account, usually a voided check or a bank letter on letterhead. Second, decide on EFT-only or combined EFT and ERA. Many payers default to a combined enrollment, and separating the two later often means filing twice, so request both unless you have a specific reason not to. Third, pick your submission route. A payer portal works well for a single payer. A clearinghouse batch enrollment service, such as Change Healthcare's EERS, is faster when you are enrolling with many payers at once. Paper forms by mail or secure fax remain the fallback when a payer has no electronic option. Fourth, confirm signatory authority before you sign: payers reject forms signed by someone without authority on file, so check who is listed as an authorized signer in your existing payer credentialing records. Fifth, submit and log the confirmation: record the confirmation ID, the date, the expected completion date, and who on your team owns follow-up. Two details deserve extra care. The legal name on your bank documents must match the legal name on your W-9 exactly, because payers match your submitted bank details against the voided check or bank letter you attach, and a mismatched account name, even a missing "DBA," triggers a manual review or a flat rejection. And the remittance receiver or clearinghouse information on the form determines where the 835 file actually lands, so confirm it matches where your posting team works: an 835 delivered to a clearinghouse account nobody monitors is worse than paper. Enrollment is almost always processed at the TIN level, and most payers automatically extend EFT and ERA coverage to every NPI associated with that TIN once the TIN-level enrollment is approved. That is convenient for multi-provider practices, but it also means an error on the TIN record affects every provider under it. A change of bank account or tax ID requires re-enrollment with each plan, so treat a bank change as an enrollment project, not a formality: deposits keep going to the old account until the payer processes the change.

WHAT THE TIMELINE LOOKS LIKE

Under the CAQH CORE enrollment rules, health plans must return an electronic enrollment receipt within 24 hours and complete processing within about two weeks most of the time, with a 90 percent service-level target. Those figures come from the CORE rules themselves, not from Neximed, and they are a service-level target rather than a guarantee. Payer packets commonly cite a processing time of around 14 days. Processing time still varies by plan, so ask each plan for its stated turnaround when you submit, and diary a follow-up against that date rather than against an average from a blog. Save the submission receipt immediately: without a receipt showing your submission date, you have no way to prove you filed on time if a payment gets delayed. When a payment or remittance goes missing, work through the problem in order: verify you have a submission receipt and confirmation ID on file, contact the payer's EDI or enrollment department directly referencing that confirmation ID, check your clearinghouse dashboard for a rejection or pending status you may have missed, and call your bank to confirm whether the CCD+ addenda for that specific payment was delivered. If you email enrollment forms containing bank details and tax ID numbers, send them only to the address the payer specifies and confirm it supports secure or encrypted delivery.

THE TRN AND THE BANK GAP

The TRN, the Reassociation Trace Number, is the trace number that appears on both the EFT and the 835, and matching them is what makes automated payment posting possible. The CORE minimum reassociation data set is short: the CCD+ effective entry date, the amount, and the payment-related information field that carries the TRN. The gap that breaks reassociation is almost always at the bank, not the payer. Because HHS adopted no Stage 3 standard, CORE 370 handles it indirectly: the rule requires health plans to tell providers, at the point of EFT and ERA enrollment, that they will need to contact their own financial institution to arrange delivery of the CORE-required minimum CCD+ data elements. So the operational step most practices skip is a banking step. Call your bank's ACH or treasury operations team, not a branch teller, and ask whether they currently forward the full CCD+ addenda record to your remittance or practice management system. Some banks only show a truncated reference number in the online banking portal, which strips out the TRN detail you need. Some charge for addenda delivery or for an ACH detail report. Confirm where the addenda data lands and in what format your practice management system can ingest. Then run a test deposit with a small payer first and check that the TRN in the bank's addenda record matches the TRN in the 835 file exactly, as CMS guidance recommends before relying on auto-posting. If the reassociation fails, you want to find out before your largest payer's payments start arriving unmatched. Without the TRN, posting staff match deposits by dollar amount and date, which fails precisely when it matters: several payers depositing similar amounts on the same day. If your bank cannot forward CCD+ addenda at all, ask the payer to include additional identifying data directly in the ACH addenda record, or set up a manual reassociation workflow where staff log the payer's trace number and cross-reference it against stored 835 files.

THE TWO CLOCKS THE OPERATING RULES DEFINE

The operating rules define two timing clocks that give you defensible service expectations to hold payers to, both from CORE 370. Clock one is when the 835 must be released: under CORE 370, Requirement 4.2, a health plan must release the 835 corresponding to the EFT no sooner than three business days before the CCD+ effective entry date and no later than three business days after it. The plan must also ensure the effective entry date is a valid banking day and that the 835's BPR16 date is that same banking day. Compliance is measured in aggregate: a plan must track and audit its transactions so that at least 90 percent in each calendar month meet the timing requirement, per the CORE rule. Clock two is when a transaction counts as late or missing: Requirement 4.3 defines late or missing as a maximum elapsed time of four business days following receipt of either the EFT or the 835, and requires the plan to establish written Late/Missing EFT and ERA Transactions Resolution Procedures and deliver them to each provider enrolling for EFT and ERA. Most practices have never asked for that document. Ask at enrollment: it names the process and the contact for chasing a half-arrived payment. Build your posting queue around those two clocks. A deposit with no 835 after four business days is not a mystery to be solved by staring at the bank feed; it is a defined event with a defined escalation path.

MEDICARE IS NOT OPTIONAL

For Medicare, EFT enrollment is a requirement, not a choice. Under 42 CFR 424.510(e), providers and suppliers must agree to receive Medicare payment by electronic funds transfer at the time of enrollment, at revalidation, on a change of Medicare contractor where they were already receiving EFT, or when submitting an enrollment change request, and must submit form CMS-588 to do it. If a practice is still receiving Medicare paper payments, that is an enrollment record problem to fix, not a preference. Commercial and Medicaid plans run their own portals and forms, and what they may ask for is bounded by the CORE enrollment data rules. Medicaid managed care routes vary: some managed care organizations enroll you directly, while others require enrollment through the state Medicaid program, so establish which route applies before filing anything.

WORKED EXAMPLE, AN ILLUSTRATIVE ENROLLMENT

A three-provider family practice bills Medicare, its state Medicaid program, and two commercial plans. It enrolls all four for combined EFT and ERA in one week, submitting Medicare through form CMS-588, one commercial plan through its portal, and the other two through its clearinghouse's batch enrollment service. It logs a confirmation ID and an expected completion date for each payer. Medicare and the first commercial plan activate within about two weeks. The second commercial plan's form is rejected because the bank letter shows the practice's trade name while the W-9 shows the legal entity name, so the practice gets a corrected bank letter and resubmits. Medicaid activates EFT but the ERA still arrives on paper for one cycle, because the state requires a separate ERA activation step the practice had not completed. Meanwhile the first commercial plan's deposits arrive, but the TRN is missing from the bank feed: the bank's online portal truncates the addenda record. The practice manager calls the bank's treasury desk, arranges full addenda delivery, and from the next deposit onward the TRN matches the 835 and posting becomes automatic. The practice's register now shows four payers, four EFT enrollments, four ERA enrollments, and one bank fix, and the only payer still partly on paper is the one whose rejection was caught because the confirmation log showed it had no receipt on file.

THE UNMATCHED-DEPOSIT QUEUE

Reassociation is automatic when the TRN is present on both sides: the daily ACH deposit feed and the 835 files import, and the system matches on TRN. The workflow that matters is the exception path, and the operating rules give it a defined trigger. Run an unmatched-deposit queue with four states. Deposit received, no 835 yet: usually normal inside the window, since the plan may release the 835 up to three business days after the effective entry date; hold, and escalate once four business days have elapsed. Deposit with no TRN in the bank feed: a Stage 3 problem, meaning your bank is not passing addenda data; the owner is the practice manager, and the fix is the bank treasury desk, not the payer. 835 received, no deposit: a payment initiation issue, or a deposit posted to another account; use the plan's late or missing resolution procedure. TRN present on both but the values disagree: a plan-side data problem; raise it with the plan citing the reassociation rule. Four business days is the escalation trigger, not a judgment call. Collect each plan's written late or missing resolution procedures at enrollment and store them with the payer record, so an aged unmatched deposit has a named process rather than a phone call to whoever answers.

CHECKLIST

FREQUENTLY ASKED QUESTIONS

A note on codes and coverage: This article is educational information about billing and electronic payments, not legal or compliance advice. EFT and ERA rules, payer enrollment requirements, and bank capabilities vary by payer and institution, so always verify them against the payer's guidance, the CAQH CORE rules, and your bank before acting. The timing and service-level figures in this article are from the CAQH CORE operating rules, not from Neximed, and individual payer processing times vary.

Related reading: What Is ERA 835 in Medical Billing? · What Is a Clearinghouse in Medical Billing? · How to Check Claim Status 276/277 · How to Read an Explanation of Benefits · Claim Denial Codes: Complete Guide · Claim Denial Management Workflow · Claim Rejection vs Claim Denial