> ## Documentation Index
> Fetch the complete documentation index at: https://mso.getlemma.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reconcile payments daily

> The three-way match between PM postings, 835 remittances, and bank deposits — card settlement timing, fee netting, and a 15-minute daily checklist.

**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

```mermaid theme={null}
graph LR
    A["PM system<br/>posted payments"] <--> B["835 remittances<br/>payer's record"]
    B <--> C["Bank deposits<br/>PC operating account"]
    A <--> C
```

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

## The 15-minute daily checklist

<Steps>
  <Step title="Total yesterday's posted payments in the PM system">
    Split payer payments from patient payments.
  </Step>

  <Step title="Total the 835s received">
    Claim payments **plus or minus PLB adjustments**. The PLB is what makes remittance totals differ from claim-payment sums.
  </Step>

  <Step title="Total deposits into each PC's operating account">
    Payer EFTs, card settlements, and check deposits.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Explain every difference">
    The legitimate ones:

    | Difference               | Why                                                                                     |
    | ------------------------ | --------------------------------------------------------------------------------------- |
    | **Timing**               | An 835 received today whose EFT lands in two days                                       |
    | **Card fees**            | Card deposits arrive **net**; gross revenue and fee expense must be recorded separately |
    | **PLB takebacks**        | Reduce the deposit with no claim-level entry                                            |
    | **Interest (PLB L6)**    | Increases the deposit; not claim revenue                                                |
    | **Paper checks**         | Deposited days after the remittance                                                     |
    | **Virtual credit cards** | Arrive as card transactions, not EFTs                                                   |
    | **Returned deposits**    | A check bounced days after deposit                                                      |

    Anything you cannot explain is an error. Find it today, while the transaction is one day old.
  </Step>

  <Step title="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](/guides/compliance/handle-recoupments).
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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](/concepts/banking/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](/concepts/banking/why-healthcare-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

| Failure                           | Consequence                                    |
| --------------------------------- | ---------------------------------------------- |
| Matching by amount instead of TRN | Silently wrong postings                        |
| Plugging unexplained variances    | A systemic misstatement by year end            |
| Netting card fees against revenue | Understated revenue; invisible processing cost |
| Ignoring PLB                      | Overstated revenue; reconciliation never ties  |
| Weekly or monthly reconciliation  | Month-end archaeology                          |
| Not scanning for payer debits     | Unexplained cash movements                     |
| Aggregate-only reconciliation     | Cross-entity routing errors undetected         |


## Related topics

- [Your first month-end close](/start/first-90-days/first-month-close.md)
- [Post payments from 835s](/guides/billing/post-payments-from-835s.md)
- [Set up bookkeeping and consolidation](/guides/banking/set-up-bookkeeping.md)
- [Handle recoupments and takebacks](/guides/compliance/handle-recoupments.md)
- [The 835: how payers answer](/concepts/payments/understanding-835s.md)
- [Payment rails 101 (ACH, checks, wires, RTP, cards)](/concepts/banking/payment-rails-101.md)
- [Why MSO-PC banking is different](/concepts/banking/why-healthcare-banking-is-different.md)
- [835 file anatomy](/reference/edi/835-anatomy.md)