How virtual accounts, true sub-accounts, and separate accounts compare on reconciliation, sweeps, FBO, payer routing, and audit, and where each one belongs in an MSO-PC structure.
At 5 PCs, the question is small. At 50 PCs, the answer reshapes how your treasury team spends its day.
The decision is structural: does each professional corporation get its own real bank account, or does each PC get a virtual sub-account under a single master? On a spreadsheet they look equivalent. In operations, they are not.
This article is for CFOs and treasury leads at multi-entity healthcare platforms built on an MSO-PC structure (opens in a new tab). We compare virtual accounts, true sub-accounts, and separate accounts on reconciliation, sweeps, FBO structure, payer EFT routing, and what audit cares about, then draw the line for where each one belongs.
Separate accounts means each PC has its own bank account at the bank: distinct account number, distinct routing number (or shared routing depending on the bank), distinct statement, distinct everything. The bank treats each PC as a separate customer, with its own EIN, its own KYC file, and its own tax reporting, the account architecture we detail in how bank accounts map onto an MSO-PC structure (opens in a new tab).
Virtual accounts (sometimes called virtual ledger accounts or VAs) means there is one real bank account at the bank. The bank issues distinct virtual account numbers for each PC, all backed by the same master. Payer ACH lands at the virtual number, which routes internally to the right PC for reporting and reconciliation. The bank treats the virtual layer as a routing convenience, not as a separate customer.
True sub-accounts are a middle ground: one banking relationship, multiple legally distinct accounts that report up through a parent. Less common in healthcare, more common in fintech.
From a payer's view, separate and virtual accounts are indistinguishable. Both are a routing number and an account number to file on an EFT enrollment form. From the bank's view they are entirely different objects, and that mismatch is where most of the confusion starts.
Separate accounts: each PC reconciles independently. If a payer sends Aetna's ACH for the dermatology PC into the wrong account, you find out at month-end. Reconciling 50 separate statements is a part-time job.
Virtual accounts: payer ACH lands at the virtual number tied to a specific PC. Reconciliation is automatic per PC. The master account just sees the same totals roll up. You catch routing errors immediately because the system flags them.
Winner: virtual accounts, by a wide margin, once you cross 10 PCs.
Separate accounts: sweeps require either a sweep agreement at each bank (operationally complex) or a daily manual process to push excess balances to a central reserve. Most platforms end up doing this on Fridays. By Friday, the cash has been sitting all week earning zero.
Virtual accounts: sweep policies live at the master account level. "Any virtual balance above $500K end of day sweeps to the reserve" runs automatically. No human touches it.
Winner: virtual accounts, especially as your reserve grows past $5M.
Separate accounts: each payer EFT enrollment uses the PC's distinct account number. Payers store this. If you ever consolidate banking, every payer needs a re-enrollment, which is the single slowest part of any bank switch.
Virtual accounts: each PC has its own virtual account number that the payer sees. Re-enrollment within the same bank is trivial because the master account does not change. Re-enrollment across banks requires the same notification but is easier to sequence.
There is a second, less obvious advantage. A virtual account number can be issued and filed with payers immediately, in parallel with the underlying entity setup, instead of waiting for each legal entity to finish onboarding. On a multi-PC, multi-location go-live, that parallelism alone can shave 30 to 60 days off the schedule.
Winner: virtual accounts, with a meaningful gap.
Separate accounts: legally distinct. Each PC's funds are clearly segregated. CPOM-compliant by default. Auditors love this.
Virtual accounts: legally one account, with internal allocation to each PC. The bank's master account holds all the funds, but the virtual account architecture preserves the same effective segregation through bookkeeping. CPOM compliance depends on documentation: the trust agreement, the FBO designation, and the operating agreement language need to explicitly establish that the virtual accounts are For Benefit Of each specific PC.
Winner: separate accounts, narrowly. Virtual accounts are equally defensible when the FBO documentation is clean, but the documentation is real work and it has to exist before the first dollar lands.
The comparison above is not a single verdict, because the two objects are strongest at different layers of the structure:
A 5-PC, 12-location group with provider-level attribution might run 15 to 20 separate accounts across all PCs and the MSO, with 30 to 40 virtual accounts layered on top for payer routing. That sounds like a lot of objects, but the operational complexity flows through a single dashboard.
Two patterns repeatedly create problems:
Separate accounts: monthly maintenance per account ($15-$60 per PC per month at most banks), per-item ACH fees per PC (if not waived), and 50 separate statements that someone has to download and reconcile.
Virtual accounts: typically a flat platform fee at the healthcare-native bank, with free ACH, free virtual account provisioning, and one statement that breaks down by PC.
At 50 PCs, the difference is real money. $15 per account per month across 50 PCs is $9,000 per year in just maintenance, before reconciliation labor.
Regulatory ambiguity. If you operate in a state where your CPOM counsel is not confident that a pooled master with virtual allocation meets the segregation standard, default to separate. Audit defensibility is worth the operational overhead. The same applies when a PC borrows in its own name or you expect to carve it out and sell it.
Separate accounts at the legal-entity boundary, virtual accounts for everything below it. That rule answers the question correctly for the large majority of multi-entity healthcare platforms, and it gets more valuable, not less, as the entity count grows.
Below that boundary, the reconciliation, sweep, payer routing, and cost advantages of a virtual account layer compound, and there is no reason to pay for real accounts you do not need. At the boundary itself, pooling PCs under one master is a deliberate decision that requires FBO documentation and counsel sign-off, not a default you drift into because the bank offered it.
Lemma provides both layers at account opening: legal-entity separate accounts for each PC and the MSO, plus per-location and per-provider virtual accounts with no per-virtual-account fees. Multi-entity onboarding runs 5 to 10 days, with automated sweep rules per MSA and FDIC coverage up to $10M per entity through an IntraFi sweep. What it does not do is make virtual accounts a substitute for per-PC legal separation. Nothing does.