Banking and books for entity #3 (and #4, and #12…)

Every professional entity you add brings its own bank accounts, its own general ledger, its own monthly close, its own management fee, and its own intercompany balances. The work does not grow gently — it grows linearly with entity count while your team does not, and the failure mode is not dramatic. It is a slow decay in reconciliation quality that surfaces during diligence.

​

The multiplication

At three entities this is manageable. At twelve, a ten-state group with an MSO and a holding company, a single month-end close touches dozens of accounts across as many logins.

​

Set up entity #3 properly

Use a fixed runbook so each new entity is set up identically. See Per-entity account checklist for the full version.

​

Chart of accounts: identical across PCs

The single highest-leverage decision in multi-entity bookkeeping. Every PC uses the same chart of accounts, with the same account numbers meaning the same things. Then:

• Consolidation is a mechanical roll-up rather than a mapping exercise
• Per-PC unit economics are comparable — you can actually tell which state performs
• A new entity’s books are a template copy, not a design project
• Investors can be given per-entity detail without a translation layer

The MSO’s chart differs, since it has different accounts, but it should also be stable. See Set up bookkeeping and consolidation.

​

Consolidation basics

At month end you produce three views, and they answer different questions: Eliminate the intercompany items. The MSO’s management fee revenue and the PCs’ management fee expense are the same dollars viewed twice. Consolidated revenue that includes both is double-counted, and it is one of the first things a quality-of-earnings review catches. Same for intercompany loans and accrued interest. See How investors read MSO-PC financials.

​

The fee-coverage check

A per-PC metric worth running monthly from entity two onward:

Can this PC pay its management fee out of its own collections, after clinical compensation and direct expenses?

If yes, the entity is self-sustaining and the fee is defensible as something a real business would pay. If no — persistently, not just during the ramp — you have one of two problems:

1. The fee is too high for what this PC can support, which is both an economic problem and an FMV problem. A fee no arm’s-length practice could pay is a fee that looks like profit extraction.
2. The PC’s unit economics don’t work, bad payer mix, bad rates, insufficient volume, which is a business problem the fee structure is masking.

Either way, a PC propped up indefinitely by undocumented intercompany transfers is a diligence red flag that reprices deals. See Where the profit lives.

​

Where multi-entity pain actually begins

Be honest about the operational reality, because it arrives sooner than expected: One login per entity. Generalist banks scope access to a legal entity. Ten PCs plus an MSO means eleven logins, eleven sets of credentials, and eleven statement downloads every month. There is no cross-entity view because, to the bank, there is no relationship between the entities. No cross-entity visibility. Answering “how much cash do we have across the group right now?” means logging into every account and adding it up in a spreadsheet. Manual intercompany movement. Eleven management fee transfers a month, each needing an invoice, each initiated separately, each reconciled separately. Per-entity KYB, repeated. Every new PC is a fresh onboarding, with the same document packet, at the same friction as the first. No banking product understands the structure. No generalist bank knows what a CPOM-clean money flow is, why the PC’s account must not be sweepable by the MSO, or why a management fee transfer is different from an owner draw. The compliance logic lives entirely in your head and your bookkeeper’s. That set of problems is what Why MSO-PC banking is different is about, and Open bank accounts for your MSO and PCs covers the options, including healthcare-focused platforms built specifically for multi-entity groups.

​

Build for twelve when you’re at three

Decisions that are cheap now and expensive later:

• Naming conventions for entities, accounts, and GL codes
• An identical chart of accounts across all PCs
• A documented per-entity setup runbook
• A close checklist parameterized by entity rather than rewritten
• Consistent access patterns, same roles, same permissions, every entity
• A single source of truth for which entity owns which contracts, accounts, and enrollments

Groups that do this expand at roughly constant marginal cost. Groups that don’t add a week of close time per state.

​

Checklist

• New PC operating account open, signer is the PC’s officer
• Naming convention applied
• Read-only access provisioned to bookkeeper and controller
• Chart of accounts copied from the template, unmodified
• Intercompany fee and loan accounts created on both sides
• Added to the monthly close checklist
• Added to the compliance calendar
• Fee-coverage check added to the monthly review
• Consolidation model updated with the new entity and its eliminations

​

You’ve finished Start Here

You now have the full arc: what an MSO-PC is, whether you need one, how to launch, how to operate, and how to expand. From here: