The roll-up is only as reliable as the location-level data behind it
A consolidated P&L for a dental or veterinary service organization is a summary — total revenue, total adjusted EBITDA, one blended margin. Behind that summary sits dozens of individual bank accounts, one or more per location, each recording what actually happened at that specific practice that month. When those location-level numbers are captured accurately and consistently, the roll-up is trustworthy. When they aren't — a missed account, a management fee that never got eliminated, an owner-comp anomaly nobody flagged — the roll-up looks clean while quietly hiding exactly the kind of problem a portfolio company or its sponsor needs to see.
This page describes how bank statements from every location in a multi-site practice group are read and structured into a consistent, location-tagged dataset, so that the unglamorous, high-volume work behind a roll-up — gathering and standardizing dozens of banks' worth of statements every month — happens as a matter of course rather than a scramble before the board reporting package is due.
Why a DSO/VSO roll-up is harder than a normal multi-entity close
Every location keeps its own bank accounts, often several
An operating account, a payroll account, and a merchant deposit account for patient financing or insurance payouts are common at a single location — a group of twenty locations can easily mean sixty or more accounts to gather every month.
The legal structure isn't a simple parent-subsidiary chain
Under corporate practice of medicine and dentistry rules in most states, the management company doesn't directly own the clinical practice — it manages it under an MSA, which changes how the practice's financials get consolidated.
Newly acquired locations arrive on their own systems
A location acquired mid-quarter often still runs on its prior bookkeeper's setup and its own legacy bank accounts during the integration window, before it's been migrated onto the platform's standard reporting stack.
A blended margin can hide a genuinely underperforming location
Strong locations can offset a weak one in a single consolidated number, and the weak location doesn't surface unless someone is looking at location-level detail specifically, not just the total.
None of these four points is a sign of a poorly run platform — it's simply what a multi-location roll-up looks like at any real scale. But together they mean that a roll-up compiled from location-level data gathered inconsistently is nowhere near as reliable as it looks once it's been formatted into a clean spreadsheet.
What this doesn't decide
Doesn't perform the consolidation or the intercompany elimination
It structures the location-level bank data and surfaces management fee transactions clearly. Booking the elimination entry per ASC 810-10-45-1, and confirming the consolidation itself, is your controller's or accounting firm's work.
Doesn't decide what belongs in the adjusted EBITDA add-back schedule
It surfaces the transactions that typically feed add-backs — above-market owner comp, related-party rent, one-time items — clearly enough to review. The judgment of what to actually add back stays with your CFO or the sponsor's finance team.
Doesn't assess VIE status or ownership structure
Whether a given practice should be consolidated as a variable interest entity is a technical accounting determination made by your accounting team, independent of what the bank data itself shows.
Where this fits alongside your PMS and your accounting system
Most DSO and VSO platforms already run on an established software stack: a practice management system (PMS) at the clinical and billing level for each location, and a consolidated accounting or ERP system — often a group-wide instance of QuickBooks, Sage Intacct, or a similar platform — that holds the general ledger and produces the actual financial statements. Neither of these systems is built to answer one specific question well: does the bank activity at every individual location actually match, dollar for dollar, what's been recorded in the books.
That gap is exactly what this fills — not a replacement for the PMS that runs clinical operations at each location, and not a replacement for the accounting system that produces the consolidated statements, but the layer that reads every location's bank statements and structures them consistently before they feed into either.
The MSA structure behind every location
In most states, corporate practice of medicine and dentistry rules prevent a management company from directly owning a clinical practice — only a licensed doctor can own the professional entity that actually treats patients. A DSO or VSO platform works around this by having the management company enter into a Management Services Agreement with each practice, providing back-office services — billing, HR, marketing, purchasing, IT, real estate — in exchange for a management fee, typically calculated as a percentage of the location's collections or a fixed monthly amount.
Under U.S. GAAP, the practice is often still consolidated into the group's financial statements as a variable interest entity, if the management company absorbs the majority of the practice's economic risk and reward through the MSA's fee structure — a technical determination made by the accounting team, not something the bank data itself resolves. What the bank data does make visible is the management fee transaction itself, moving from the practice's operating account to the MSO's account every period, which is exactly the transaction that has to be eliminated in consolidation.
What gets read
| Field | Source |
|---|---|
| Transaction date, amount, description | Every bank statement, per location, per account |
| Account type (operating, payroll, merchant deposit) | Statement header and account structure |
| Management fee transfers to the MSO | Recurring transfers, matched by amount and pattern |
| Recurring rent, owner draw, and one-time items | Flagged transaction categories, surfaced for review |
Four categories of data, read from whatever bank statements a location already has on hand — no pre-arranged integration with any specific bank or practice management system required.
The management fee elimination problem
When a practice pays a management fee to the MSO and the two entities are consolidated, that fee shows up twice inside the raw combined numbers before any adjustment: once as an expense on the practice's books, and once as revenue on the MSO's books. Left unadjusted, the consolidated P&L overstates total revenue and total expenses by the same amount — the net income figure is technically still correct, but the gross revenue and expense lines are inflated, which distorts margin percentages and any metric calculated against revenue.
ASC 810-10-45-1 requires this intercompany transaction to be eliminated in consolidation. Making that elimination correctly depends on first knowing, with certainty, exactly how much management fee moved between each practice and the MSO in a given period — which is precisely the transaction this reading surfaces from the bank statements themselves, tagged by location and by period, ready for the controller to eliminate rather than needing to be reconstructed from memory or from a separate fee calculation spreadsheet.
How it works
Upload each location's bank statements
Every account at every location, for the reporting period you're closing.
Every transaction is read
Date, amount and description extracted from each statement's own structure.
Transactions are tagged by location and account type
Operating, payroll and merchant deposit activity kept distinct per location.
Management fees and add-back candidates are surfaced
Recurring intercompany transfers and flagged categories highlighted for review.
Exported
Excel, CSV or JSON, structured by location, ready to feed the consolidated roll-up.
A twelve-location close, reconciled
A regional DSO with twelve locations closes a monthly reporting period, gathering statements from thirty-one bank accounts across operating, payroll and merchant deposit categories.
| Category | Result |
|---|---|
| Bank accounts read and tagged by location | 31 of 31 |
| Management fee transfers matched to MSO deposits | 12 of 12 |
| Related-party rent transactions flagged | 4, surfaced for the add-back schedule |
| Unusual one-time transactions flagged | 3, surfaced for review |
One of the flagged one-time transactions turns out to be a security deposit refund from a location that changed landlords — correctly excluded from recurring operating activity once flagged, rather than left blended into the location's regular monthly cash flow.
Same-store growth vs. acquired growth
A portfolio's total revenue can grow purely because it acquired more locations, even while its existing locations are flat or declining — a distinction that matters enormously to a sponsor evaluating whether the platform's core operations are actually improving. Same-store growth isolates the locations that were part of the portfolio for the full comparison period, stripping out the effect of new acquisitions, to answer that question cleanly.
Calculating same-store growth depends on having each location's bank activity tagged consistently and dated accurately enough to draw a clean line between "existing for the full period" and "acquired partway through" — exactly the kind of location-level consistency that's easy to lose when statements are gathered informally, one email attachment at a time, from a dozen different office managers.
The add-backs that show up in bank data
A newly acquired practice's bank statements often carry the financial habits of a privately-owned business, not a portfolio company — the founding doctor may have paid themselves well above or below a market clinical salary, charged their own practice rent on real estate they personally own, or run a handful of clearly personal expenses through the practice account. None of these are errors exactly — they're simply how a single-owner practice manages cash before it joins a larger platform — but they do distort a location's true operating EBITDA if left unadjusted in a comparison against other locations.
Reading the bank statements surfaces these specific transactions clearly — a recurring payment to the owner above what a market-rate associate doctor would earn, a monthly rent payment to a related-party landlord, a one-time renovation expense — so the CFO or sponsor building the add-back schedule is working from a complete, sourced list rather than whatever the location's own bookkeeper happened to flag informally.
The 100-day window after a new location joins
Most DSO and VSO platforms run some version of a 100-day integration plan after closing on a new location — migrating payroll, standardizing the chart of accounts, and eventually moving the practice onto the group's own banking setup. During that window, the newly acquired location is often still operating on its legacy bank accounts, sometimes still using its prior bookkeeper's categorization habits, which makes it the hardest location in the portfolio to fold cleanly into the monthly roll-up.
Because reading a bank statement doesn't depend on the account being part of any pre-arranged system integration, a newly acquired location's legacy statements can be read and tagged from the very first month after close — the roll-up doesn't have to wait for the 100-day integration to finish before that location's activity is visible at the same level of detail as every other location in the portfolio.
Manual vs. automatic
| Manual | Automatic |
|---|---|
| Each location's statements read and re-keyed by hand every close | Every location's transactions read and tagged automatically |
| Management fee amounts reconstructed from a separate calculation | Every fee transfer matched directly to the bank record |
| Add-back candidates found only when someone digs through an account | Owner comp, related-party rent and one-time items surfaced by default |
From five locations to fifty
A five-location group can gather and reconcile its statements manually without too much strain — a controller who knows every location personally can catch most anomalies by memory. A fifty-location platform, adding two or three new locations a quarter through acquisition, faces a fundamentally different volume problem — not a harder task in kind, just one that stops fitting into the time any one finance team actually has available each month.
Reading every location's statements the same way regardless of portfolio size keeps the reconciliation effort proportional to what actually needs a human decision — the flagged exceptions, the add-back judgment calls — rather than growing linearly with every additional location and every additional bank account.
Who this is for
DSO/VSO controllers
Location-level bank data structured and ready for the monthly consolidated close, without re-keying every statement by hand.
PE sponsor finance teams
A consistent, location-tagged dataset behind the portfolio reporting package, comparable across every practice in the group.
Outside accounting firms serving portfolio companies
The same reading process applied consistently across multiple DSO or VSO clients.
M&A and integration teams
A newly acquired location's legacy bank data folded into the roll-up from month one, before the 100-day integration finishes.
Why grounding the roll-up in the bank record matters
A roll-up built from each location's self-reported monthly numbers, without independently confirming those numbers against what the bank actually shows, is trusting the input data by definition. A location's bookkeeper miscategorizing a transaction, a management fee posted at the wrong amount, or an owner-comp payment that quietly crept above market rate can sit undetected in a roll-up indefinitely, since nothing forces a cross-check against the bank record unless someone does it deliberately, location by location, every period.
Reconciling against the bank statement — the one record in the whole chain that reflects what actually happened at each location, not what a bookkeeper entered — is what catches these discrepancies before a sponsor's finance team does during quarterly board reporting, which is a meaningfully better position for a platform to be in.
This principle holds regardless of how sophisticated a platform's accounting system is — even a well-configured consolidated ledger is only as accurate as the location-level data entered into it, and no amount of downstream reporting polish substitutes for an independent check against the bank statement each location actually operates on.
Get started with your first location's statement
Upload one location's real bank statement to see how the reading and tagging works — no signup required to try it.
Security and privacy
Uploads are encrypted with TLS from end to end.
Processing runs on infrastructure with SOC 2-aligned controls.
Original documents are deleted shortly after processing.
Nothing you upload is ever used to train AI models.
For dozens of practices' worth of bank accounts carrying sensitive financial detail, that matters — full details are on the security page.