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

# Reconcile payments daily

> Reconcile the PMS day sheet, 835 remittances, and bank deposits while accounting for card settlement timing and fee netting.

**Daily reconciliation** matches what the PMS day sheet posted, what the 835s reported, and what reached the bank. A short daily review reduces the volume of unresolved differences at month-end and can catch a payment routed to the wrong entity before the error repeats.

The **day sheet** is the PMS end-of-day report of production, collections, and adjustments by provider. Close it each evening, then reconcile the reported collections to remittances and bank activity. Without that match, the day sheet is only an operational report.

## 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["PMS day sheet<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="Close yesterday's day sheet and total the posted payments">
    Separate payer and patient payments. Within patient collections, distinguish checkout payments, treatment-plan deposits, payment-plan installments, and membership charges so each flow can be traced.
  </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**         | May be deposited several days after the remittance and are still used by some smaller dental payers |
    | **Virtual credit cards** | Arrive as card transactions, not EFTs                                                               |
    | **Membership billing**   | Recurring charges settle with card batches, not against any claim                                   |
    | **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 dental 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 do not appear separately
* **Net of fees:** the deposit equals gross transactions less processing fees
* **T+1 or T+2:** the deposit arrives one or two days 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 PMS'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 a dental support organization (DSO) 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

Reconcile each entity every business day. Confirm whether the bank provides a consolidated view across legal entities or requires separate access for each account.

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 dental banking is different](/concepts/banking/why-dental-banking-is-different).

## Verify it worked

* [ ] Day sheet closed daily and tied to the bank, 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  | A large backlog of unexplained differences at month-end |
| Not scanning for payer debits     | Unexplained cash movements                              |
| Aggregate-only reconciliation     | Cross-entity routing errors undetected                  |