> ## Documentation Index
> Fetch the complete documentation index at: https://dso.getlemma.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Set up required EDI, ERA, and EFT connections
> Distinguish claim submission, electronic remittance, electronic payment, and attachment functions, then configure each at the grain the payer, product, payee, and trading-partner route requires.
**Claim EDI**, **electronic remittance advice (ERA)**, and **electronic funds transfer (EFT)** are different functions. Claim EDI maps an electronic claim route and trading partner; ERA is the X12 835 explanation of adjudication sent to an authorized receiver; EFT is the payment instruction to the enrolled payee's financial institution.3 A payer may use separate forms, one combined workflow, a clearinghouse authorization, an open payer-ID route, or a delegated enrollment utility. Distinct functions do not imply a fixed number of applications. Dental attachments are another route to configure only where the payer and claim require supporting material.
## The three, side by side
| | EDI | ERA | EFT |
| ------------------------- | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
| **Function** | Routes an applicable 837D from a submitter/trading partner to the payer ID and product | Routes an X12 835 to the provider's authorized receiver | Sends an ACH payment to the enrolled payee account using the adopted EFT standard |
| **Key mappings** | Payer ID, product, submitter or trading-partner ID, billing and rendering identifiers, and sometimes location | Health plan, receiver, payee/provider identifiers, product, and effective date | Health plan, enrolled payee, tax/NPI identifiers required by the plan, bank account, validation, and effective date |
| **If not configured** | Follow the payer's permitted alternative; an unauthorized electronic route may reject | Remittance may arrive through another electronic receiver or on paper | Payment may use a permitted alternative such as check or VCC unless the provider requests standard ACH EFT |
| **Common setup channels** | Clearinghouse, payer portal/form, or another trading partner | Clearinghouse, payer portal/form, or enrollment utility | Payer portal/form or participating enrollment utility |
## Prerequisites
* The contract, state enrollment, out-of-network submission authority, or other basis for the specific claim route
* The applicable billing or payee entity's W-9 and tax documentation, with consistent legal-business data
* The billing, rendering, pay-to, location, and NPI/TIN relationships the payer requires; a Type 2 NPI only where the enrolled organization is part of the route
* Bank evidence for the legally permitted, payer-enrolled payee account
* A clearinghouse or other trading partner chosen that supports the transactions and payer routes you need, including **837D** for routine dental-benefit claims. See [Choose a clearinghouse](/guides/billing/choose-a-clearinghouse).
## Steps
Identify the clearinghouse or other trading partner and its submitter and receiver identifiers. A shared submitter can sometimes carry claims for multiple enrolled billing entities; other routes require an entity-specific authorization. Either design needs controls that populate the correct payer ID, product, billing provider, rendering provider, location, and tax identifiers.
For each intended electronic claim route, ask the clearinghouse and payer whether enrollment or authorization is required. Some payer IDs are available through the trading partner without a provider-specific EDI application. Others require a signed form, portal approval, or linkage for particular billing entities or products. Confirm that the route supports the transaction being sent. Routine dental-benefit claims usually use the **837D**, while some covered medical or institutional pathways use the 837P or 837I.
Track the payer ID, product, enrolled identifiers, submission status, approval if required, and usable effective date. “Submitted” is not “approved,” but do not invent an approval step for an open route that does not have one.
A payer may request radiographs, periodontal charts, narratives, photos, or other material for a particular claim, authorization, or audit. The accepted route varies: a payer portal, clearinghouse-integrated attachment, **Vyne Dental's FastAttach** (the NEA network), DentalXChange, mail, or another specified channel. An NEA number in a claim is one supported workflow, not a universal dental-claim requirement.1
Configure only the routes the target payers accept and test retrieval or receipt. A March 2026 HIPAA rule adopts the **X12 275** attachment standard with a **May 26, 2028 compliance date**; that standard changes covered electronic exchanges but does not by itself guarantee that a current portal or vendor disappears. See [Dental attachments](/reference/edi/dental-attachments).2
For each health plan from which you request standard ERA, identify the authorized **receiver** and the provider/payee identifiers the plan uses. The receiver may be the current clearinghouse, another vendor, or a direct endpoint.
**ERA and EFT are separate functions and can route independently.** A payment can reach the intended bank while the 835 continues to a former receiver, creating manual retrieval and posting work.
When you change clearinghouses, inventory the ERA relationships that point to the former receiver and follow each affected health plan's change process. Some require a new enrollment; others support a receiver update through a clearinghouse, utility, or portal. Do not assume that changing claim EDI automatically moves ERA.
Enroll the account of the legally permitted payee that the health plan recognizes for the product and identifiers. In a conventional dentist-owned PC/MSO structure, that will generally be the professional entity's account; in another lawful ownership and enrollment model, determine the correct payee from the governing state law, payer record, and contract rather than the acronym “PC.”
Options:
* **The health plan's own portal or form**; for Delta, start with the member company identified for the service location and product
* **CAQH EnrollHub**, which lets you submit bank details once for participating payers
* **CMS-588**, if the group [bills Medicare](/guides/enrollment/enroll-in-medicare) at all
Do not route professional revenue to a support-company account merely because it is the group's operating account. Match the bank account to the authorized payer payee and the state's ownership/control rules. An Arizona registered lay-owned dental business, for example, does not share the same structural premise as a dentist-owned PC/MSO arrangement. See [Why DSO banking is different](/concepts/banking/why-dental-banking-is-different).
If a health plan sends a virtual credit card, identify the card terms and request standard ACH EFT if that is the desired method. CMS states that a health plan must comply when a provider requests the adopted ACH EFT standard, subject to completing that plan's enrollment process.4 Card acceptance may create merchant fees, but the rate is processor- and agreement-specific. See [Paper checks and virtual credit cards](/concepts/payments/paper-checks-and-vcc).
Test the functions actually configured:
* For electronic claims, confirm acceptance using the acknowledgement the route supports, such as a **277CA**, and then verify payer adjudication
* When a claim or authorization needs an attachment, confirm the receiving party can retrieve or associate it
* If ERA was elected, confirm the first 835 reaches the authorized receiver and can post
* If EFT was elected or required, confirm the payment reaches the enrolled payee account
* For paired ERA and ACH EFT, confirm reassociation using the matching **TRN** data3
Record each relationship at its actual grain: state/program, health plan or payer, product, payer ID, contract party, billing/pay-to entity, rendering provider, location, trading partner, claim route, attachment route, ERA receiver, EFT payee account, statuses, and effective dates.
## Multi-entity considerations
Do not use a theoretical three-by-payer-by-PC enrollment count. First determine what the health plan and trading partner key each function to:
| Function | Possible operational grain | Control to document |
| ----------- | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Claim EDI | Trading partner and payer ID, with provider-specific authorization only where required | Which products, billing/rendering identifiers, and locations may use the route |
| ERA | Health plan plus receiver and the provider/payee identifiers used by its enrollment process | Where each product's 835 is delivered and from what effective date |
| EFT | Health plan plus enrolled payee and the identifiers/bank validation it requires | Which legal payee owns the account and which products/payments the approval covers |
| Attachments | Payer, product, claim or authorization, and accepted submission channel | How the attachment is associated and receipt/retrieval is proven |
Use the completed matrix to evaluate clearinghouse route coverage, payer-ID accuracy, enrollment support, acknowledgement visibility, and ERA migration capability. See [Choose a clearinghouse](/guides/billing/choose-a-clearinghouse).
A group may use one trading-partner submitter configuration across multiple billing entities if the route permits it, but the claim generator still needs controls that prevent one entity's TIN/NPI, rendering provider, location, or payer product from leaking into another's claim.
## Verify it worked
* [ ] Each intended electronic claim route documented; approval obtained where required; correct 837 transaction confirmed
* [ ] Each required attachment route configured and receipt/retrieval tested
* [ ] Each elected ERA relationship points to the intended current receiver
* [ ] Each elected or required EFT relationship points to the authorized payee account
* [ ] VCC payment methods reviewed and ACH EFT requested where desired
* [ ] First electronic claim accepted through the acknowledgement the route supports and adjudication verified
* [ ] For each elected ERA route, first 835 received and posted
* [ ] For each elected or required EFT route, first payment landed in the correct account
* [ ] For paired ERA and ACH EFT, 835 and deposit reassociate by TRN
* [ ] Relationship grid updated at the applicable program, payer, product, entity/provider, location, and transaction-route grain
## Common failure modes
| Failure | Consequence |
| ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| Assuming claim EDI setup also configures ERA and EFT | Misrouted or non-electronic remittance/payment |
| No accepted attachment route for a payer that requests documentation | Affected claim or authorization pends, rejects, or denies |
| ERA pointing at a former clearinghouse | Remittance retrieval and posting become manual until the receiver is corrected |
| EFT pointed at an entity that is not the authorized payee | Contract, enrollment, reconciliation, and potentially CPOD problems |
| Required W-9 or tax data do not match the legal-business record used for enrollment | Enrollment can delay or reject pending correction |
| Claims submitted before a required EDI approval or effective date | Front-door rejection or payer enrollment edit |
| Failing to update affected ERA receiver relationships after a clearinghouse change | Remittances continue to the former receiver or arrive on paper |
| Accepting VCCs without reviewing terms or requesting the desired method | Avoidable merchant fees and harder reconciliation |
| Shared submitter config without entity/provider/location controls | Claims under the wrong identifiers |
## Sources
1. Vyne Dental, [FastAttach](https://vynedental.com/fastattach/); DentalXChange, [attachment service](https://payconnect.dentalxchange.com/provider/claimconnect/AttachmentPage); payer-side example: GEHA, [NEA FastAttach instructions](https://www.geha.com/en/resource-center/provider-resources/nea-fastattach).
2. Administrative Simplification: Adoption of Standards for Health Care Claims Attachments Transactions, 91 FR 14350 (final rule, March 24, 2026; X12N 275 v6020, 277 RFAI; compliance May 26, 2028): [Federal Register](https://www.federalregister.gov/documents/2026/03/24/2026-05676/administrative-simplification-adoption-of-standards-for-health-care-claims-attachments-transactions).
3. CMS, [Health Care Payment and Remittance Advice and EFT](https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/transactions/health-care-payment-remittance-advice-electronic-funds-transfer) and [payment/remittance reassociation basics (PDF)](https://www.cms.gov/files/document/adminsimp-payment-remittance-reassociation-fact-sheet.pdf).
4. CMS, [HIPAA Administrative Simplification FAQs (PDF)](https://www.cms.gov/files/document/gl-2022-04-go-answers-faq.pdf). Providers may request standard ACH EFT and X12 835 ERA, while health-plan enrollment remains required for the selected transactions.