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

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

> Each new PC needs its own accounts and its own clean books. Where multi-entity operations start to hurt, and how to build so it scales.

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

| Per new PC, you add                        | Count                        |
| ------------------------------------------ | ---------------------------- |
| Bank accounts                              | 1–3                          |
| Bank logins and credential sets            | 1 per bank relationship      |
| KYB document packets                       | 1                            |
| Sets of signers and access permissions     | 1                            |
| General ledgers to close monthly           | 1                            |
| Management fee invoices per year           | 12                           |
| Intercompany balances to reconcile         | 1 pair                       |
| Payer EFT enrollment sets                  | 1 per payer                  |
| Payroll registrations                      | 1 (plus MSO's in that state) |
| Sets of annual filings and franchise taxes | 1                            |

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](/reference/banking/per-entity-account-checklist) for the full version.

<Steps>
  <Step title="Open the new PC's operating account">
    Signer is the new PC's licensed officer, the new friendly owner, not you. Same rule as state one, and it does not get more convenient with scale. See [Structure accounts across your entities](/guides/banking/structure-accounts-across-entities).
  </Step>

  <Step title="Apply the naming convention">
    Decide it once and never deviate: `[Brand] [State] PC, Operating`. Consistent naming is what makes a twelve-entity bank list readable and a reconciliation automatable.
  </Step>

  <Step title="Provision access consistently">
    Signer: the PC's officer. Read-only: bookkeeper, controller, and the operator who reconciles. Never share credentials between entities.
  </Step>

  <Step title="Create the general ledger from a template">
    Same chart of accounts as every other PC. Divergent charts of accounts across entities make consolidation manual forever.
  </Step>

  <Step title="Set up the intercompany accounts">
    A management fee payable/receivable pair, and a loan payable/receivable pair if you'll fund the ramp.
  </Step>

  <Step title="Add it to the close checklist and compliance calendar">
    Before it has a single transaction.
  </Step>
</Steps>

## 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](/guides/banking/set-up-bookkeeping).

## Consolidation basics

At month end you produce three views, and they answer different questions:

| View                               | What it shows                                                   | Who asks for it                                |
| ---------------------------------- | --------------------------------------------------------------- | ---------------------------------------------- |
| **Per-entity**                     | Each PC and the MSO standalone                                  | Operators, and anyone checking fee coverage    |
| **Consolidated with eliminations** | The whole business, with intercompany fees and loans netted out | Lenders, auditors, and the board               |
| **MSO standalone**                 | The management company alone                                    | **Investors**, this is the entity they can own |

**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](/concepts/finance/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](/concepts/finance/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](/concepts/banking/why-healthcare-banking-is-different) is about, and [Open bank accounts for your MSO and PCs](/guides/banking/open-bank-accounts) 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:

<CardGroup cols={3}>
  <Card title="Guides" icon="list-check" href="/guides/formation/form-a-pc">
    Task recipes for everything above.
  </Card>

  <Card title="Concepts" icon="lightbulb" href="/concepts/model/cpom">
    The models behind the mechanics.
  </Card>

  <Card title="Reference" icon="table-list" href="/reference/appendix/glossary">
    Every code, state, payer, and rule.
  </Card>
</CardGroup>


## Related topics

- [Structure accounts across your entities](/guides/banking/structure-accounts-across-entities.md)
- [Set up bookkeeping and consolidation](/guides/banking/set-up-bookkeeping.md)
- [Produce investor-grade financial reporting](/guides/banking/produce-investor-reporting.md)
- [Account structures for MSO-PC groups](/concepts/banking/account-structures.md)
- [Intercompany money movement](/concepts/banking/intercompany-money-movement.md)
- [How investors read MSO-PC financials](/concepts/finance/how-investors-read-mso-pc-financials.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)