> ## Documentation Index
> Fetch the complete documentation index at: https://mso.getlemma.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Set up EDI, ERA, and EFT with each payer

> Three separate enrollments people assume are one: claim submission authorization, remittance delivery, and where the money lands.

**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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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](/concepts/banking/why-healthcare-banking-is-different).
  </Step>

  <Step title="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](/concepts/payments/paper-checks-and-vcc).
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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**        |

<Tip>
  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](/guides/billing/choose-a-clearinghouse).
</Tip>

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             |


## Related topics

- [Step 8: Enroll with your first payer](/start/zero-to-paid/enroll-with-your-first-payer.md)
- [Choose a clearinghouse](/guides/billing/choose-a-clearinghouse.md)
- [Post payments from 835s](/guides/billing/post-payments-from-835s.md)
- [Reconcile payments daily](/guides/payments/reconcile-daily-payments.md)
- [The 835: how payers answer](/concepts/payments/understanding-835s.md)
- [Paper checks, lockboxes, and virtual credit cards from payers](/concepts/payments/paper-checks-and-vcc.md)
- [Payer enrollment & submission links](/reference/payers/enrollment-links.md)