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

# Structure accounts across your entities

> A practical account map for PCs and the DSO, naming conventions, role-based access, receipt-routing checks, and controls that prevent accidental commingling.

This is a practical starting point for laying out accounts across a multi-entity dental group: which accounts, whose name, who signs, who sees. It is not a national legal default. Confirm the receipt destination and account rights for each entity under state law, payer and program terms, merchant and bank documents, entity governance, and any approved transition or reassignment mechanics. The compliance framework comes from [Why DSO banking is different](/concepts/banking/why-dental-banking-is-different).

## Prerequisites

* Every entity formed with its own EIN
* A decision on your naming convention
* Clarity on who the PC's authorized officer is

## The account map

### Per PC

| Account                   | Purpose                                                                                                                              | When to add                                    |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------- |
| **Operating**             | Receipts routed here when it is the authorized account for the enrolled billing provider; entity obligations and documented fees out | Launch                                         |
| **Payroll**               | Funded from operating before each run                                                                                                | When that entity's payroll volume justifies it |
| **Refund / disbursement** | Patient refund checks drawn from a controlled account                                                                                | When refund volume justifies it                |

### For the DSO

| Account                | Purpose                                              | When to add          |
| ---------------------- | ---------------------------------------------------- | -------------------- |
| **Operating**          | Documented fee and other DSO income; DSO obligations | Launch               |
| **Payroll**            | Payroll for workers whose actual employer is the DSO | Early                |
| **Tax reserve**        | Estimated taxes set aside                            | Early                |
| **Reserve / treasury** | Runway and outage cushion                            | When there's surplus |

**Every account is another reconciliation, another set of signers, and another statement.** Add accounts because they solve a specific problem, not because a diagram looks tidy.

## Naming convention

Decide once and never deviate:

```text theme={null}
Bluebird Dental TX PC, Operating
Bluebird Dental TX PC, Payroll
Bluebird Dental OK PC, Operating
Bluebird Practice Partners, LLC, Operating
Bluebird Practice Partners, LLC, Payroll
Bluebird Practice Partners, LLC, Tax Reserve
```

This matters more than it sounds. It is what makes a thirty-account list readable, makes reconciliation scriptable, and prevents someone paying a Texas expense from the Oklahoma account because the names were ambiguous.

## Signing authority

The following is a conservative starting pattern, not a rule that fits every state or account. Configure each role from state law, entity governance, the management services agreement (MSA), payer and program terms, and the bank's account documents.

| Role                                    | PC accounts                                                                             | DSO accounts                              |
| --------------------------------------- | --------------------------------------------------------------------------------------- | ----------------------------------------- |
| **Signer / authorized user**            | People authorized by the PC's governance and applicable law; often its licensed officer | People authorized by the DSO's governance |
| **Read-only**                           | Role-limited bookkeeper, controller, or reconciler, if permitted                        | Same                                      |
| **Payment initiator** (where supported) | Operations may prepare payments if the documents and workflow permit it                 | Authorized DSO staff                      |
| **Approver**                            | The PC-designated approver under the approved workflow                                  | DSO-designated approver                   |

**A common conservative pattern is operations prepares and a PC-designated approver releases.** Use it only where the MSA, governance documents, bank permissions, and state law support that division of authority.

<Warning>
  **Do not grant a DSO unilateral withdrawal, sweep, signer, or shared-credential right over a PC account without state-specific legal analysis and express authority in the governing documents.** Actual control is fact- and state-specific. *In re OCA* treated revenue-account control as one fact in an aggregated analysis of the agreements before the court; it did not create a nationwide per se rule. See [Run a CPOD self-audit](/guides/compliance/run-a-cpod-self-audit).
</Warning>

## Visibility vs control

These are different axes, but both require a scoped access decision.

**Read-only visibility is ordinarily lower risk than authority to move money, but it is not automatically exposure-free.** Scope it to operational need and test confidentiality, HIPAA, entity governance, bank permissions, and whether the parties' actual conduct gives the viewer influence beyond the stated role. Unilateral withdrawal and sweep rights deserve especially close review.

So: **use least-privilege visibility and deliberately constrained transaction rights.** Give finance users the access they need to reconcile and report, and document who may initiate, approve, release, or stop each movement.

## How commingling actually happens

Not through fraud. Through convenience.

| Scenario                                             | Why it happens                              | Fix                                                          |
| ---------------------------------------------------- | ------------------------------------------- | ------------------------------------------------------------ |
| DSO pays a PC expense because the PC is short        | Friday afternoon, the lab bill needs paying | Record an intercompany entry the same day, or lend on a note |
| PC pays a DSO expense because the card was handy     | The wrong card was in someone's wallet      | Separate cards per entity, clearly labeled                   |
| One entity's refund check drawn on another's account | The check stock was in the drawer           | Per-entity check stock, physically separated                 |
| Payer EFT enrolled to the wrong account              | The form said "company account"             | Verify every EFT enrollment against the entity               |
| A shared credit card across entities                 | Simplicity                                  | Never do this                                                |
| Payroll for both entities from one account           | One payroll provider, one funding account   | Two funding accounts, one per employer                       |

**Every one of these is fixable the day it happens and painful a year later.** The rule: if money moves between entities, there is either an invoice or a note, recorded on both sides, the same day.

## Steps

<Steps>
  <Step title="Write the account map before opening anything">
    Which accounts, which entity, which purpose.
  </Step>

  <Step title="Apply the naming convention from account one" />

  <Step title="Set signers per the table above" />

  <Step title="Provision role-limited visibility and constrained transaction rights" />

  <Step title="Issue per-entity payment cards, labeled" />

  <Step title="Store per-entity check stock separately, physically" />

  <Step title="Document the map and add it to the per-entity setup runbook">
    So entity twelve is set up identically to entity two. See [Per-entity account checklist](/reference/banking/per-entity-account-checklist).
  </Step>

  <Step title="Review access quarterly">
    Departed employees, changed roles, and new entities. Access drift is a real finding.
  </Step>
</Steps>

## Cash concentration, carefully

Groups with meaningful balances want to concentrate idle cash for yield. The constraints:

* **Every PC-to-DSO movement needs a documented lawful basis**, such as a fee, loan repayment, or another transfer permitted by the governing documents and applicable law. Record matching entries on both entities' ledgers.
* **Each entity retains enough** to meet its own payroll, tax, refund, and direct obligations
* **Unilateral DSO withdrawal or sweep rights require state-specific review** of the documents and actual operating practice
* **Automated cross-entity sweeps are a heightened-risk design**, not a substitute for invoices, approvals, transfer authority, and per-entity accounting

## Verify it worked

* [ ] Account map documented before opening
* [ ] Naming convention applied consistently
* [ ] Signers, initiators, and approvers match state law, governance documents, the MSA, and bank permissions
* [ ] Read-only access is role-limited and reviewed for confidentiality and actual-control risk
* [ ] Any standing sweep or ACH debit authority has documented legal, contractual, and bank approval
* [ ] Per-entity cards and check stock, physically separated
* [ ] Setup runbook written
* [ ] Quarterly access review scheduled