The consolidated spreadsheet breaks when operating companies sit beside investments.
Investment reporting tools such as Addepar and Masttro are designed around securities, funds, and custodial accounts. They handle a public equity portfolio well, but an operating company is a different kind of holding. Its value, cash, and performance come from a general ledger, a chart of accounts, and management reporting that the investment tool was never meant to hold in detail, so the office fills the gap by hand.
The result is usually a spreadsheet that someone rebuilds every quarter. Accounting exports from each operating company, custodian statements, property reports, and notes from advisors are pasted into tabs and reconciled by one or two people who understand the formulas. The report arrives late, the logic behind each figure is hard to trace, and every new entity makes the workbook more fragile.
The spreadsheet also carries a quieter risk. It usually contains everything, so sharing any part of it means sharing the whole file or building a trimmed copy by hand. Family members, executives, and outside advisors end up seeing more than they should, or the office stops sharing altogether. A consolidated view built from connected records can answer both problems at once.
Start with a map of every entity and what it holds.
Before connecting any system, write down the structure the reporting has to follow. That means every operating company, holding entity, trust, real estate vehicle, and investment account, the percentage each entity holds in the others, and which family branch or principal each one ultimately serves. Most offices have this in a diagram from their lawyers, but rarely in a form software can read and reporting can use.
The entity map becomes the backbone of everything that follows. Consolidated views roll up along it, access rules are written against it, and documents are filed to it. When an operating company acquires a business or a new trust is formed, the change is made once in the map, and reporting and permissions follow without anyone rebuilding a workbook or rewriting a sharing list.
Building the map also surfaces disagreements early. Two advisors may describe the same holding differently, an old entity may still appear in one system after it was dissolved, or an intercompany loan may be recorded on only one side. Settling those questions at the start is far easier than discovering them later inside a consolidated report the principals already rely on.
Connect each source system and let it remain the record for its part.
Each part of the picture already has a system that should stay in charge of it. Operating companies keep their books in NetSuite, Sage Intacct, QuickBooks, or similar. Investment reporting tools hold the securities and fund positions, fund administrators and custodians send statements, and property systems track rents and expenses. The consolidated layer reads from each of them rather than replacing any.
Connections vary in quality. Cloud accounting systems usually offer APIs, some custodians and administrators provide data feeds, and others send only statements or exports. The connection for each source is chosen to match what it offers, and the consolidated view shows when each figure was last updated, so the principals know which numbers are current and which are waiting on a statement.
Mismatches deserve a deliberate place in the design. An intercompany balance that does not agree, a custodian feed that fails, or an entity missing from a ledger should land in a review queue with a named person responsible. Fixing these in the source system, rather than overriding them in a spreadsheet, keeps the consolidated view trustworthy from one period to the next.
Agree on definitions and access before building any views.
A consolidated report is only as clear as the definitions behind it. The principals need to agree on how an operating company is valued in the report, whether real estate is shown at cost or at an appraised figure, how income is treated across entities, and how performance is measured for holdings with no market price. Writing these down once prevents the same argument every reporting period.
Access needs the same care. Which family members see which entities, which executives see only their company, and which advisors see only their engagement are decisions for the principals, not for whoever builds the software. The rules should apply to every screen, search, and export, and every view should be logged, so the office can answer who saw what if the question ever arises.
Data handling belongs in the same conversation. Where the records are hosted, who at the software provider can reach them, how long exports are retained, and how access is removed when an advisor’s engagement ends should all be agreed in writing before any real records are connected. A family office has good reasons to be cautious, and the design should reflect that caution.
Build the consolidated view in phases, starting with the questions the principals ask most.
A first release does not need to answer every question. It usually covers the entity map, connections to the main accounting and investment systems, a consolidated view along the agreed definitions, and access for the people who need it most. Cash positions, capital calls, distributions, and a portal for the wider family can follow once the core view is trusted.
The same work often shows where the operating companies need help. A company whose numbers arrive late or need heavy adjustment is usually running on manual processes and founder-era tools. Because a family office intends to keep its companies, modernizing that company in phases, with documentation that outlasts any one person, tends to be a better investment than preparing it for a sale.
Baybloom builds this kind of consolidated reporting and operating company software, scoped in writing with the principals and the management teams involved. The family offices page describes the typical first release, the systems involved, and the questions offices ask before starting. The connected reporting project page covers the reporting layer itself in more technical detail for the teams who will run it.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project