To match ABA ERA EFT and bank deposit evidence, connect the remittance trace to the related payment mechanism and verify that the actual deposit reached the authorized account. Balance claim and provider-level details to the ERA total, then balance that amount to the EFT or check and bank record. Track zero-payment remittances, unmatched deposits, fees, returns, reversals, and timing differences separately.

Define Hana's ERA, EFT, and deposit reassociation control

Hana's register follows one remittance and payment pair from receipt through bank confirmation and ledger posting. It preserves the raw ERA, ACH addenda or check evidence, trace, settlement date, bank amount, payer, entity, claims, PLB items, and every exception. Deposit recognition occurs only after identity and amount reconcile.

Build the payment reassociation register

Record payer and payee entity; ERA control; receipt time; BPR amount; TRN trace; payment method; ACH addenda or check number; expected date; bank account alias; bank settlement date and amount; return or reversal; claim total; PLB total; zero-payment state; fee or offset; match method; variance; owner; posting batch; reviewer; close date; and evidence retention. Structured fields support identity, versioning, clocks, comparison, access, routing, holds, measurement, correction, retesting, and close. Narrative preserves clinical meaning, uncertainty, disagreement, family communication, privacy, legal deferral, and why the authorized owner chose the final path.

Run Hana's workflow

Hana matches trace and amount first, then checks payer, payee, account, date, and payment method. She balances all claim and PLB detail to the ERA and compares the result with the actual bank record. One deposit is never allocated across remittances by guess. Timing differences remain open with a next check date.

Keep decision rights with qualified owners

An ERA and an EFT are separate artifacts. A deposit proves money movement but cannot explain claim adjustments. A balanced ERA cannot prove that money reached the correct account. Accounting owns bank and ledger recognition, while RCM owns claim mapping and privacy staff control remittance access.

Work through Hana's fictional example

Hana locks 20 fictional remittance events. Fourteen match payer, payee, trace, amount, date, claims, PLB, account, and deposit. Two deposits settle a day later, one ERA has zero payment, one trace is truncated, one deposit reaches an old account, and one PLB prevents balance. Four resolve. Two stay open. This synthetic cohort tests workflow and arithmetic only. It creates no coding, coverage, authorization, payment, patient-balance, privacy, accounting, or legal conclusion for a real person, provider, plan, claim, or deposit.

Calculate Hana's measures

Initial payment reassociation is 14 of 20 events, or 70.0%. Eighteen reach verified deposit, valid zero-payment disposition, or documented hold, or 90.0%. ERAs, payment mechanisms, deposits, claims, PLB items, and journal entries remain separate units.

Address the main ERA, EFT, and deposit reassociation risk

Posting from the bank feed alone can leave adjustments, patient responsibility, and claim balances wrong. Posting from the ERA alone can recognize cash that never settled or reached an unauthorized account.

Test the payment reassociation register against exceptions

Hana tests same-dollar deposits, truncated trace, zero-payment ERA, returned ACH, old bank account, check conversion, PLB, offset, settlement delay, duplicate import, and wrong payee entity. Each test retains the initial evidence, source version, expected result, actual result, affected unit, safeguard, owner, correction, retest, and disposition. Failed and held cases stay inside the predeclared cohort.

Document the stop condition

Hold cash allocation or close when trace, payer, payee, bank account, amount, remittance balance, deposit status, or ownership is unresolved. Security and treasury owners investigate unexpected account changes or returns before the payment record is released.

Hand off open work clearly

Hana's handoff contains the ERA control, TRN trace, payment record, authorized bank account alias, settlement evidence, balance proof, PLB treatment, open variance, owner, and next bank or payer check. The receiver verifies the evidence in both RCM and accounting systems and records access-limited links rather than copying bank details broadly.

Maintain Hana's control over time

Hana reviews payment reassociation after payer, bank, clearinghouse, treasury, ERA-parser, or ledger changes. Her monthly control samples ordinary, zero-payment, PLB, delayed, and returned transactions. It compares due remittances with matched deposits and ages every unresolved item through the financial close.

Run Hana's independent check

Hana assigns a reviewer who did not build the payment reassociation register. The reviewer reconstructs the ERA, EFT, and deposit reassociation state, source, decision, calculation, correction, and close from retained evidence. Earlier versions, failed records, and holds remain available. A missing population, hidden exception, unexplained value, overwritten history, or decision by an unauthorized role fails the check.

Use the adopted claim standard as the starting boundary

Current 45 CFR 162.1102 identifies the adopted professional-claim standard. CMS's professional-claim page provides Medicare electronic and paper context, while the NUCC Version 13.0 manual governs its paper-form scope. Hana checks the actual transaction, service date, payer, product, and receiver before applying any ERA, EFT, and deposit reassociation rule.

Keep companion and claim-status evidence route specific

CMS says its Medicare FFS companion guides supplement the X12 TR3 for named Medicare routes. The administrative-simplification claim-status page identifies 276 and 277 status transactions, and the March 2026 Medicare status guide illustrates Medicare-specific stages. Hana records which source and receiver produced each state in the payment reassociation register.

Read ERA adjustments at the correct level

The current CMS ERA and EFT page describes an ERA as a health plan's explanation of claim payment and explains CARC and RARC use. The Medicare remittance page separates claim, service-line, and provider-level adjustments and explains PR, CO, and PLB in Medicare scope. Hana retains those levels instead of moving an unexplained amount into another account.

Reassociate remittance and payment with evidence

The CMS EFT page describes Medicare direct deposit and reconciliation with bank statements. X12 RFI 2075 explains the 835 TR3's one-to-one relationship between a payment mechanism and an 835, with a zero-payment 835 as the stated exception. Hana uses trace, amount, payee, date, and bank evidence for the payment reassociation register.

Treat responsibility codes as adjudication evidence

X12 RFI 2048 explains that an adjustment assigned to the patient uses PR and an adjustment arising from a provider contractual or regulatory obligation uses CO within the 835 guide. CMS's Medicare remittance guidance says Medicare beneficiaries may be billed only for adjustments carrying PR. Hana also verifies the actual program, contract, secondary coverage, notices, and protections before a balance action.

Limit payment data to authorized use

HHS treatment, payment, and health-care-operations guidance describes HIPAA pathways for covered entities. Its minimum-necessary guidance generally applies to payment uses, disclosures, and requests. Hana records entity status, purpose, recipient, workforce role, and scoped data access for the payment reassociation register, with more protective law or contract requirements evaluated separately.

Preserve clinical and compliance authority

The CASP public summary and BACB Ethics Code provide scoped clinical and covered-professional context. Clinical record authorship and care decisions stay with qualified roles. The OIG GCPG is voluntary and nonbinding general guidance. Hana uses these sources for control design without presenting them as a universal ERA, EFT, and deposit reassociation mandate or payment guarantee.

Related resources

Sources