How to set up per-location accounts in a DSO

As organizations scale locations, banking grows complex: each site needs distinct EFT routing, admin visibility, and reconciliation without the burden of opening dozens of separate bank accounts.

Dental and medical service organizations scale by adding locations, and the banking architecture that supports a growing DSO (opens in a new tab) has to evolve with them. Each new location creates a banking question that gets harder the more locations you have: how do you give every location its own payer EFT routing, its own visibility for the practice administrator, and its own reconciliation trail, without opening 30 separate bank accounts?

The answer is a mix of two structures: separate accounts at legal-entity boundaries, and virtual accounts inside each entity. Used correctly, a 12-location DSO runs as cleanly as a 2-location group.

What per-location banking actually needs to solve

For each location, the practice administrator and CFO usually need:

• A unique routing and account number to enroll for payer EFT, so reimbursements can be attributed to that location.
• Per-location revenue visibility for productivity tracking and compensation.
• Per-location reconciliation, so anomalies surface at the location level instead of being averaged out across the group.
• Aggregate visibility for the CFO at the group level, with the option to drill down to any individual location.

None of these strictly require a separate legal account per location. They require per-location identity to payers and per-location reporting at the bank.

Two structural patterns

DSOs typically use one of two patterns, or a hybrid:

Pattern 1: Separate legal accounts per location

Each location is set up as its own PC entity with its own bank account. CPOM-clean, but adds significant onboarding overhead. Best when each location has clinician owner separation that benefits from full legal separation.

Pattern 2: Virtual accounts per location, one underlying PC

One PC entity covers multiple physical locations. Each location gets a virtual account (unique routing, settles into the same underlying entity account) for payer EFT. Faster to set up, easier to operate, and fully compatible with productivity-based reporting.

Hybrid

Most growing DSOs use a hybrid: separate PC entities by state or geographic region, with virtual accounts covering individual locations within each PC. This balances CPOM compliance against operational simplicity.

When separate accounts per location make sense

• State CPOM rules require it. Some states are strict enough that each clinical location with its own clinician ownership needs its own PC.
• Each location has materially different clinician ownership.
• Independent payer contracts per location. Some payers contract by NPI; if each location has its own NPI, separate accounts simplify payer reconciliation.
• M&A flexibility. Separate legal accounts make it easier to sell or restructure individual locations later without disturbing the rest of the group.

When virtual accounts are the better pattern

• All locations within a PC share the same clinician ownership. CPOM is satisfied at the PC level; per-location separate accounts add no compliance value.
• Speed of expansion matters. Adding a virtual account takes a day; adding a new PC plus full account onboarding takes 5 to 10 days at a healthcare-native bank or 35 to 75 days at a generalist.
• Productivity reporting is per-location, but cash management is centralized. Virtual accounts give per-location attribution while letting the PC manage cash centrally.
• Cost. Virtual accounts at most healthcare-native banks are included; separate accounts can carry monthly fees and per-account ACH limits.

How payer EFT enrollment works per location

Each location, separate-account or virtual, files payer EFT enrollment with its unique routing and account number. The mechanics:

1. The location confirms its NPI and tax ID with each payer.
2. The location submits an EFT enrollment form with the unique routing and account number assigned by the bank (the actual entity account for separate, or the virtual account for virtual).
3. The payer processes the enrollment, typically in 30 to 60 days.
4. From that point forward, that payer routes reimbursements to that specific routing/account combination.

Practices can run all locations' enrollments in parallel. The payer-side timeline is the bottleneck, not the bank-side.

How sweep rules aggregate across locations

For DSOs running virtual accounts under a single PC, sweep rules at the bank level can aggregate, route, and report on per-location balances even though they all settle into one underlying entity account. Common patterns:

• Daily balance report per virtual account, with totals rolled up to the PC level.
• Weekly transfer of net per-location revenue to the MSO management fee account, with location-level breakdowns in the memo.
• Monthly attribution of expenses (rent, supplies, payroll) back to specific locations for productivity reporting.

Generic banks rarely support virtual-account-level sweep rules. Healthcare-native banks like Lemma do, with full reporting hooks.

A sample setup for a 12-location DSO

One practical configuration for a 12-location group across 3 states:

1. Three PC entities, one per state, each clinician-owned per state law.
2. One MSO entity that contracts with all 3 PCs.
3. Each PC has its own operating account and reserve account.
4. Each location has a virtual account under its PC, with unique routing for payer EFT enrollment.
5. Sweep rules: monthly management fee from each PC to MSO; nightly reserve sweeps from PC operating accounts above threshold.
6. Consolidated dashboard shows all 12 locations, 3 PCs, and the MSO in one view.

Total banking footprint: 4 entity accounts plus 12 virtual accounts. Significantly cleaner than 12 separate legal accounts, while preserving CPOM compliance and per-location reporting.

Common mistakes

• Opening separate legal accounts for every location when virtual accounts would suffice. Adds onboarding time and operational complexity without compliance benefit.
• Using virtual accounts to span CPOM-protected legal boundaries. Virtual accounts cannot satisfy CPOM separation, the exact confusion comparing Relay's sub-accounts to Lemma's real per-entity accounts (opens in a new tab) untangles for practices used to envelope-style budgeting apps. Each PC still needs its own legal account.
• Not enrolling each location for payer EFT separately. Routing all locations through one payer EFT setup defeats the per-location attribution that motivated the structure.
• Skipping the consolidated dashboard. Without group-level visibility, the CFO ends up logging into 12 individual accounts every week, which is exactly the problem the structure was supposed to solve.

What Lemma handles, and what it does not

