EFT vs Paper Check: The Payer Payment Conversion

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 — which is the useful way to think about it, because the federal standards only reach the first one.

Stage 1 — the health plan initiates payment. The plan (or its business associate) instructs its financial institution to send the payment through the ACH network. This is the stage HIPAA standardises: 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 (45 CFR 162.1602). The plan must put the same TRN on the corresponding 835.

Stage 2 — bank to bank. The plan's financial institution moves the payment to yours across the ACH network. HHS adopted no standard here; NACHA's rules govern.

Stage 3 — your bank tells you. Your financial institution notifies you that funds were deposited. HHS adopted no standard here either, and CMS says so in terms: HIPAA rules do not require financial institutions to deliver the CORE-required minimum CCD+ data in their Stage 3 deposit notification. The format is whatever you and your bank agree.

Separately, the plan sends the 835. The electronic remittance advice travels its own path to your clearinghouse or directly to you, carrying the matching TRN. You then reassociate: match the deposit to the remittance, post, and update patient accounts.

Two practical consequences follow. First, an ACH credit is not instantaneous — it settles on a banking day, and the CCD+ effective entry date must itself be a valid banking day. Second, and this is the one that bites, the TRN is guaranteed only as far as Stage 1. If your deposit feed arrives without it, no HIPAA rule has been broken; the fix is a conversation with your bank, not an appeal to the payer.

The operating rules are routinely described as "the 2014 CAQH CORE rules." More precisely: CAQH CORE approved the Phase III EFT & ERA rule set in June 2012, and HHS adopted it by regulation for use on and after 1 January 2014 (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 & ERA Reassociation (CCD+/835) Rule, and the CORE 350 835 infrastructure rule.

What that actually gets you, and from whom:

• A plan must conduct the transaction in the standard format when you ask it to. 45 CFR 162.925 states that 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 penalise a transaction because it is a standard transaction. That obligation runs to HIPAA-covered health plans. Workers' compensation carriers, auto and liability insurers are not HIPAA covered entities, which is exactly why a workers' comp payer can still insist on paper.
• The same TRN on both transactions. The plan puts the 835 TRN segment in field 3 of the CCD+ addenda record and the matching TRN on the 835 (CMS, HIPAA adopted standards).
• A timing window, not a delivery guarantee. See the next section.
• A standard enrollment data set. CORE 380 and 382 define the maximum standard data set a 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.

What the rules do not do: they do not bind your bank, they do not oblige a plan to tell you a payment is coming before it arrives, and they do not eliminate per-payer enrollment. You still enrol with each health plan you bill.

The TRN is the trace number that appears on both the EFT and the 835, and matching them is what makes automated payment posting possible. CORE's 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 (CMS reassociation fact sheet, June 2022). CMS's own summary is blunt about the limit — HIPAA rules do not mandate that financial institutions deliver this information in their Stage 3 deposit notification.

So the operational step most practices skip is a banking step: call the treasury desk, confirm the ACH deposit feed passes addenda data through rather than stripping it, and confirm it in the format your practice management system can ingest. Some banks charge for addenda delivery or for an ACH detail report. That is a real cost to weigh against the posting hours it saves — and it is a question your bank answers, not your payer.

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.

Most timing claims about EFT are guesses. These two are not — they are rule text, and they give you defensible service expectations to hold payers to.

Clock one: 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.

Clock two: 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.

Those two clocks are what a payment-posting queue should be built around. 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.

What we deliberately do not publish here. This page used to carry a figure for how many days a paper check costs you, a dollar range for the A/R that paper checks tie up, and a number of days that converting to EFT removes from days in A/R. None of them had a source, so they are gone. The honest version: mail transit plus manual deposit handling plainly takes longer than an ACH credit, and the size of that gap at your practice is measurable from your own data — take the remit date and the deposit date on your last hundred paper payments and compare the same pair on your EFT payers. That comparison takes an afternoon and it is worth more than any industry average, including one we might have invented for you. A/R follow-up on those slow payers is work that accounts receivable follow-up services can own either way.

Enrollment is per health plan, and it is the step that actually determines whether you are on EFT — not payer willingness. CMS states the requirement plainly: to receive EFT payments and ERAs, a provider must enrol with each health plan it bills, and every EFT and ERA enrollment process must comply with the CORE 380 and CORE 382 enrollment data rules adopted at 45 CFR 162.1603.

Medicare is not optional. 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. What they may ask for is bounded by the CORE enrollment data rules, and in practice it is the tax ID, the NPI, the bank routing and account numbers, and evidence of the account such as a voided cheque or a bank letter. Some require a notarised signature. Processing time varies by plan and we do not publish a range for it — ask the plan for its stated turnaround when you submit, and diarise a follow-up against that date rather than against an average from a blog.

The register that makes this manageable. Below is an illustrative register — the format, not real client data. Fill it from a 90-day payment report and it tells you what to work next.

Three columns do the work: whether the plan pays electronically, whether the remittance arrives electronically, and whether the TRN survives the trip to your bank statement. A plan can be green on the first two and still cost you posting time on the third.

Four reasons cover most of what is left on a paper-check list, and they need different owners.

The enrollment was never completed, or was broken by a change. A change of bank account or tax ID requires re-enrollment with each plan, and a practice that has changed banks or restructured its entity often carries a tail of paper payers because the re-enrollment work was deprioritised. This is the largest category and it is entirely within your control.

The plan's enrollment route is manual. Smaller commercial plans and some carriers still take paper enrollment forms that get lost or misrouted. Submitting is not completing — track submission dates and chase them.

Medicaid managed care routes vary. Some MCOs enrol you directly; others require enrollment through the state Medicaid program. Establish which before filing anything.

The payer is not a HIPAA covered entity. Workers' compensation and auto carriers are outside the HIPAA transaction rules, so the standard-transaction obligation in 45 CFR 162.925 does not reach them. Ask anyway — many pay electronically by choice — but do not treat a refusal as a compliance failure.

Working the list quarter by quarter clears it. We do not publish a target completion rate or a timeline for that work, because the answer depends on how many of your payers fall in the fourth category — which is a fact about your payer mix, not about your diligence.

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. Every deposit or remittance that does not auto-match lands in one of them, and each has a different owner:

Four business days is the escalation trigger, not a judgement call. CORE 370 defines late or missing as a maximum elapsed time of four business days following receipt of either transaction, and requires the plan to give each enrolling provider written resolution procedures (CORE 370, Requirement 4.3). Collect those procedures at enrollment and store them with the payer record; then an aged unmatched deposit has a named process rather than a phone call to whoever answers.

Manual matching by dollar amount should be the exception it was designed to be. When it is the default, the cause is usually the Stage 3 gap above — and that is fixable in one conversation with your bank.