A family office would never make an investment without understanding who holds the asset, what rights attach to it, and what happens if the relationship with a manager or counterparty ends. That same discipline rarely shows up when the family office evaluates its own operational and technology infrastructure.
The data inside a family office platform is not a byproduct of the software. It is the financial record of the family’s wealth. Entity structures, ownership chains, capital accounts, transaction histories, tax records, partnership allocations, and the documents behind all of it. That data is what makes reporting possible, what auditors examine, and what a successor team would need to continue operations if anything changed. Losing access to it, or discovering that it cannot be moved without significant cost and reconstruction, is a governance failure.
Most platform evaluations focus on features, reporting quality, and user experience. Those things matter, but they are surface-level compared to a more basic set of questions. Where does the data physically reside? Who can access it? Is it stored in a structure that the family office controls as its own books of record, or does it live inside a vendor’s proprietary model where it serves the platform’s analytical functions first and the family office’s independence second? And if the family office decides to leave, what comes with it and what stays behind?
These are not hypothetical concerns. Family offices routinely operate technology relationships that last a decade or longer. Over that period, the volume of data grows, the complexity of the structures it represents deepens, and the cost of migrating away from a platform increases. The time to understand who owns and controls that data is before the relationship begins, not when it needs to end.
What “data ownership” actually means in practice
Every family office software vendor will tell you that you own your data. It is a standard clause in most enterprise agreements, and it is rarely untrue in a strictly legal sense. The problem is that legal ownership and practical control are not the same thing, and the gap between them is where operational risk lives.
Data ownership in a family office context breaks down into three distinct questions that tend to get treated as one.
The first is legal ownership. This is the contractual question. Your agreement with the vendor says the data belongs to you. In most cases that is straightforward, and it is the easiest box to check during an evaluation. But a contract that says you own your data does not tell you much about what happens when you try to exercise that ownership.
The second is physical control. This is the infrastructure question. Where does the data actually reside? Is it on hardware that the family office owns or operates? Is it in a private cloud environment dedicated to a single client? Or is it in a multi-tenant environment managed entirely by the vendor, where your data sits alongside other clients’ data on shared infrastructure? Each of these arrangements implies a different level of control over access, security policy, data residency, and what happens during a vendor disruption.
The third is functional portability. This is the question most buyers underweight and most vendors would prefer not to discuss in detail. If the family office decides to move to a different platform, can it extract its data in a structured, usable format that another system can ingest? Or is the data stored in a proprietary model that makes extraction technically possible but practically expensive, requiring months of mapping, reformatting, and reconstruction to make it functional somewhere else?
A family office that has legal ownership but no deployment choice and limited portability is in a weaker position than it may realize. The data belongs to the family on paper, but the vendor’s architecture determines how much of that ownership translates into real control. Understanding where your platform sits on each of these three dimensions is the starting point for any honest evaluation.
Where your data lives
The physical location of your data is not a technical detail to delegate to IT. It is a governance decision that determines who can access your financial records, what jurisdiction they fall under, and how much direct control the family office retains over its own infrastructure.
There are three common deployment models in family office software, and each one answers the control question differently.
In a multi-tenant SaaS model, the vendor hosts the platform on shared infrastructure and manages everything from updates to security to backups. The family office accesses the system through a browser or application, and the data resides in the vendor’s environment. This is the most common model in the market because it is the easiest for vendors to deliver and the simplest for clients to adopt. The tradeoff is that the family office has limited say over where the data is stored, how the environment is configured, and what other clients share the same infrastructure. Logical separation keeps your data distinct from other tenants, but the physical environment is the vendor’s to manage.
In a private cloud model, the family office’s instance runs in an isolated environment, typically hosted by a cloud provider but dedicated to a single client. This gives the family office more control over data residency, access policies, and security configuration than a shared environment would, while still offloading infrastructure management. The data is still hosted externally, but the family office has a dedicated environment that is not shared with other clients.
In an on-premises deployment, the software runs on infrastructure that the family office owns and operates within its own facilities or data center. The data never leaves the family office’s physical control. No vendor employee, no cloud provider, and no co-tenant has access to the environment unless the family office explicitly grants it. For offices with strict data residency requirements, regulatory constraints, or a governance philosophy that treats financial data the way it treats physical assets, on-premises deployment is the arrangement that most fully aligns legal ownership with practical control. The family office owns the data and holds it.
Most platforms in the family office software market offer only one of these options, typically multi-tenant SaaS. That is not necessarily a problem for every family office, but it means the decision has been made for you. The platform’s business model determines where your data lives, not your governance requirements.
FundCount is one of the few platforms in this space that offers all three. A family office can deploy on its own hardware, in a dedicated private cloud, or as a fully managed SaaS solution, and move between these options as its needs evolve. The architecture is the same regardless of deployment model, which means the family office is not choosing between capability and control. It is choosing the level of infrastructure ownership that fits its situation.
Addepar operates as a SaaS platform. The family office’s data resides in Addepar’s hosted environment, and deployment on client-owned infrastructure is not a published option. Masttro emphasizes its Swiss-based private cloud hosting with dedicated servers and direct custodian feeds, which is a strong data privacy position. But it remains a vendor-managed environment, and the family office does not have the option to bring the system in-house.
None of this makes one vendor categorically better than another. It means the question of where your data lives is being answered by your platform choice whether you are asking it or not. A family office that cares about data control should be making that decision deliberately, and should understand what each vendor’s deployment model permits and what it does not.
Who holds the books?
Deployment determines where data lives. Architecture determines how it is organized and whether the family office can function independently of the platform if it needs to.
The most consequential architectural question in a family office platform evaluation is whether the system includes a native general ledger and accounting engine, or whether it operates as a reporting and analytics layer that sits on top of a separate accounting system. This distinction sounds technical, but it has direct implications for data control, portability, and operational independence.
When a platform is built on an integrated general ledger with portfolio accounting and partnership accounting in the same system, every transaction that enters the platform creates a journal entry. Capital calls, distributions, trades, revaluations, fee calculations, and allocation events all flow through the same accounting structure. The result is a unified set of books that the family office maintains as its financial system of record. The data is structured according to accounting conventions that are understood across the industry, which means it can be audited in place, reported from directly, and if necessary, exported in a format that another accounting system can work with.
When a platform does not include a native general ledger, the family office needs a second system to maintain its books. This is a common arrangement. The reporting platform handles positions, ownership structures, analytics, and client-facing reports. A separate tool, often QuickBooks, Sage, or a similar general ledger package, handles the actual accounting entries, financial statements, and compliance outputs. The two systems have to be reconciled, and the family office’s complete financial picture exists only when both are combined.
The data control problem surfaces when you consider what each system holds independently. The reporting platform contains the portfolio structure, historical analytics, custom attributes, ownership graphs, and presentation logic. The general ledger contains the accounting entries and financial statements. Neither has the whole picture. If the family office leaves the reporting platform, it keeps its GL but loses the analytical layer and the configurations built over years of use. If it leaves the GL, the reporting platform has no accounting backbone to produce auditable financials from.
Addepar is transparent about its positioning here. It describes itself as a complement to general ledger systems, not a replacement for them. Its strength is in centralizing financial information for analysis and reporting, and it integrates with external GL tools to complete the accounting workflow. For family offices that already have a strong accounting function and want a powerful analytical layer on top, that can work well. But the data is split across two systems by design, and the family office’s independence is tied to both.
Masttro similarly operates as an aggregation and reporting platform. It offers document automation, portfolio visualization, and performance reporting, but it does not position itself as a book-of-record accounting system. Family offices using Masttro will typically maintain a separate GL, creating the same two-system dynamic.
FundCount takes a different approach. Its architecture starts with a general ledger and builds portfolio accounting, partnership accounting, and reporting into the same system. Every transaction produces a journal entry. Every report traces back to the underlying accounting data. There is no second system to reconcile with, because the books and the reporting draw from the same source. For a family office evaluating data control, this means the financial record of the family’s wealth lives in one place, structured in a way that is both auditable and portable.
This is not an argument that reporting platforms have no value. They clearly do, and many family offices use them effectively. The point is that architecture determines where your most critical data resides and how dependent you are on any single vendor to access it. A family office whose books of record live inside its own accounting system has a different risk profile than one whose financial picture is distributed across two platforms maintained by two different vendors.
Pricing models as a data control signal
Pricing is usually evaluated as a cost question. How much will this platform cost us this year, and how does that compare to the alternatives? That is a reasonable place to start, but it misses a more structural issue. The way a vendor prices its platform tells you something about the long-term economics of the relationship and how the balance of leverage shifts over time.
AUM-based pricing is the most common model among wealth management and reporting platforms. The family office pays a fee that scales with the total value of assets managed or reported on the platform. This is not inherently unreasonable. It aligns the vendor’s revenue with the scale of the operation it supports, and for many buyers that alignment feels proportional. But how AUM-based pricing is structured varies considerably across vendors, and the differences compound over a long relationship.
A flat-rate AUM model, where the cost per dollar of assets stays constant as the portfolio grows, produces a software expense that tracks market performance and asset acquisition directly. A year in which markets perform well or a large position is acquired becomes a year in which the software bill increases, even if the platform is not being used any differently. Over a decade, this can produce significant cost escalation that has nothing to do with how much operational value the platform is delivering. At the same time, the family office is accumulating years of data, configurations, and workflow logic inside the platform, which means the cost of staying rises alongside the cost of leaving. Those two trends reinforce each other.
FundCount uses AUM-based pricing as well, but structures it differently. Pricing is based on AUA/AUM and the number of users, with AUM charges scaled across tiers so that the rate decreases as asset levels grow. The model is designed to serve a family office managing ten million dollars and one managing a hundred billion at economics that remain proportional for each. A portfolio that doubles in value does not double the software cost, because the tiered structure absorbs growth without producing a linear increase in fees. The user-based component ties part of the cost to operational usage, which means pricing reflects both the scale of the assets and the size of the team working with them.
The practical difference shows up in long-term planning. A family office evaluating a scaled AUM model can project its software costs under various growth scenarios and see a curve that flattens as the portfolio grows, rather than one that accelerates. That predictability matters for a family office that thinks about vendor relationships in decade-long terms and wants to avoid a situation where the economics of the platform gradually shift against it.
For a family office that treats data ownership as a governance principle, pricing structure is part of that picture. A pricing model whose costs escalate in lockstep with portfolio growth creates increasing friction around the decision to stay or leave. A model that scales more gradually keeps that decision grounded in whether the platform is earning the relationship on its merits, not on the switching cost it has accumulated.
Data portability and what happens when you need to leave
Every vendor will tell you that you can export your data. That statement is almost always technically true and almost always incomplete. The question is not whether data can come out of the platform. The question is what form it takes when it does, and how much work is required to make it functional somewhere else.
Data portability depends on how the platform structures information internally. A system built on a general ledger stores data as transactions, journal entries, positions, and balances organized according to standard accounting conventions. Those conventions exist across the industry. Another accounting system may use a different chart of accounts or different field names, but the underlying logic of debits, credits, and period-based reporting is shared. Migrating transactional data from one GL-based system to another is a project with known steps. It is not trivial, but the data speaks a common language.
A platform built around a proprietary data model presents a different challenge. Addepar, for example, uses what it calls the Financial Graph, a structure that represents portfolios as hierarchies of ownership relationships with attributes attached at various levels. This is a powerful model for analysis. It allows users to shift perspective across entities, drill into any level of the ownership chain, and run calculations that account for complex, layered structures. Inside the platform, it is one of Addepar’s genuine strengths.
The portability question is what happens when that data needs to exist outside the platform. Ownership graphs, custom attributes, calculated fields, historical analytics, and reporting configurations are all built within the logic of the Financial Graph. Exporting them to a flat file or another system’s schema means translating from one data model to another, and that translation is where information can be lost, simplified, or rendered unusable without significant reconstruction. A family office that has spent years building its portfolio structure, analytics views, and reporting templates inside a proprietary model may find that those assets are effectively platform-specific.
Masttro’s aggregation model creates a similar consideration in a different form. The platform consolidates data from hundreds of custodian feeds and structures it for visualization, reporting, and document management. That consolidated view is valuable, but the aggregation logic, entity mapping, and presentation configurations are built within Masttro’s system. If the family office moves to a different platform, the underlying custodian feeds can be reestablished, but the work of mapping, normalizing, and configuring those feeds starts over.
FundCount’s transactional architecture works in its favor here. Because data enters the system as accounting transactions and is maintained in a general ledger structure, the export reflects the same conventions that other accounting systems use. Ownership structures, partnership allocations, and portfolio positions are all recorded as transactions with journal entries, which means they can be extracted in a format that retains their accounting meaning. The family office is not exporting a proprietary graph or an aggregation model. It is exporting its books.
This does not mean migration from FundCount would be effortless. Any platform transition involves mapping, validation, and testing. But there is a meaningful difference between migrating structured accounting data and reconstructing a proprietary analytical model from exported files. The first is a known process with established practices. The second is a custom project whose scope depends on how deeply the family office built into the vendor’s specific architecture.
The practical test during any platform evaluation is simple. Ask the vendor to show you what a complete data export looks like. Ask how long a migration to a different system would take. Ask what would not come with you. The answers will tell you more about your actual data control than any contractual ownership clause.
A category most evaluations miss
Most data control conversations focus on positions, transactions, and portfolio structures. That makes sense, because those are the categories that drive reporting and accounting. But family offices with active alternative investment and co-investment programs are accumulating another category of data that rarely gets the same scrutiny: the information extracted from GP documents.
Capital call notices, distribution schedules, capital account statements, quarterly reports, K-1s, and co-investment financial statements all contain data that needs to make it into the family office’s accounting and reporting systems. That data arrives as PDFs, portal downloads, and email attachments in whatever format each GP happens to use. Increasingly, family offices are turning to document extraction tools to automate the process of reading those documents and converting the contents into structured data.
The data control question here is straightforward. Once a document has been processed and its contents extracted, where does that structured data live? Is it stored inside the extraction tool as a standalone dataset? Is it held in a reporting layer that sits apart from the accounting system? Or does it post directly into the family office’s books of record, where it becomes part of the same transactional history as every other entry?
The answer matters because document-extracted data is not static. It drives capital activity, updates cost basis, affects unfunded commitment tracking, and shows up in performance calculations and tax reporting. If that data lives only inside an extraction tool or a reporting platform, it has to be reconciled against the books separately. And if the family office changes platforms, the extracted data may not come with it in a form that preserves its connection to the source documents or its downstream accounting effects.
Several vendors in the family office space now offer document extraction capabilities. Canoe processes alternative investment documents at scale. SS&C describes document aggregation and extraction using natural language processing. Masttro automates handling of capital calls, distributions, and capital statements through its AI module. Addepar has introduced workflows for automating alternatives document collection and processing. Each of these addresses the extraction problem, but each one operates as a capability within a reporting or aggregation platform, separate from the accounting system of record.
FundCount’s AI Document Intelligence takes a different approach to where the extracted data lands. Because FundCount is built on an integrated general ledger, the data extracted from a GP document can be reviewed, approved, and posted directly into the accounting and portfolio system. The extracted capital call becomes a journal entry. The distribution breakdown posts into the partnership accounting records. The source document remains linked to the data it produced, accessible from within the same system for audit support. The extracted data does not sit in a separate tool waiting to be reconciled. It becomes part of the books.
For a family office thinking about data control over a long time horizon, this distinction is worth weighing. Document volumes grow as co-investment programs expand. The cumulative value of years of extracted, structured, and posted document data is substantial. If that data is embedded in a standalone extraction tool or a reporting layer that the family office may eventually leave, it represents a category of institutional knowledge that could be difficult and expensive to reconstruct.
What to ask your vendor
The questions below are designed to surface information that most sales processes do not volunteer. A family office that asks these questions during an evaluation will have a clearer picture of where its data will live, how dependent it will become, and what it would take to change course.
Where is my data physically hosted, and do I have a choice of deployment model? If the only option is multi-tenant SaaS, understand what that means for your data residency, access controls, and security configuration. If private cloud or on-premises deployment is available, understand what it costs and whether the platform’s capabilities change depending on how it is deployed.
Does the platform include a native general ledger, or will I need a separate accounting system? If the answer is a separate GL, ask how the two systems stay in sync, who is responsible for reconciliation, and what happens to the data in the reporting platform if you change your accounting system.
Is pricing tied to my AUM? If so, model the cost over five and ten years at reasonable growth assumptions. Compare that trajectory to a pricing model based on structural complexity, and consider which one gives you more predictable costs and less incentive to stay past the point where the platform is the right fit.
What does a complete data export look like? Ask for a sample. Ask what format the data arrives in, whether it includes historical transactions or only current positions, and whether ownership structures, custom configurations, and reporting templates are included or left behind.
If I leave, what stays behind that I cannot take with me? This is the question vendors are least prepared to answer precisely, and the one whose answer tells you the most. Every platform has elements that do not export cleanly. Knowing what those are before you commit is materially different from discovering them when you are trying to leave.
How does the platform handle document-extracted data? If the platform offers document extraction for alternative investment or co-investment documents, ask where the extracted data is stored, whether it posts into the accounting system or sits in a separate module, and whether the connection between the source document and the posted data survives an export.
Who inside the vendor’s organization can access my data? Understand the vendor’s internal access policies, whether support staff can view your financial records, and what controls exist to limit and audit that access.
Closing thoughts
Data ownership is a function of where the data lives, how it is structured, whether it can move, and whether the economics of the platform make it progressively harder to exercise the control you were promised when you signed.
Family offices apply this kind of thinking to every other relationship they manage. They negotiate custody arrangements to ensure they can move assets. They structure investment vehicles to preserve governance rights. They review counterparty risk as a matter of course. The technology platform that holds the financial record of the family’s wealth deserves the same scrutiny.
FundCount was designed around the principle that a family office’s data should remain under the family office’s control. A unified general ledger means the books of record live in one system, not split across a reporting layer and a separate accounting tool. Flexible deployment means the family office chooses where the data resides based on its own governance requirements, including on its own infrastructure. Pricing based on structural complexity means the cost of the platform stays proportional to the work it does, not the value of the assets it reports on. And AI Document Intelligence means that the growing volume of GP documents feeding alternative investment and co-investment programs converts into structured accounting data inside the same system, not inside a standalone tool the family office would have to rebuild if it moved on.
If you are evaluating platforms or reconsidering the one you are on, start with the questions in the previous section. They will tell you more about your real position than a feature comparison ever will. If you want to see how FundCount answers each of them with your specific structures and requirements, we are happy to walk through it.
