Skip to main content
Daily reconciliation matches what your PM system posted, what the 835s said, and what actually hit the bank. Fifteen minutes a day prevents month-end archaeology, and it is the control that catches misrouted payments in a multi-entity group before they compound.

Prerequisites

  • Payments posted daily
  • Read access to each entity’s bank account
  • Processor settlement reports
  • 835s retrievable from your clearinghouse

The three-way match

All three must agree. Where they don’t, the difference must be explained, not plugged.

The 15-minute daily checklist

1

Total yesterday's posted payments in the PM system

Split payer payments from patient payments.
2

Total the 835s received

Claim payments plus or minus PLB adjustments. The PLB is what makes remittance totals differ from claim-payment sums.
3

Total deposits into each PC's operating account

Payer EFTs, card settlements, and check deposits.
4

Match EFTs to 835s by TRN

Reconcile by the TRN reassociation trace number, not by dollar amount. Amount-matching works until two payers send similar amounts on the same day, then it produces silently wrong postings. The TRN is carried in the 835 and in the EFT’s ACH addenda record specifically so this match is deterministic.
5

Explain every difference

The legitimate ones:Anything you cannot explain is an error. Find it today, while the transaction is one day old.
6

Check for unexpected debits

Payers can pull money out. A payer with an ACH debit authorization can recoup an overpayment directly from the PC’s account. In a multi-entity group with no cross-entity view, an unexplained debit can sit for weeks. Scan for them daily. See Handle recoupments.
7

Confirm each entity's money landed in that entity's account

Per PC. A misconfigured EFT enrollment routing one entity’s payments to another is a commingling problem, and per-entity reconciliation is the only thing that catches it.

Card settlement mechanics

Cards reconcile differently and trip people up:
  • Batch settlement — a day’s transactions settle as one deposit, so individual payments don’t appear separately
  • Net of fees — the deposit is the gross amount minus processing fees
  • T+1 or T+2 — the deposit lands a day or two after the transaction
  • Refunds and chargebacks reduce settlements, sometimes in a later batch
Record gross revenue and fee expense separately. Booking the net deposit as revenue understates both revenue and expense, and it makes your effective processing rate invisible, which means you cannot tell whether your pricing is competitive. Reconcile the processor’s settlement report to the bank deposit, and the processor’s transaction detail to the PM system’s patient payment postings.

Returned deposits

A deposited check can be returned days later, reversing the credit and usually charging a fee. Common reasons include insufficient funds, closed account, stop payment, and stale dating. Run a returned-item review as part of the daily check. If you posted the payment on deposit, your ledger is now wrong, and in an MSO-PC group a returned deposit can cascade into a management fee transfer that shouldn’t have been made. See Payment rails 101.

Multi-entity reconciliation

Per entity, every day. Which is straightforward in principle and operationally heavy in practice, because a generalist bank scopes access per legal entity — eleven entities means eleven logins and no consolidated view. Practical mitigations:
  • Consistent account naming so a long list is scannable
  • Read-only access for the person reconciling, across every entity
  • A single reconciliation template parameterized by entity, rather than one per entity
  • Bank or platform reporting that surfaces ACH addenda data, so TRN matching can be automated
See Why MSO-PC banking is different.

Verify it worked

  • Three-way match run daily, per entity
  • EFTs matched to 835s by TRN
  • Every difference explained, none plugged
  • PLB adjustments identified and recorded
  • Card settlements reconciled; gross revenue and fees recorded separately
  • Unexpected debits scanned for daily
  • Returned items reviewed
  • Each entity’s payments confirmed landing in that entity’s account

Common failure modes