Two locations, same revenue, very different real economics
Two practices in the same portfolio can post nearly identical monthly collections and still have wildly different underlying profitability once you account for how each one was actually run before joining the platform — one founding doctor paid themselves a market clinical salary and rented from an unrelated landlord; another paid themselves well above market and owns the building the practice sits in, charging above-market rent to their own practice. Both look similar on a raw revenue comparison. Neither looks similar once normalized.
This page describes how each location's bank activity is read and the specific transactions behind that gap — owner comp, related-party rent, one-time items — are surfaced, so building a genuinely comparable margin across the portfolio doesn't depend on someone manually digging through each location's bank statement line by line every time a comparison is needed.
Why comparability breaks down across a portfolio
A raw location-level P&L reflects however that specific practice happened to be run before it joined the platform — one owner's personal compensation philosophy, one location's real-estate arrangement, one bookkeeper's habits around what counts as a business expense. None of that variation is wrong on its own, but it means comparing raw margins across locations mostly measures differences in bookkeeping and ownership history, not differences in genuine clinical or operational performance.
Normalizing for these differences — putting every location on the same footing for owner comp, real estate cost, and one-time items — is what turns a set of raw, inconsistent P&Ls into a comparison that actually says something useful about which locations are performing well and which aren't.
What this doesn't decide
Doesn't set the market compensation benchmark
It surfaces the recurring payment pattern to an owner or clinician. Comparing that pattern against a market salary benchmark is a determination your finance team makes with its own reference data.
Doesn't confirm related-party status on its own
A recurring rent payment is flagged for review. Confirming the landlord is actually a related party depends on ownership information the bank statement alone doesn't contain.
Doesn't produce the final adjusted EBITDA number
It structures the underlying transactions clearly. The add-back decision, and the resulting adjusted figure, is built by your CFO or the sponsor's finance team.
What normalization actually requires
Reliable transaction-level detail from every location's bank account (not a summarized monthly total), a consistent way of recognizing recurring payment patterns that typically indicate owner comp or related-party rent, and a clear separation between what's recurring operating activity and what's a genuine one-time item — combined, these three give a finance team the raw material a real add-back schedule depends on, rather than a rough estimate built from whatever the location's own bookkeeper happened to note.
What gets read
| Field | Used for |
|---|---|
| Every transaction date, amount and description | Building the location's full transaction history |
| Recurring payment patterns to individuals | Flagging potential owner or clinician compensation |
| Recurring rent or lease payments | Flagging potential related-party real estate cost |
| Irregular, non-recurring large transactions | Separating one-time items from operating activity |
The four add-back categories this surfaces
Owner and clinician compensation
Recurring payments to an owner or associate doctor, surfaced with amount and frequency for comparison against a market benchmark.
Related-party rent
Recurring rent or lease payments flagged when the pattern suggests a fixed, non-arm's-length arrangement worth reviewing.
One-time and non-recurring items
Large, irregular transactions — a renovation, a settlement, a security deposit refund — separated from ongoing operating cash flow.
Personal or discretionary expenses
Transactions that don't fit a location's normal recurring pattern, flagged for a closer look rather than assumed to be operational.
How it works
Upload a location's bank statements
One or more accounts, covering the period you want normalized.
Every transaction is read
Full transaction history extracted, not just a monthly summary.
Patterns are flagged by category
Owner comp, related-party rent and one-time items surfaced separately.
Exported for review
Excel, CSV or JSON, ready to drop into your own add-back workpaper.
A newly acquired location, normalized
A veterinary platform closes on a single-owner clinic and needs a normalized EBITDA figure within its first month in the portfolio, before its bank accounts have even been migrated onto the platform's standard setup.
| Flagged item | Detail |
|---|---|
| Owner draw pattern | $18,500/month, well above a market associate DVM salary |
| Rent to related-party LLC | $6,200/month, owned by the same founding veterinarian |
| One-time renovation expense | $34,000, single transaction, three months prior |
None of these three items required the finance team to interview the location's prior bookkeeper or dig through a year of paper statements — every one of them surfaced directly from the clinic's own bank activity, dated and sourced, ready for the sponsor's finance team to decide how each should factor into the location's normalized figure.
Guaranteed pay vs. production-based compensation
A location's bank statement shows a very different payment pattern depending on how its doctors are compensated. A guaranteed-salary arrangement shows up as a fixed, identical recurring transfer every pay period. A production-based arrangement — compensation tied to a percentage of the doctor's own collections — shows up as a variable amount that moves with the location's revenue month to month.
Reading and surfacing both patterns matters because normalizing one the way you'd normalize the other produces a misleading result — a variable, collections-linked payment isn't automatically "above market" just because it's larger in a strong revenue month, and a fixed guaranteed salary isn't automatically fine just because it's consistent. Surfacing the actual payment pattern, rather than a single blended average, gives the finance team the detail needed to apply the right kind of comparison for each location's specific compensation model.
A location can also mix both models — a guaranteed base plus a production bonus above a certain collections threshold, for instance. Reading captures the full payment history rather than collapsing it into a single average figure, so a mixed compensation structure is represented accurately instead of being forced into whichever of the two simpler categories it resembles most.
Manual vs. automatic
| Manual | Automatic |
|---|---|
| A finance analyst scans months of statements by eye for anomalies | Recurring patterns and irregular transactions flagged automatically |
| Owner comp estimated from a single conversation with the seller | The actual recurring payment pattern read directly from the bank record |
| Normalization redone from scratch for each new acquisition | The same reading process applied consistently to every location |
From one add-back schedule to a portfolio-wide comparison
Normalizing a single location's EBITDA by hand, with a finance analyst reading through a year of statements, is a workable one-off exercise. Doing it consistently for every location in a growing thirty- or forty-practice portfolio, every time a board reporting package or an add-on acquisition underwriting needs an updated comparison, is a different kind of problem — not because any single location is hard to normalize, but because the analyst's time doesn't scale with the number of locations that need the same treatment.
Reading every location's bank activity the same way, regardless of portfolio size, keeps the normalization effort proportional to what actually needs a person's judgment — reviewing the flagged transactions and deciding on the add-back — rather than growing linearly with every additional location added to the platform.
This matters most in exactly the moment a portfolio-wide comparison is usually needed most urgently — right before a board meeting, an add-on acquisition decision, or a refinancing conversation, when there's rarely enough lead time to have a finance analyst work through dozens of locations by hand from a standing start.
Who uses this
DSO/VSO CFOs
A comparable, normalized margin across every location, built from a consistent process rather than an ad hoc one.
PE sponsor finance teams
The add-back detail needed for board reporting and add-on acquisition underwriting, sourced from the bank record.
Deal teams evaluating a new acquisition
A quick, sourced read on a target location's real operating economics before a formal quality of earnings review.
Outside accounting firms
The same normalization support applied consistently across multiple portfolio company engagements.
Why the source transaction matters more than the final number
An add-back schedule that lists a dollar figure without a clear reference to the underlying bank transaction is difficult for anyone else to trust or verify — a sponsor's investment committee, a lender reviewing covenant compliance, or an outside accounting firm performing a quality of earnings review will all eventually ask where a specific add-back number came from. Every flagged transaction here carries its exact date, amount and source account, so the answer to that question is always immediate.
This matters even more during due diligence for a sale or a refinancing, when an add-back schedule built without clear sourcing tends to get challenged line by line — a schedule that already traces every figure back to its bank record holds up to that scrutiny far better than one built from estimates and recollection.
There's a quieter benefit too — a sourced add-back schedule is easier to update. When a location's circumstances change, whether that's a renegotiated owner comp arrangement or a new related-party lease, having every prior figure tied to its original transaction makes it straightforward to see exactly what changed and when, instead of having to reconstruct the schedule's history from scratch to understand the difference between this quarter and last.
Harder cases this is built to handle
A doctor paid partly through payroll and partly through owner draws
Both payment streams are read from their respective accounts and surfaced together, rather than only capturing the payroll-run portion.
Rent that increased mid-year
A change in the recurring rent amount is captured with its effective date, rather than averaged into a single figure that obscures when the increase happened.
A location with two part-owners paid differently
Each recurring payment stream to a different individual is tracked separately rather than combined into one blended owner-comp figure.
A one-time item that recurs more than once
A transaction that initially looks one-time but repeats in a later period is re-flagged for review rather than assumed to still be non-recurring.
None of these four cases require special configuration ahead of time — they're handled the same way any other transaction pattern is handled, by reading what actually happened in the bank account and flagging anything that doesn't fit a simple, single-pattern assumption.
Get started with your first location
Upload one location's bank statement to see how the flagging works — no signup required to try it. See the full multi-location roll-up overview for how this fits into the rest of the process.
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 bank data touching individual owner compensation, that matters — full details are on the security page.