> ## 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. # Account structures for DSO groups > Patterns from one PC to thirty: minimal, standard, and advanced account maps for a DSO and its practice entities, FBO pitfalls, and the visibility-versus-control tradeoff. An account structure is the map of which bank accounts exist, which entity owns each, who can move money from it, and what flows through it. In a dental support organization (DSO) group, route receipts to the account authorized for the enrolled billing provider under state law, payer and program terms, merchant and bank documents, and any approved transition or reassignment mechanics. Preserve each entity's ledger and separateness even where a bank provides consolidated visibility or an approved collection structure. ## Three patterns ### Minimal, one PC, launch stage | Entity | Account | Purpose | | ------ | --------- | -------------------------------------------------------------------------------------------------------------------------------------- | | PC | Operating | Receipts routed here when this is the authorized account for the enrolled billing provider; entity obligations and documented fees out | | DSO | Operating | Documented fee and other DSO income in; DSO obligations out | Two accounts are a common launch-stage map. The number and labels alone do not establish compliance; the authorized receipt destination, ownership, permissions, contracts, and actual conduct do. ### Standard, one to five PCs, operating | Entity | Account | Purpose | | ------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Each PC | Operating | Receipts assigned to that entity under the confirmed payer, program, merchant, bank, and transition mechanics; entity obligations and documented fees out | | DSO | Operating | Fee income and general operations | | DSO | Payroll | Funded from operating before each run; limits exposure | | DSO | Tax reserve | Estimated taxes set aside so they aren't spent | | DSO | Savings / reserve | Runway, and a cushion against events like a clearinghouse outage | The DSO's payroll and tax accounts are ordinary financial hygiene, not compliance requirements. They exist so payroll funds aren't accidentally spent and tax money isn't mistaken for working capital. ### Advanced, five to thirty PCs | Entity | Account | Purpose | | ----------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------ | | Each PC | Operating | Receipts routed here when authorized for that enrolled billing provider | | Each PC | Payroll | Payroll segregation for workers employed by that entity | | Each PC | Refund / disbursement clearing | Patient refunds and credit-balance payouts drawn from a controlled account | | DSO | Operating | Fee income | | DSO | Payroll | Payroll for workers whose actual employer is the DSO | | DSO | Tax reserve | | | DSO | Reserve / treasury | | | Holding co. | Operating | Sweeping profits out of the DSO when you have a holding company with multiple portfolio companies underneath | At this scale, separate accounts are mainly an operational control. They limit the effect of an error, simplify reconciliation, and let you grant narrow access. A per-PC refund account is especially useful in dentistry. Estimates, downgrades, and coordination of benefits create a steady stream of patient credit balances, and a dedicated account makes those refunds easier to audit. See [Refunds and credit balances](/concepts/payments/refunds-and-credit-balances). **Every account you add is another reconciliation, another set of signers, and another statement.** Add accounts because they solve a specific problem, not because a structure diagram looks tidy. ## Signers and access The part that founders find uncomfortable and must not solve by cheating. This table is a conservative starting pattern. Configure actual roles from state law, entity governance, the management services agreement (MSA), payer and program terms, bank documents, and the parties' real operating practice. | 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 | | **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. **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.** The documents and actual conduct matter. *In re OCA* treated revenue-account control as one fact in an aggregated analysis of the agreements before the court; the 2015 New York Aspen Dental settlement imposed account-control terms on the settling parties.1 Those are important risk signals, not nationwide per se rules. ## FBO and pooled account pitfalls Occasionally someone proposes a **for-benefit-of (FBO)** structure: one account holding funds attributed to multiple PCs with sub-ledger accounting. Do not assume the label makes the structure valid. Test these issues before using one: 1. **Receipt and account authority.** Is this the account authorized for each enrolled billing provider under state law, payer and program terms, merchant and bank documents, and approved transition or reassignment mechanics? 2. **Ownership and accounting.** A sub-ledger does not by itself establish legal ownership or preserve entity separateness. 3. **Payer and bank mismatch.** Enrollment and treasury documents may validate, name, or restrict the destination account; verify them payer by payer and bank by bank. 4. **Diligence and audit friction.** Reconstructing per-entity cash from a pooled account is exactly the work an auditor will make you do. 5. **Money transmission questions.** Holding funds for the benefit of others can raise licensing issues depending on who operates the pool. The lower-complexity version of "one view across many accounts" is **consolidated visibility over separately owned or otherwise authorized accounts**, with receipts and balances maintained on the correct entity ledgers. Whether a pooled or FBO structure is permitted is fact-, contract-, and state-specific. ## Visibility vs control The genuine tension in multi-entity treasury. | | More control to the PC | More visibility to the DSO | | ------- | --------------------------------------------------- | ------------------------------------------------------------------ | | **Pro** | Cleaner CPOD posture; clearer separateness | Faster operations; better cash management; earlier error detection | | **Con** | Slower; depends on a dentist who is seeing patients | Erodes the separateness the structure depends on | The resolution is that these are **different axes that require different controls.** 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 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 needed to reconcile and report, and document who may initiate, approve, release, or stop each movement. ## Naming conventions Adopt a consistent naming convention. For example: ```text theme={null} [Brand] [State] Dental PC, Operating [Brand] [State] Dental PC, Payroll [Brand] [State] Dental PC, Refunds [Brand] DSO, Operating [Brand] DSO, Payroll [Brand] DSO, Tax Reserve ``` Consistent naming keeps a thirty-account list readable, supports automated reconciliation, and reduces the chance that someone pays a Colorado expense from the Arizona account. ## 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 other transfer permitted by the governing documents and applicable law, with matching entries on both entities' ledgers * **Each entity should retain enough** to cover its payroll, tax, refund, and direct obligations * **Unilateral DSO withdrawal or sweep rights require state-specific review** of the documents and actual operating practice Before automating a cross-entity sweep, document the transfer authority, approval and stop rights, calculation, timing, and accounting treatment. Test those actual rights under applicable state law and the account documents rather than assuming a particular toggle makes the arrangement compliant. A common conservative approach is an **invoiced periodic fee**, sized so the PC retains an appropriate working balance, with any other surplus movement handled through a documented and authorized mechanism. See [Intercompany money movement](/concepts/banking/intercompany-money-movement). ## Sources 1. *In re OCA, Inc.*, 552 F.3d 413 (5th Cir. 2008): [opinion](https://caselaw.findlaw.com/us-5th-circuit/1452605.html); NY AG, [settlement with Aspen Dental Management](https://ag.ny.gov/press-release/2015/ag-schneiderman-announces-settlement-aspen-dental-management-bars-company-making) (June 18, 2015). See [DSO case law](/reference/legal/dso-case-law).