> ## 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.

# Why MSO-PC banking is different

> Multi-entity by construction, payer money that must land in PC-controlled accounts, management fee flows that need documentation, and reconciliation that ties remittances to deposits.

Banking for an MSO-PC group is not ordinary business banking with more accounts. It is **multi-entity by regulatory construction**, the destination of payer money is a **compliance question**, intercompany transfers require **documentation to be legitimate**, and reconciliation has to tie **835 remittances to bank deposits** rather than simply balancing a statement.

Generalist banks solve none of this, because none of it is a banking problem from their side.

## Four ways it differs

### 1. Multi-entity isn't a preference — it's the structure

An ordinary company with ten locations has one legal entity and can have one bank account. An MSO-PC group with ten locations across ten states has **eleven legal entities**, each requiring its own accounts, because professional entities are state-chartered and cannot travel. See [One PC per state](/concepts/entities/one-pc-per-state).

Separation between them isn't optional tidiness. Commingled funds undermine corporate separateness, which is precisely what a CPOM challenge attacks and what a diligence process examines.

### 2. Payer money must land where the PC controls it

Three rules converge on the PC operating account:

**CPOM.** The PC earns the professional fee. Payer revenue landing in an MSO account hands a regulator the argument that a lay entity is collecting for the practice of medicine. Control of receipts is one of the functional indicia examined. See [The CPOM doctrine](/concepts/model/cpom).

**Payer contracts and Medicare rules.** Payers pay the entity they contracted with, at the Tax ID they enrolled. Medicare's payment and reassignment rules constrain how payments can be directed, which is why lenders structure healthcare AR facilities around provider-controlled accounts rather than direct assignment.

**Corporate separateness.** Basic, and load-bearing here.

**An MSO with unilateral withdrawal authority over the PC's operating account is a CPOM self-audit finding**, even if the money movement itself is legitimate. The control is the problem, not just the transfers. See [Move money between PC and MSO](/guides/banking/move-money-mso-pc).

### 3. Intercompany flows need paper to be real

In an ordinary company, moving money between accounts is a bookkeeping entry. Here, the monthly management fee is a **transaction between two separately owned legal entities**, and its legitimacy depends on documentation:

* The MSO issues an **actual invoice**
* The PC **pays it** from its own account, on its own authority, after covering clinical obligations
* Both entities **book it** at identical amounts
* The invoice is **filed** in both entities' records

A standing sweep with no invoice is the fact pattern that gets structures recharacterized. See [Intercompany money movement](/concepts/banking/intercompany-money-movement).

### 4. Reconciliation ties three systems, not two

Ordinary reconciliation matches the ledger to the bank statement. Healthcare reconciliation is three-way:

```mermaid theme={null}
graph LR
    A[PM system<br/>posted payments] <--> B[835 remittances]
    B <--> C[Bank deposits]
    A <--> C
```

And the middle link is genuinely hard, because **one 835 is not one bank deposit**: deposits aggregate remittances, PLB adjustments shift totals, and card settlements arrive net of fees. Matching runs on the **TRN reassociation trace number**, not on amounts. See [The 835](/concepts/payments/understanding-835s).

## What breaks at scale

The problems are mild at one PC and compound linearly:

| At 1 PC                           | At 10 PCs                               |
| --------------------------------- | --------------------------------------- |
| 2–3 accounts                      | 20–30 accounts                          |
| 2 bank logins                     | 11+ logins with separate credentials    |
| 1 KYB onboarding                  | 11, each a fresh packet                 |
| 1 management fee transfer monthly | 10, each needing an invoice             |
| 1 intercompany balance pair       | 10 pairs to reconcile                   |
| Cash position: check one account  | Log into eleven and build a spreadsheet |
| 1 set of check stock and signers  | 10, each drawn on its own account       |

None of this is intellectually hard. All of it consumes a finance team's month, and the failure mode is quiet degradation in reconciliation quality, which surfaces during a raise, not during operations.

## What generalist banks don't do

Being fair to banks: these are not deficiencies so much as things outside what a commercial bank is built to provide.

**Entity-scoped access.** A bank relationship is per legal entity. There is no cross-entity view because, to the bank, there is no relationship between your entities. Eleven logins is the product working as designed.

**No structural awareness.** No generalist bank knows what CPOM-clean money movement is, why the PC's account must not be sweepable by the MSO, or how a management fee transfer differs from an owner draw. The compliance logic lives entirely in your head.

**Repeated onboarding friction.** Every new PC is a fresh KYB with the same packet at the same friction as the first. Beneficial ownership questionnaires don't anticipate a structure where the 100% owner is a clinician whose economics are governed by a contract with someone else.

**Reconciliation ends at the statement.** Banks reconcile deposits. They do not reassociate deposits to 835s, because 835s aren't theirs.

<Info>
  **Lemma** builds banking specifically for this shape of problem, one interface across every PC and the MSO, designed around MSO-PC compliance patterns rather than adapted to them. Named here under our [mention policy](/reference/appendix/about-lemma); the rest of this section is written to be useful regardless of where you bank, and the account structures and reconciliation discipline described in [Account structures](/concepts/banking/account-structures) and [Move money between PC and MSO](/guides/banking/move-money-mso-pc) work at any institution.
</Info>

## What good looks like

Regardless of provider:

* **Every entity has its own accounts**, with no shared accounts anywhere
* **The PC's signer is the PC's licensed officer**
* **Operations has read-only access** for reconciliation
* **No standing sweep authority** from MSO over PC
* **Every intercompany transfer has an invoice**
* **Deposits reconcile to 835s by TRN**, daily
* **A consistent naming convention** across entities and accounts
* **A per-entity setup runbook** so entity twelve takes as long as entity two


## Related topics

- [Step 7: Open bank accounts](/start/zero-to-paid/open-bank-accounts.md)
- [Banking and books for entity #3 (and #4, and #12…)](/start/second-state/banking-and-books.md)
- [Open bank accounts for your MSO and PCs](/guides/banking/open-bank-accounts.md)
- [Structure accounts across your entities](/guides/banking/structure-accounts-across-entities.md)
- [Move money between PC and MSO (the right way)](/guides/banking/move-money-mso-pc.md)
- [Account structures for MSO-PC groups](/concepts/banking/account-structures.md)
- [Intercompany money movement](/concepts/banking/intercompany-money-movement.md)
- [Payment rails 101 (ACH, checks, wires, RTP, cards)](/concepts/banking/payment-rails-101.md)
- [KYB/KYC document checklist for account opening](/reference/banking/kyb-document-checklist.md)
- [Per-entity account & access checklist](/reference/banking/per-entity-account-checklist.md)