Matching Electronic Payments to Remittances and Deposits
An electronic funds transfer can reach a healthcare organization’s bank before the remittance is available in the posting system. Sometimes the ERA arrives first. In other cases, the payment and remittance are present, but their totals appear to disagree. Each situation raises a different question: Was the money received, can it be matched to the correct remittance, and has the financial activity been accounted for accurately?
EFT reconciliation connects actual bank deposits with payer payment information. Deposit balancing confirms that those amounts are accounted for within the organization’s cash and posting records. Although these activities are closely related, they are not interchangeable. A deposit can be correctly identified and still contain claim-level posting errors. Conversely, claim payments may appear accurate in a remittance while a provider-level offset changes the money actually deposited.
A deposit amount isn't proof that every claim payment was applied correctly, and a balanced posting batch doesn't automatically explain the cash. Matching the bank, payment detail, remittance, and ledger requires separate checks and a traceable resolution for exceptions.
Two Balances, Two Questions
Electronic funds transfer (EFT) is an electronic movement of funds from a payer to a provider’s financial institution. An electronic remittance advice (ERA), usually an X12 835 transaction, explains the adjudication and financial adjustments accompanying payer claim processing. One ERA may contain multiple claim payments and provider-level adjustments. [1]
EFT reconciliation associates the bank payment with its corresponding remittance and validates the expected cash amount. Deposit balancing reconciles money received against cash application, outstanding exceptions, and the relevant banking or accounting control totals. Organizations may use separate teams for treasury, cash application, payment posting, and accounting, so the exact handoffs vary.
Four different amounts to keep separate
- Billed charges: the organization’s submitted amounts for services, not necessarily what the payer owes.
- Claim-level payments: amounts assigned to the claims adjudicated in the remittance.
- Provider-level adjustments (PLBs): items such as recoupments or interest that can change the net payment independently of claim-level paid totals.
- Actual EFT amount: the cash issued through the payment transaction, which should ultimately be traced to the corresponding bank receipt.
For a standard 835, the basic reconciliation relationship is net payment = sum of claim-level paid amounts minus the signed sum of provider-level adjustments. A positive PLB amount generally reduces the EFT; a negative PLB amount generally increases it. The exact signs and transaction details must be interpreted in context, especially in exported spreadsheets. CMS describes this balancing relationship for Medicare remittances. [2]
When and Where Reconciliation Happens
Reconciliation begins when a payer issues payment, a bank reports a credit, or the organization receives the corresponding remittance. The frequency may be daily, by bank settlement, by payer, or by accounting period. The important operational distinction is that the bank’s posted date, the payer’s effective payment date, the ERA production date, and the posting date may not be identical.
The teams involved
Staff should work within their assigned permissions. Finding a variance does not authorize an analyst to create a patient balance, reverse an adjustment, write off a payment, or modify an interface mapping.
The Records, Fields, and Identifiers Used
A reconciliation generally uses a bank activity report, an EFT or ACH deposit record, the ERA or remittance image, a cash application batch, and exception or reconciliation reports. A robust audit trail links the records rather than relying on the payer name and matching dollar amount alone.
Under federal EFT/ERA operating rules, the standardized CCD+Addenda payment can carry the TRN information used to match the electronic funds transfer to its remittance. This matching process is called reassociation. The trace information in the ACH addenda and associated 835 should correspond. [3]
Why trace numbers matter
A payer may issue several EFTs with the same rounded amount, or multiple payments may be deposited on the same day. Comparing dollar values alone can create a false match. Use the available trace, payee, payment date, bank account, and remittance identifiers together. If the TRN is absent from the view used by posting staff, check whether it is available from an authorized ACH addenda or EDI report before labeling the payment unmatched.
A Practical EFT-to-Deposit Reconciliation Workflow
- Identify the bank receipt. Retrieve the posted amount, date, payer/originator details, destination account, and available ACH trace/addenda under authorized access. Confirm whether the credit is final or pending.
- Find the matching ERA. Search by payer, payee, trace, payment date, and amount. Confirm that the file is for the same provider or organizational entity.
- Check the remittance control. Review BPR payment amount, remittance totals, and all PLB items. Do not assume the sum of visible claim payments is the expected bank deposit.
- Reconcile claim and line arithmetic. Verify that billed charges, adjustments, and payments balance where applicable. Use the actual remittance records, including negative amounts and any reported reversals.
- Prepare the posting batch. Match claim transactions to authorized accounts; separate unmapped, missing, duplicate, or held records rather than fabricating entries.
- Compare cash and application totals. Validate posted claim payments plus appropriately recorded provider-level and unapplied/clearing activity against the EFT and accounting controls. Avoid double-counting the same PLB as both a deduction from cash and a patient-account payment.
- Resolve or route exceptions. Research the source records, identify ownership, and document any pending items. Some differences are timing, some are remittance structure, and some are actual errors.
- Verify completion. Confirm the bank, remittance, posting, and relevant ledger controls agree or that any remaining difference is explicitly documented, assigned, and carried forward under policy.
An important principle is to distinguish a balanced batch from a fully resolved batch. A control report can net to zero even when a deposit was attached to the wrong remittance or two claim-level errors offset each other.
Worked Example: Claim Payments Differ From the EFT
Illustrative example: A remittance contains three claims and a provider-level recoupment. The analyst sees $475 in claim payments, but the bank received $395.
Calculation: $175 + $200 + $100 = $475. Then $475 − $80 = $395. The $80 difference isn't automatically missing revenue or patient responsibility. It is a separately reported provider-level reduction that must be accounted for in the designated cash and adjustment workflow.
The analyst would record the three claim payments to the correct accounts and route or record the recoupment under the organization’s approved PLB controls. Before linking the $80 to a specific earlier claim, the analyst needs evidence identifying the underlying recovery. The PLB code and reference should be retained for follow-up. [1]
What changes if a PLB is negative?
For illustration, a −$15 signed PLB representing an applicable payment addition would increase cash: $475 − (−$15) = $490. An Excel report might instead display a deduction as negative or use debit and credit columns. Confirm the source-file convention before making any formula; changing signs to reach the bank total without understanding the source isn't reconciliation.
Worked Example: Line Balancing and the Wrong Adjustment
Illustrative example: One service line is billed at $300. The payer reports $180 paid, a $90 contractual adjustment, and $30 in patient coinsurance. The line is mathematically balanced: $300 − $90 − $30 = $180.
If a posting export mistakenly shifts $20 from CO to PR, the line might still balance numerically, but the patient balance would be overstated. Financial reconciliation must therefore verify classification as well as arithmetic. The 835 service-line balancing rule relates the original service charge, signed CAS adjustments, and paid amount. [4]
The reviewer should compare the original 835 segments against the displayed EOB, payer instructions, and system mapping. A balance difference isn't permission to move contractual obligations into patient responsibility. If the original 835 appears inconsistent, retain the source and escalate for payer or EDI review as appropriate.
Worked Example: Two Errors That Cancel Out
Illustrative control scenario: A $620 EFT is correctly matched to the ERA, and the posting batch also totals $620. But one payment was posted $25 too high, while another was posted $25 too low.
The control total balances but the accounts are wrong. Match individual claim and service payments, not only total deposits. Investigate whether the difference came from a manual keying error, line mapping, payment split, or misidentified account. Correct the specific misapplications through authorized procedures, then confirm both individual account balances and the $620 cash control.
Unmatched EFTs, Missing ERAs, and Timing Differences
Not every discrepancy signals a financial loss. A remittance might not yet have reached the clearinghouse, a file may be held in an EDI queue, or a bank credit may settle on a different business day than the payer’s payment date. These possibilities must be checked before posting an unmatched amount as income or returning funds.
Reversals, takebacks, and retractions
A payer may reverse a previously adjudicated payment and replace it with different adjudication details. Depending on the payer’s remittance, the corrected activity can include negative claim payments, associated adjustments, and separate provider-level recoupment transactions. Follow the original remittance references and the actual EFT rather than treating every negative line as a new patient debt. Detailed PLB and recoupment analysis is covered in its own foundational guide.
A repeated takeback-and-reapply pattern deserves special attention. Validate whether both sides of the correction are present, whether the same amount is being withheld more than once, and whether posting automation is writing off unrelated balances. An analyst can identify the pattern, quantify its effect, and escalate it, even when investigation or configuration changes belong to another team.
Deposit Balancing, Controls, and Period-End Reconciliation
Posting balances, bank balances, and general ledger balances may operate at different levels. A daily cash report may track remittance deposits by payer, while accounting monitors bank clearing accounts and month-end entries. A payment that is properly held as unapplied cash should not disappear from deposit control simply because it could not yet be applied to a patient account.
A practical deposit-control schedule
This is an accounted-for deposit, not a fully reconciled remittance population. The $250 remains an exception until it is matched, supported, posted, and cleared through the appropriate workflow. For period end, unresolved items should have traceable owners, aging, supporting records, and disposition rules. A zero difference in a workbook does not remove the responsibility to resolve open items.
Controls that catch recurring failures
- Completeness: compare bank credits to received remittances and expected file counts.
- Uniqueness: use payment and transaction identifiers to detect duplicate EFT or ERA application.
- Accuracy: validate signed PLBs, line adjustments, and payment mapping against original source data.
- Timeliness: age unmatched deposits and unresolved remittance exceptions separately.
- Separation of duties: require appropriate approvals for manual adjustments, reassignments, and write-offs.
- Evidence: maintain trace information, source-file versions, exception comments, and correction audit histories.
Common Reconciliation Mistakes and How to Prevent Them
Balancing to the wrong target
If an ERA lists $475 in claim payments but the actual EFT is $395 after an $80 PLB, a posting workflow that forces the claims to total $395 without handling the PLB separately may corrupt the patient-account posting. The bank receipt is the hard cash target; claim and provider adjustments explain how that target was reached.
Treating a remittance display as the source of truth
A payer portal summary or printed EOB can omit detail visible in the raw 835, or a converted report can invert signs. Compare the original remittance transaction, bank activity, and posting logs before correcting records. Where the payer’s actual transaction is inconsistent, preserve the discrepancy and obtain clarification.
Posting an informational amount as cash
Some remittance data communicates earlier payments, informational adjustments, or other amounts that should not become new current-period cash entries. Automated posting rules must distinguish reportable information from payable activity. When a bot appears to post informational-only amounts, isolate examples and validate whether the issue is a data interpretation error or a configuration failure.
Using unsupported patient or contractual adjustments
It may be tempting to move a variance into PR or CO because the remaining amount then looks correct. That changes account responsibility without proof. Verify the appropriate payer adjustment groups and reasons, contract and benefit implications, and organizational correction permissions. [1]
Assuming one payer deposit equals one remittance file
Payment-to-remittance relationships must be verified with the available identifiers and documented processing behavior. A remittance may carry numerous claims, and internal processing can separate a transaction into workqueues or files. Investigate the actual grouping rather than using payer name plus amount as the only key.
Practical Reconciliation Checklist
- ☐ Confirm actual bank receipt, account, settlement date, and amount.
- ☐ Match the deposit to an ERA using trace and payee identifiers wherever available.
- ☐ Verify BPR/net payment and whether the payment method explains expected bank activity.
- ☐ Sum claim payments and account for all signed provider-level adjustments.
- ☐ Validate service/claim charge, payment, and adjustment balances as applicable.
- ☐ Check reversals, negative amounts, and claim reprocessing history.
- ☐ Match individual claim payments to correct patient accounts and service lines.
- ☐ Identify unapplied, duplicate, rejected, or held items separately from posted payments.
- ☐ Ensure clearing-account and deposit totals tie to the verified EFT.
- ☐ Record unresolved exceptions with evidence, ownership, follow-up, and aging.
- ☐ Validate corrections and preserve an auditable history before closing the batch.
Connecting Reconciliation to the Rest of the Revenue Cycle
Reliable deposit reconciliation supports cash reporting, patient balance accuracy, accounts receivable, payer recovery investigations, and financial close. Its limits are equally important: balancing the EFT does not prove that a payer allowed the correct contract amount, that a recoupment was justified, or that every claim was coded correctly. Those questions require additional evidence and may belong to managed care, revenue integrity, or other specialized teams.
The next guide on CARC, RARC, and Adjustment Codes will explain the reasons behind specific payer adjustments. The dedicated guide to PLBs, Recoupments, and Retractions will address provider-level recovery patterns in greater depth. For this article, the central goal is to account for every dollar, preserve the classification of every adjustment, and identify unresolved differences before they affect downstream records.
References and Further Learning
The sources below support the technical transaction and reconciliation principles explained here. Medicare-specific examples must be evaluated within their applicable program scope, and organizations should verify current payer guidance and internal controls before applying any workflow.
References
Additional Learning
Educational Disclaimer
Revenue Cycle Uncovered is an independent educational resource. Content is provided for general informational purposes and does not represent the policies, practices, or positions of any employer or organization. Workflows, payer requirements, regulations, and operational practices may vary. Information should be independently verified when applied to specific situations.