> ## Documentation Index
> Fetch the complete documentation index at: https://dso.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 dental 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 adds bank accounts, a general ledger, a monthly close, management-fee entries, and intercompany balances. The work grows with the entity count even when the finance team does not. Reconciliation quality can gradually decline until diligence or an audit exposes the gaps.
## 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 the DSO's in that state) |
| Sets of annual filings and franchise taxes | 1 |
Three entities may be manageable with a simple process. A ten-state group with a DSO and holding company can have twelve entities, dozens of accounts, and almost as many logins involved in a single month-end close.
## 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.
Use the signer authorized by the new PC's governing documents and applicable state rules. In Bluebird's example, that is the new PC's licensed officer. See [Structure accounts across your entities](/guides/banking/structure-accounts-across-entities).
Use a consistent convention such as `[Brand] [State] PC, Operating`. Consistent names make a twelve-entity bank list readable and easier to reconcile automatically.
Signer: the PC's officer. Read-only: bookkeeper, controller, and the operator who reconciles. Never share credentials between entities.
Use the same chart of accounts as every other PC. Divergent account structures require recurring manual mapping during consolidation.
A management fee payable/receivable pair, and a loan payable/receivable pair if you'll fund the ramp.
Before it has a single transaction.
## Use the same chart of accounts across PCs
Give every PC the **same** chart of accounts, with the same account numbers assigned to the same categories, including gross production, PPO write-offs, and any hygiene-versus-doctor production split. This provides several practical benefits:
* Consolidation is a mechanical roll-up rather than a mapping exercise
* Per-PC unit economics are comparable across states
* 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 DSO'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 DSO 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 |
| **DSO standalone** | The management company alone | **Investors**, this is the entity they can own |
**Eliminate the intercompany items.** The DSO's management fee revenue and the PCs' management fee expense represent the same dollars. Including both in consolidated revenue double-counts the fee. Apply the same elimination principle to intercompany loans and accrued interest.
See [How investors read DSO financials](/concepts/finance/how-investors-read-dso-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 the answer is yes, the entity is self-sustaining and can support the modeled fee. If the answer remains no after the startup period, investigate two possible causes:
1. **The fee is too high for what this PC can support.** That may present both an economic issue and a fair-market-value concern. Compare the amount with the services rendered, the agreement, and the state-specific fee rules.
2. **The PC's unit economics do not work.** Possible causes include weak PPO fee schedules, poor hygiene reappointment, or insufficient volume. Changing the fee presentation does not fix that operating problem.
Undocumented intercompany transfers and long-running fee-coverage deficits commonly draw attention in financial and legal diligence. See [Where the profit lives](/concepts/finance/where-the-profit-lives).
## Common multi-entity constraints
As entity count grows, these constraints often appear:
**Access may be scoped by legal entity.** At some generalist banks, ten PCs plus a DSO can mean eleven logins, credential sets, and statement downloads each month. Ask whether the bank offers a group-level view without combining legal ownership or account authority.
**Cross-entity visibility may be limited.** Without a group view or treasury tool, answering "how much cash do we have across the group right now?" may require exporting and combining each account's balance.
**Manual intercompany movement.** Eleven management fee transfers a month, each needing an invoice, each initiated separately, each reconciled separately.
**KYB repeats for each entity.** A new PC commonly triggers another onboarding and document review, even when the DSO already banks with the institution.
**Generic workflows may not reflect the DSO-PC structure.** Document why account authority stays with the PC, how management fees are approved and invoiced, and which transfers are permitted. Configure bank permissions and bookkeeping controls to match that design.
That set of problems is what [Why dental banking is different](/concepts/banking/why-dental-banking-is-different) is about, and [Open bank accounts for your DSO and PCs](/guides/banking/open-bank-accounts) covers the options, including healthcare-focused platforms built specifically for multi-entity dental groups.
## Standardize early
These decisions become harder to change as the entity count grows:
* **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
Standardization will not remove the work of adding an entity, but it can keep each addition from creating a new set of naming, access, and close rules.
## 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 a dental support organization (DSO) is, whether you need one, how to launch, how to operate, how to buy a practice, and how to expand. From here:
Task recipes for everything above.
The models behind the mechanics.
Codes, state sources, payer details, and operating rules.