Structure accounts across your entities

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.

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:

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.

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.

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

Write the account map before opening anything

Which accounts, which entity, which purpose.

Apply the naming convention from account one

Set signers per the table above

Provision role-limited visibility and constrained transaction rights

Issue per-entity payment cards, labeled

Store per-entity check stock separately, physically

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.

Review access quarterly

Departed employees, changed roles, and new entities. Access drift is a real finding.

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

Formation & Corporate

Agreements

Credentialing & Payer Enrollment

Billing Operations

Patient Payments & Membership Plans

Acquisitions & Growth

Banking & Finance

Compliance Tasks

Structure accounts across your entities

Prerequisites

The account map

Per PC

For the DSO

Naming convention

Signing authority

Visibility vs control

How commingling actually happens

Steps

Cash concentration, carefully

Verify it worked

​Prerequisites

​The account map

​Per PC

​For the DSO

​Naming convention

​Signing authority

​Visibility vs control

​How commingling actually happens

​Steps

​Cash concentration, carefully

​Verify it worked

Prerequisites

The account map

Per PC

For the DSO

Naming convention

Signing authority

Visibility vs control

How commingling actually happens

Steps

Cash concentration, carefully

Verify it worked