> ## 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. # Account structures for MSO-PC groups > Patterns from one PC to thirty: minimal, standard, and advanced account maps, FBO pitfalls, and the visibility-versus-control tradeoff. An account structure is the map of which bank accounts exist, which entity owns each, who can move money from it, and what flows through it. In an MSO-PC group the map is constrained by compliance before it is optimized for convenience: the PC must control the accounts that receive payer money. ## Three patterns ### Minimal, one PC, launch stage | Entity | Account | Purpose | | ------ | --------- | ------------------------------------------------------------------------------- | | PC | Operating | Payer EFTs and patient payments in; clinical payroll and the management fee out | | MSO | Operating | Management fee in; all non-clinical expenses out | Two accounts. Sufficient to be compliant and to launch. ### Standard, one to five PCs, operating | Entity | Account | Purpose | | ------- | ----------------- | ---------------------------------------------------------------- | | Each PC | Operating | Revenue in, clinical payroll and fee out | | MSO | Operating | Fee income and general operations | | MSO | Payroll | Funded from operating before each run; limits exposure | | MSO | Tax reserve | Estimated taxes set aside so they aren't spent | | MSO | Savings / reserve | Runway, and a cushion against events like a clearinghouse outage | The MSO's payroll and tax accounts are ordinary financial hygiene, not compliance requirements. They exist so payroll funds aren't accidentally spent and tax money isn't mistaken for working capital. ### Advanced, five to thirty PCs | Entity | Account | Purpose | | ----------- | ------------------------------ | --------------------------------------------------------------------------------------------------------- | | Each PC | Operating | Revenue in | | Each PC | Payroll | Clinical payroll segregation | | Each PC | Refund / disbursement clearing | Patient refunds drawn from a controlled account | | MSO | Operating | Fee income | | MSO | Payroll | Non-clinical | | MSO | Tax reserve | | | MSO | Reserve / treasury | | | Holding co. | Operating | Sweeping profits out of MSOs when you have a holding company with multiple portfolio companies underneath | At this scale the driver is **operational control**, not compliance: segregated accounts limit the blast radius of an error, make reconciliation cleaner, and let you delegate access narrowly. **Every account you add is another reconciliation, another set of signers, and another statement.** Add accounts because they solve a specific problem, not because a structure diagram looks tidy. ## Signers and access The part that founders find uncomfortable and must not solve by cheating. | Role | PC accounts | MSO accounts | | ------------------------------- | ---------------------------------------------------------- | ------------ | | **Signer / authorized user** | The PC's licensed officer, the clinician-owner | MSO officers | | **Read-only** | Bookkeeper, controller, the operator who reconciles | Same | | **Initiator (where supported)** | Operations may prepare payments for the officer's approval | MSO staff | | **Approver** | The PC's officer | MSO officer | The pattern that works: **operations prepares, the PC's officer approves.** The MSA authorizes the MSO to provide financial administration services including preparing payments; the authority to release funds stays with the PC. **Never give the MSO unilateral withdrawal authority over a PC account.** Not a standing ACH debit authorization, not a signer role for an MSO executive, not shared credentials. The money movement may be entirely legitimate; the *control* is the finding. ## FBO and pooled account pitfalls Occasionally someone proposes a **for-benefit-of (FBO)** structure: one account holding funds for multiple PCs with sub-ledger accounting. This is generally a bad idea here, for reasons that stack: 1. **The PC doesn't control its own receipts**, the exact CPOM problem the account structure is supposed to solve. 2. **Commingling.** Sub-ledgers are not separate legal ownership. 3. **Payer enrollment mismatch.** Each PC's EFT enrollment specifies an account; pooling means the named account isn't the PC's. 4. **Diligence and audit friction.** Reconstructing per-entity cash from a pooled account is exactly the work an auditor will make you do. 5. **Money transmission questions.** Holding funds for the benefit of others can raise licensing issues depending on who operates the pool. The legitimate version of "one view across many accounts" is **consolidated visibility over separately owned accounts**, not a single pooled account. Visibility can be shared; ownership cannot. ## Visibility vs control The genuine tension in multi-entity treasury. | | More control to the PC | More visibility to the MSO | | ------- | ----------------------------------------------------- | ------------------------------------------------------------------ | | **Pro** | Cleaner CPOM posture; clearer separateness | Faster operations; better cash management; earlier error detection | | **Con** | Slower; depends on a clinician who is seeing patients | Erodes the separateness the structure depends on | The resolution is that these are **different axes, and only one of them is a compliance question.** Read-only visibility across all entities creates no CPOM exposure — nobody's clinical judgment or receipts are controlled by someone seeing a balance. Withdrawal authority is the constrained thing. So: **maximize visibility, constrain control.** Give the MSO's finance team read access to everything and withdrawal authority over nothing on the PC side. ## Naming conventions Decide once, never deviate. A workable pattern: ```text theme={null} [Brand] [State] PC, Operating [Brand] [State] PC, Payroll [Brand] [State] PC, Refunds [Brand] MSO, Operating [Brand] MSO, Payroll [Brand] MSO, Tax Reserve ``` This matters more than it sounds. Consistent naming is what makes a thirty-account list readable, makes reconciliation scriptable, and prevents the error where someone pays a Colorado expense from the Arizona account because the names were ambiguous. ## Cash concentration, carefully Groups with meaningful balances want to concentrate idle cash for yield. The constraints: * **PC cash can move to the MSO only as a management fee or a documented loan repayment**, never as an undocumented transfer * **Each PC must retain enough** to cover clinical payroll and its direct obligations * **Any concentration structure must not give the MSO withdrawal authority** over PC accounts Any automated cash sweeps need to give the physician on file for the PC the ability to turn off the cash sweep without approval from anyone in the MSO. The compliant approach is an **invoiced monthly fee**, sized so the PC retains an appropriate working balance, with any surplus addressed through a documented mechanism rather than an automated pull. ## Related topics - [Structure accounts across your entities](/guides/banking/structure-accounts-across-entities.md) - [Open bank accounts for your MSO and PCs](/guides/banking/open-bank-accounts.md) - [Move money between PC and MSO (the right way)](/guides/banking/move-money-mso-pc.md) - [Why MSO-PC banking is different](/concepts/banking/why-healthcare-banking-is-different.md) - [Intercompany money movement](/concepts/banking/intercompany-money-movement.md) - [Per-entity account & access checklist](/reference/banking/per-entity-account-checklist.md) - [KYB/KYC document checklist for account opening](/reference/banking/kyb-document-checklist.md)