Lemma supports both patterns: separate legal accounts per PC entity (multi-entity onboarding in 5 to 10 days), and virtual accounts per location with unique routing. The dashboard surfaces per-location, per-PC, and group-level views. Sweep rules can aggregate at any layer.

Lemma does not structure your DSO entity setup, decide for you which states need separate PCs, or replace your healthcare attorney's CPOM analysis. It provides the banking layer once the legal structure is decided.

How to decide pattern up front

The choice of separate-vs-virtual rarely needs to be uniform across the entire DSO. Most groups land on a hybrid by asking these questions per state and per location:

1. Does state CPOM require a separate PC for each location? If yes, separate accounts.
2. Are owners materially different across locations? If yes, separate PCs (and accounts).
3. Does this location need its own NPI for payer contracts? If yes, virtual or separate works; depends on item 1.
4. Is per-location productivity reporting required? Both patterns support it; virtual is simpler.
5. How fast does the group plan to expand? Faster expansion plans favor virtual.

Document the decision per location alongside the legal structure. The reasoning becomes the audit defense if any payer or regulator asks why one location is structured one way and another differently.

How reports should look

Per-location reporting needs three views available to the CFO:

• Daily snapshot: each location's deposits, expenses, and ending balance for the day.
• Weekly trend: deposits and expenses by location compared to the prior 4 weeks.
• Monthly P&L: per-location revenue and expense allocation, ready for productivity-based comp calculations.

Banks that surface this natively eliminate the spreadsheet stitching most DSO CFOs end up doing manually, one of the criteria worth checking against any comparison of banks for multi-location medical groups (opens in a new tab). Lemma's dashboard supports all three views at the virtual-account layer; generic banks typically support only the daily snapshot at the legal-entity layer.

What happens at sale or restructure

Per-location structure choices have implications when the DSO is sold or restructures. Two common scenarios:

• Selling the whole DSO. Buyers prefer clean entity-level boundaries. Virtual-account setups require a slightly more complex carve-out at sale, but this is well-understood and rarely a deal blocker.
• Selling individual locations. Materially easier with separate accounts than with virtual. If location-by-location divestiture is a likely path, separate accounts pay back the upfront onboarding cost.

Most groups defer this consideration until they're closer to a transaction. That works as long as the structure can be migrated cleanly when the time comes; usually it can, but allow 60 to 90 days for the cutover.

Sequencing the first 30 days

For a DSO opening 5 new locations under existing PCs, the realistic 30-day plan:

1. Days 1-3: confirm CPOM and entity structure decisions per location with healthcare counsel.
2. Days 4-7: request virtual accounts for new locations (or open new PCs for separate-account locations).
3. Days 8-14: receive routing and account numbers, file payer EFT enrollments in bulk.
4. Days 15-25: payer enrollments process. Bank-side dashboard configured for per-location reporting.
5. Days 26-30: first reimbursements landing in correct virtual or separate accounts. Reconciliation tested.

This timeline assumes a healthcare-native bank. At a generalist, multiply by 2-3 for the bank-side steps.

One operational note: The cleanest DSO setups separate the banking layer from the payer-enrollment layer mentally. The bank gives you routing numbers; the payer enrollments use them. Keeping a single source of truth (a spreadsheet listing every location, NPI, virtual account routing, and current payer enrollment status) prevents the two layers from drifting apart and saves hours of weekly cross-checking.

Understanding MSO-PC structure

MSO-PC banking (opens in a new tab) is the legal structure that almost every multi-location healthcare group ends up using. It separates the business of running a healthcare practice from the clinical side. The MSO handles administration; the PC handles patient care.

That separation is also why MSO-PC banking is harder than single-entity banking. Each entity is legally distinct, has its own EIN, and needs its own bank account. Get the structure right and operations scale cleanly; get it wrong and CPOM, tax, and payer compliance issues compound.

What each letter stands for

MSO stands for Management Services Organization. The MSO is a non-clinician-owned entity that provides administrative, financial, technology, and operational support to clinical practices.

PC stands for Professional Corporation. The PC is a clinician-owned entity that holds payer contracts, employs clinicians, and bills for clinical services.

The two entities operate together under a Management Services Agreement (MSA) that defines what services the MSO provides, what fee the PC pays, and how money flows between them.

Why the structure exists

The structure exists to satisfy Corporate Practice of Medicine (CPOM) rules. Most US states prohibit non-clinicians from owning or controlling a medical practice. The MSO-PC structure lets non-clinician investors and operators own the business side (real estate, equipment, billing systems, admin staff) without owning the clinical side. Clinicians own the PC and retain control over clinical decisions and revenue.

The structure also enables scale. A non-clinician investor can fund growth through the MSO, while clinical ownership remains distributed across multiple PCs. This is how dental service organizations (DSOs), ophthalmology groups, dermatology platforms, and most other multi-state healthcare groups grow.

Why it matters for banking

MSO-PC structure determines four things about banking:

• Each entity needs its own bank account in its own name and EIN. CPOM rules and payer contracts require it.
• Funds flow between entities via documented intercompany transfers (the management fee, primarily). Pooled accounts violate CPOM.
• The bank must support cross-entity reporting and consolidated dashboards so the CFO does not log into 5 separate accounts daily.
• FDIC coverage stacks per entity. A 5-PC group plus an MSO has 6 separate $10M sweep ceilings, $60M of insured capacity total at a healthcare-native bank.

Generic business banks technically support the structure but do it slowly (35 to 75 days of onboarding for 5 PCs) and with limited cross-entity tooling. Healthcare-native banks like Lemma assume MSO-PC from day one, with multi-entity onboarding in 5 to 10 days and consolidated dashboards across every entity.