Account structures for MSO-PC groups

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:

The PC doesn’t control its own receipts, the exact CPOM problem the account structure is supposed to solve.
Commingling. Sub-ledgers are not separate legal ownership.
Payer enrollment mismatch. Each PC’s EFT enrollment specifies an account; pooling means the named account isn’t the PC’s.
Diligence and audit friction. Reconstructing per-entity cash from a pooled account is exactly the work an auditor will make you do.
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:

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

The MSO-PC Model

Professional Entities

How Healthcare Gets Paid

Banking & Treasury

Finance & Investor Economics

Compliance Concepts

Industry Nuances

Account structures for MSO-PC groups

Three patterns

Minimal, one PC, launch stage

Standard, one to five PCs, operating

Advanced, five to thirty PCs

Signers and access

FBO and pooled account pitfalls

Visibility vs control

Naming conventions

Cash concentration, carefully

​Three patterns

​Minimal, one PC, launch stage

​Standard, one to five PCs, operating

​Advanced, five to thirty PCs

​Signers and access

​FBO and pooled account pitfalls

​Visibility vs control

​Naming conventions

​Cash concentration, carefully

Three patterns

Minimal, one PC, launch stage

Standard, one to five PCs, operating

Advanced, five to thirty PCs

Signers and access

FBO and pooled account pitfalls

Visibility vs control

Naming conventions

Cash concentration, carefully