A composite drawn from work with multi-entity finance teams. Identifying details have been changed.
When a private equity platform grows by acquisition, the finance team inherits the problem nobody put on the deal memo: every entity keeps its own books, in its own system, with its own chart of accounts. Consolidation becomes a monthly act of manual reconciliation, and the planning model is only ever as fresh as the last person to update a spreadsheet.
This platform had rolled up five independently owned practices across a little over a dozen locations. Each one arrived as a going concern with its own general ledger, its own practice management system, and its own patient CRM. Two of the practices ran the same accounting package, configured so differently that the trial balances may as well have come from different vendors. The other three shared nothing.
At the management company, finance was three people. Each practice kept its own bookkeeping on site. There was no data engineering function to escalate to, and no budget to hire one.
The constraint: the systems were staying
The obvious move is to migrate everyone onto one stack. This platform decided against it, and on both layers the reasoning held.
The practice systems were the operational constraint. The acquired practices ran different specialties, and the software underneath was built around those specialties: how visits get scheduled, how procedures get coded, how revenue gets recognized against them. These are not interchangeable products. Replacing them would have meant retraining every front office and putting revenue cycle at risk across every site at once, in exchange for a reporting benefit finance could get another way. The systems were not technical debt. They were the reason each practice ran well enough to be worth acquiring.
The books stayed separate for a different and more structural reason. Each practice sat in its own legal entity with its own filings, and in a physician services platform the entity structure is not discretionary: the management company contracts with physician-owned practices that maintain their own books. On top of that, the selling physicians in three of the five practices held earnouts tied to their own performance, so those P&Ls had to stand on their own through the earnout period. Merging the ledgers was not a project anyone had deferred. It was not available.
So the systems stayed, on both layers, and the reporting problem stayed with them. Finance still owed the sponsor a consolidated view every month.
The goal: one model, every practice, every month
The team did not want another integration project. They could not have staffed one. They wanted to describe what they needed and have it work, then trust the result enough to forecast on it.
With Nexadata, the work followed the same four steps every workflow does.
- Connect. Each practice’s accounting system, practice management system, and CRM was connected through its API. The systems that exposed an OpenAPI or OData specification did not need a hand-built connector at all.
- Transform. Trial balances arrived in five shapes, and so did the visit and procedure data behind them. The team reshaped both into one structure in plain language, no scripts.
- Map. Five charts of accounts were mapped to a single planning taxonomy with conditional logic, and five service-line vocabularies were mapped alongside them. Provider compensation, supply cost, and equipment leases sat in different accounts at every practice, so the rules that resolve those differences live in the mapping instead of in someone’s memory.
- Review. Before anything reached the planning system, a person checked the mappings, the totals tied out, and the run was approved.
What changed
The monthly consolidation that used to take the better part of a week now refreshes on a schedule. The practices kept the systems they know. And because the volume drivers land next to the financials, the model forecasts on visits and provider productivity instead of on last year’s revenue plus a percentage. The mappings are versioned and auditable, so when the sponsor or an auditor asks why an account rolled up the way it did, the answer is one click, not one afternoon.
We were never going to get five practices onto one system, and at some point we stopped trying. The differences live in the mappings now instead of in a spreadsheet only I understood. I can close the month without chasing five office managers for their numbers.
FP&A Manager, PE-backed physician services platform
The problem does not scale with the company
It would be easy to file this under small-company problems, the kind that resolve on their own once the platform grows up and buys a real ERP. That reading is wrong, and it is worth saying plainly.
Five practices with five sets of books create exactly the work a global manufacturer creates across fifty subsidiaries. The volume differs. The task is identical: somebody has to decide what an account in one system means in the consolidated model, apply that decision the same way every period, and be able to defend it a year later.
Consolidation is what creates that work, at every size. The moment two organizations that kept their own books have to report as one, someone owns the translation between them. A roll-up of independent practices, a corporate carve-out, a merger of equals, a parent absorbing a subsidiary it has owned for a decade: the shape is the same, and it rarely resolves on its own. Most organizations never finish standardizing, because the systems that resist standardization are usually the ones doing real operational work.
Which means the durable answer is not to wait for one system. It is to make the translation between systems something the finance team owns, maintains, and can explain.
The deeper win here is not speed. It is that the people who own the numbers own the data pipeline too, instead of waiting in a queue behind every other request to engineering. That matters most when the finance team is three people, and it does not stop mattering when it is thirty.
See how this applies to your stack on the financial planning solution page.