A family office rarely has a transaction volume problem. It has a structure problem. Eleven entities, some of them LLCs, some trusts, a foundation, two operating businesses and a handful of property holdings, each with its own bank account, its own year-end quirks and its own set of people entitled to see it.
That is why family office accounting software is a different purchase from ordinary accounting software. The pain is not the number of invoices. It is that a consolidated view of the family’s position requires somebody to open twelve files, apply ownership percentages from memory, and rebuild a workbook that only they fully understand. When that person is on leave, the family flies blind.
What follows is the implementation view: what has to be designed, what the software genuinely handles, what you will still need elsewhere, and where these projects run into trouble.
Key Takeaways
- Entity structure, not transaction volume, drives cost and timeline. Design the entity and ownership model before anyone configures anything.
- Continuous consolidation removes the monthly rebuild. Inter-entity eliminations and due to and due from accounts have to be designed for it to be trustworthy.
- Access design is a first-class requirement here, not an afterthought. Deciding who can see which entity is often the most sensitive conversation in the project.
- This is a general ledger, not a portfolio accounting system. Positions, performance and partnership waterfalls stay with your custodian or specialist tools.
- New entities get added constantly in a family office. Build the setup so adding entity twelve is a template, not a project.
Screenshots throughout are Sage Intacct product material. The figures shown in them are Sage’s demonstration data, not Lucentive client results.
What family office accounting software has to do that ordinary accounting does not
Family office accounting software has to hold many small entities in one place, consolidate them continuously, keep them logically separate for privacy and tax, and let the same chart of accounts and reporting structure apply across all of them. Ordinary accounting software assumes one company. That single assumption is what breaks.
The requirements that keep recurring in scoping sessions are worth naming. Multiple legal entities with different fiscal year-ends and different bases of accounting. Ownership percentages that vary by entity and change when a structure is reorganised. Capital accounts and allocations for partnerships and LLCs. Bill payment for household and property expenses coded to the right entity, with approval routing that respects who may authorise what. And a two-headed reporting requirement, because the family wants a plain-language picture and the CPA wants a clean trial balance per entity.
Sage Intacct handles this through entities in a multi-entity structure plus dimensions for everything else. The dimensional part matters more than people expect at the start: property, asset class, family member, purpose and funding source are all dimensions rather than accounts, which is what keeps the chart of accounts small across a dozen entities instead of multiplying. Our explanation of how dimensions work in practice is the single most useful thing to read before your design workshop.
Continuous consolidation across entities, and what it replaces
Continuous consolidation means the consolidated view is maintained as transactions post, rather than assembled at period end. Open the consolidated entity and the numbers are current. There is no consolidation run to schedule, no workbook to refresh, and no window where the parent view and the entity views disagree with each other.
Notice the eliminations slice in the revenue chart above. That is the part that separates real consolidation from addition. Family offices are full of inter-entity activity: a management company charging the trusts, a holding entity funding an operating business, one entity paying an expense on another’s behalf. If those are simply summed, the consolidated numbers are inflated and every one of those inflations is a question at the next family meeting.
The design work is in the inter-entity rules. You decide which entity pairs transact, how due to and due from accounts are structured, and whether inter-entity transactions post automatically to both sides or route through a review. Get that right and consolidation is genuinely maintenance-free. Get it approximate and you will spend the first two quarters explaining variances that are artefacts of your own setup. The broader case for this approach is covered in our piece on consolidating and automating finances for multi-entity organizations.
[DATA: Lucentive’s typical entity count at go-live across family office implementations — Rich to confirm]
A real-time pulse on the financials, with custom dashboards and controlled access
Custom dashboards give the family office a real-time pulse on the financials: consolidated cash, net income by entity, balance sheet by entity, and whatever the principals actually ask about. The important design question is not what goes on the dashboard. It is who is allowed to open it.
What a family office puts on that top row is narrower than most dashboards: cash by entity and in total, distributions made year to date, capital calls outstanding, and the two or three balances the principals ask about by name. Everything else can live one click down. The honest caveat is that a daily view is only as current as the things feeding it. Bank feeds have to be connected and reconciled on a rhythm somebody owns, and expenses have to be coded to the right entity when they are entered rather than corrected at quarter-end. The same applies to the property and household bills that arrive without an obvious entity attached, because someone has to decide at entry which entity bears the cost. A dashboard built over inconsistent coding is worse than a spreadsheet, because it looks authoritative. Agree the coding discipline and the reconciliation cadence during design, and name who owns both.
The entity selector in that screenshot is the whole feature in one control. Sitting at top level you see the consolidated position. Pick an entity and every panel on the page re-scopes to it, without a different report and without exporting anything. For a family office director who is asked about the foundation on Tuesday and the property partnership on Wednesday, that one control removes most of the ad hoc reporting requests.
Access design deserves genuine project time and is usually the most delicate conversation we facilitate. Branches of a family are frequently not entitled to see each other’s entities. An outsourced bookkeeper may need entry rights in two entities and nothing else. A trustee may need read access to one entity’s statements and no sight of the operating company. Role-based access handles all of it cleanly, but only if somebody decides it explicitly, entity by entity, before go-live rather than after the first uncomfortable discovery. There is more on how the reporting layer gets built in our guide to dashboards and reporting.
Integrating with the systems you already run, and what stays outside
You can easily integrate the ledger with existing and new systems through its API and prebuilt connectors: bill payment, expense capture, payroll, banking feeds and document storage all connect without custom development in most cases. What matters more for a family office is being clear about what should deliberately stay outside the ledger.
This is where honesty saves you money. Sage Intacct is a general ledger and a strong one. It is not a portfolio accounting system. It does not track security-level positions, calculate time-weighted returns, model a partnership distribution waterfall or produce K-1s. Those belong with your custodian, your portfolio accounting provider and your CPA. What the ledger does is hold the investment entities’ book values, cash movements and expenses, and reconcile cleanly to the statements those other systems produce.
The practical pattern that works is a periodic journal from the custodian or portfolio system into the ledger at whatever granularity your accountants need, rather than trying to mirror positions transaction by transaction. Decide that granularity during design. Teams that decide it late usually over-engineer it, then quietly stop maintaining the detail within a year. If your office also holds property vehicles, which most do, the requirements overlap heavily with what we cover in real estate accounting software.
What the cloud actually changes here
Access from anywhere is the headline, and for a family office with principals in three time zones and an outsourced accounting team, it is a real benefit rather than a slogan. The larger change is that there is no longer a file. No workbook on somebody’s laptop, no server in a closet, no version that got emailed and then edited.
Two consequences are worth planning for. Continuity improves substantially, because the office is no longer one person’s institutional memory plus one machine. And the audit trail becomes complete, which is unfamiliar and occasionally uncomfortable for teams used to adjusting a spreadsheet. Every entry has a user, a timestamp and a history. Where trustees and beneficiaries need assurance that trail is an asset, and it is worth saying so early to a team that first experiences it as scrutiny.
Security is a fair question and deserves a straight answer: the platform provides the controls, and your configuration decides whether they are used well. Multi-factor authentication, IP restriction, role-based permissions and entity-level restriction are all available. Whether your family office is actually protected depends on the access design discussed above, which is a project deliverable and not a product feature.
Where family office implementations get stuck
Four patterns account for most of the difficulty, and none is about the software. Each is a decision that needs someone with authority in the family or the office to make it, and each gets harder the longer it is deferred.
The entity list is not final when configuration starts
Structures move. An entity is added, another is being wound down, one is mid-reorganisation. Freeze the list for go-live, and separately design how a new entity gets added afterward so that adding number twelve takes an afternoon and follows a template.
Nobody owns the ownership percentages
Allocations depend on percentages that live in legal documents, sometimes contradictory ones. Have counsel or the family’s accountant confirm them in writing before they are configured. Reconstructing an allocation later means restating months of activity.
Access design is left until user acceptance testing
By then the project is committed and the conversation about which family members see which entities becomes urgent instead of considered. Start it in week two, in a room with whoever is entitled to decide.
The historical data question is answered by default
Migrating years of detail across a dozen entities is expensive and rarely worth it. Most offices are best served by opening balances plus one comparative year, with the old system retained read-only. Decide it deliberately, because deciding it by drift is how budgets go. Our guidance on planning the costs, time and resources for an implementation covers how that trade-off usually falls.
Summary
The value here is structural. A family office running a dozen entities on spreadsheets and separate ledgers has a consolidated picture that is always slightly out of date and always dependent on one person. Moving to a multi-entity cloud ledger makes that picture continuous and shared. The work that produces the result is not the software installation. It is the entity model, the inter-entity rules, the dimension design and the access matrix, and those four are where the project should spend its thinking time.
Be equally clear about what stays outside. Portfolio positions, performance and tax filings live elsewhere and integrate cleanly. Anyone who tells you one system does all of it is selling rather than implementing.
If you are weighing this up, the most productive preparation is to draw your entity structure on one page, mark who is allowed to see each box, and note which entities transact with each other. That page drives most of the design. Bring it to us and our consultants will walk you through what the configuration would look like and what it would take. Start a conversation with our team when you are ready.
Frequently Asked Questions
What is family office accounting?
Family office accounting is the bookkeeping, consolidation and reporting for the entities a family uses to hold and manage its wealth: operating businesses, holding companies, trusts, partnerships, foundations and property vehicles. The distinguishing feature is structural complexity rather than volume. A relatively small number of transactions has to be maintained across many legal entities, consolidated accurately, and reported with tight control over who can see what.
What is the difference between single family office and multi family office requirements?
A single family office typically has fewer entities but more sensitive access rules, because branches of one family may not be entitled to see each other’s holdings. A multi family office has all of that plus clean separation between unrelated clients, client-level billing and reporting, and usually stricter audit expectations. The underlying platform is the same; the access design and reporting workload are meaningfully larger for the multi family model.
Can it handle capital accounts and partner allocations?
It handles the ledger side well. Capital accounts are maintained per partner or member, and allocations can be configured to post by ownership percentage across entities. What it does not do is model a distribution waterfall with tiers, hurdles and catch-ups. If your partnerships have that structure, expect to keep a specialist tool or a maintained model for the waterfall and use the ledger for the resulting entries.
Does it produce K-1s or handle tax filing?
No. It produces the clean, entity-level trial balances and supporting detail that your CPA needs to prepare returns and K-1s, which is usually where most of the preparation time goes. The tax filing itself stays with your accountants. In practice the benefit shows up as a shorter and less argumentative year-end, because the accountants receive reconciled books per entity rather than a workbook they have to interrogate.
How long does a family office implementation take?
Timeline is driven by entity count, how settled the structure is and how much history you migrate, rather than by transaction volume. A stable structure with opening balances only is a much shorter project than one mid-reorganisation with years of detail to bring across. The reliable predictor is how quickly the family can give final answers on entity list, ownership percentages and access.
Can we add new entities after go-live?
Yes, and you should assume you will, because family structures change constantly. The thing that determines whether it is easy is how the original configuration was built. If the chart of accounts, dimension structure and reporting are shared rather than entity-specific, a new entity is largely a copy with a few decisions attached. If each entity was configured as a one-off, every addition is a small project of its own.