Set up EDI, ERA, and EFT with each payer

EDI authorizes your clearinghouse to submit claims on the PC’s behalf. ERA tells the payer where to deliver 835 remittance advice. EFT tells the payer which bank account to deposit into. They are three separate enrollments with three separate failure modes, and confusing them is the most common enrollment error in a growing group.

The three, side by side

	EDI	ERA	EFT
Authorizes	Your clearinghouse to submit 837 claims	The payer to send 835s to a specific receiver	The payer to deposit to a specific account
Identified by	Submitter ID	Receiver ID (usually your clearinghouse)	Bank routing and account number
If missing	Claims rejected at the front door	Payments arrive with no electronic explanation	Paper checks, or virtual credit cards
Set up via	Clearinghouse, usually	Clearinghouse or payer portal	Payer portal, or CAQH EnrollHub

Prerequisites

Payer contract executed
The PC’s W-9, with the legal name matching the CP 575 exactly
Type 2 NPI
A voided check or bank letter for the PC’s operating account
Your clearinghouse’s submitter and receiver IDs

Steps

Get your submitter and receiver IDs from the clearinghouse

Different per clearinghouse. In a multi-PC group, confirm whether each entity gets its own submitter configuration — it should, so claims can’t go out under the wrong Tax ID.

Complete EDI enrollment per payer

Most clearinghouses handle this on your behalf; this is one of the highest-value services they provide. Some payers require a signed authorization form directly.Track status per payer. “Submitted” is not “approved,” and claims sent before approval reject.

Complete ERA enrollment per payer

Specify the receiver, your clearinghouse, so 835s route there.ERA and EFT are separate and route independently. The most common enrollment error in a growing group: the payment goes to the right bank account while the 835 keeps flowing to a clearinghouse you stopped using. You receive money you cannot post.When you change clearinghouses, re-enroll ERA with every payer. This is a project, not a checkbox, and skipping it means months of manual posting.

Complete EFT enrollment per payer

Bank details for the PC’s operating account.Options:

The payer’s own portal or form, most common
CAQH EnrollHub — submit bank details once for participating payers
CMS-588 for Medicare

Never point EFT at the MSO’s account. It happens when whoever fills the form uses “the company account.” Unwinding it means re-enrolling EFT with every affected payer, weeks per payer, plus the CPOM problem of payer revenue landing in the lay entity. See Why MSO-PC banking is different.

Convert any virtual credit card payer to EFT

If a payer defaults to sending virtual card numbers, complete their EFT enrollment and ask explicitly to opt out of the card program, in writing. VCCs cost you 2–3% of the payment. See Paper checks and virtual credit cards.

Test before you rely on it

Submit a test or first live claim and confirm a clean 277CA
Confirm the first 835 arrives at your clearinghouse and posts
Confirm the first EFT lands in the correct account
Confirm the 835 and the deposit reassociate by TRN

All four, per payer. A payer where three of four work is a payer that will cost you reconciliation time indefinitely.

Record everything in the enrollment grid

Per entity, per payer: submitter ID, EDI status, ERA status and receiver, EFT status and account, and the date each was confirmed.

Multi-entity considerations

Each PC is a separate Tax ID and needs its own set of all three, with every payer.

At 1 PC × 8 payers	At 10 PCs × 8 payers
8 EDI enrollments	80
8 ERA enrollments	80
8 EFT enrollments	80
24 total	240 total

This is the arithmetic that makes clearinghouse enrollment support quality the criterion worth weighting most heavily when choosing one, not claim transmission price. See Choose a clearinghouse.

Also: configure each PC’s submitter separately so a misconfiguration can’t send one entity’s claims under another’s Tax ID. That is a compliance problem, not just a billing error.

Verify it worked

EDI approved (not merely submitted) per payer
ERA enrolled and pointing at your current clearinghouse
EFT enrolled to the PC’s account
Any VCC payer converted to EFT
First claim accepted at 277CA
First 835 received and posted
First EFT landed in the correct account
835 and deposit reassociate by TRN
Enrollment grid updated per entity per payer

Common failure modes

Failure	Consequence
Assuming EDI enrollment covers ERA and EFT	Payments with no remittance; paper checks
ERA pointing at a former clearinghouse	Money you cannot post
EFT pointed at the MSO account	CPOM problem plus weeks of re-enrollment
W-9 name not matching the CP 575	Enrollment rejected
Claims submitted before EDI approval	Front-door rejections
Not re-enrolling ERA after a clearinghouse change	Months of manual posting
Accepting VCCs passively	2–3% of remittances lost, permanently
Shared submitter config across entities	Claims under the wrong Tax ID

Formation & Corporate

Agreements

Credentialing & Payer Enrollment

Billing Operations

Patient Payments & Refunds

Banking & Finance

Compliance Tasks

Set up EDI, ERA, and EFT with each payer

The three, side by side

Prerequisites

Steps

Multi-entity considerations

Verify it worked

Common failure modes

​The three, side by side

​Prerequisites

​Steps

​Multi-entity considerations

​Verify it worked

​Common failure modes

The three, side by side

Prerequisites

Steps

Multi-entity considerations

Verify it worked

Common failure modes