The shape of the problem
A family office is an accounting problem disguised as an investment operation. There are entities — trusts, holding companies, LLCs, partnerships, a foundation — and each has its own bank accounts, its own custodians and its own reporting obligations to somebody. Nobody outside the office has a complete picture and often nobody inside does either.
The documents reflect that fragmentation. Bank statements from several institutions in several countries, custodian statements in their own formats, capital call and distribution notices as PDFs from each fund manager, plus whatever the family's operating businesses produce. Very little of it arrives as data.
So the work that consumes an analyst's month is not analysis, it is assembly: downloading, reading, retyping, checking, and then producing a consolidated view that is out of date by the time it is presented. This page is about the assembly.
Intercompany transfers are where consolidation goes wrong
Money moves internally constantly: a trust funds an LLC, the holding company sweeps cash, a partnership distributes to its partners who are themselves entities in the same structure. Each of those movements appears twice in the underlying data — once as an outflow, once as an inflow.
Total them naively and the office reports inflows that never came from outside and outflows that never left the family. On a structure with regular internal funding, that inflation can be substantial enough to make a consolidated cash-flow statement actively misleading rather than merely imprecise.
Elimination is the fix and it needs matched pairs: same date or within a day or two, same amount, opposite signs, two accounts you own. That match is only possible when every account's transactions sit in one dataset with an entity column — which is the single most valuable thing conversion produces here.
Every custodian reports differently
Custodian statements are not bank statements. They mix cash movements with positions, corporate actions, accruals, fees and income, and each firm presents them in its own idiom — different names for the same thing, different treatment of pending trades, different placement of the cash summary.
For most family office reporting, the cash and income lines are what matter for the operational picture: dividends and interest received, fees charged, subscriptions and redemptions, cash sweeps. Extracting those consistently across custodians is what makes a combined income view possible.
Where the requirement is genuinely portfolio accounting — cost basis, unrealised gains, time-weighted returns — that is a different discipline and a different system. We say so plainly in what we are not; this is the cash and document layer beneath it.
Capital calls and distributions arrive as PDFs from people who like PDFs
Private equity, venture and real estate funds communicate by notice: a capital call with a due date and wire instructions, a distribution notice with a breakdown between return of capital and gain, an occasional recallable-distribution wrinkle that changes what the number means.
These are among the least standardised documents in finance and among the most consequential — a missed call has real penalties, and a distribution misclassified as income distorts both reporting and the eventual tax conversation. They arrive by email, from dozens of managers, in dozens of layouts.
Extracting them gives the office a commitments and flows register: fund, entity, date, amount, type, and the wire that settled it. Matching that register against the bank data is how you know a call was actually paid and a distribution actually landed — which is not the same as knowing a notice was received.
How this differs from our statement-type pages
Investment statement converter, brokerage statement to Excel and dividend statement to Excel are document-type pages: one statement, one format, one output. If you have a Schwab or Fidelity statement to convert, those are the right pages and they go into more detail on the format.
This page is about the operations around many such documents at once — several entities, several institutions, several currencies, and the consolidation rules that only exist when you own more than one account.
The two are complementary. Use the document-type pages to understand what comes out of any single statement; use this one for the structure that sits above them. Crypto statement to Excel covers digital-asset holdings where the family has them.
The entity column is the whole design
If there is one structural decision that determines whether a consolidated dataset is useful, it is tagging every row with the entity and the account it came from at the moment of conversion — not later, from memory, when three files have been merged and nobody is sure which trust the second one belonged to.
Merging supports that directly: many statements in, one workbook out, with a source column per row. Add an entity mapping beside it and every question — by entity, by custodian, by currency, by month — becomes a pivot rather than a project.
Keep the entity naming stable across years. Structures change, entities get renamed after a restructuring, and a consolidated history where the same trust appears under three names is a history nobody can chart.
| Layer | Where it lives | What conversion contributes |
|---|---|---|
| Bank accounts per entity | Several banks, several countries | Every transaction with date, narrative, amount, balance |
| Custodian accounts | Brokerages and private banks | Cash, income, fees and flows as rows |
| Private fund positions | Manager notices by email | Calls and distributions as a register |
| Operating businesses | Their own ledgers | Statements where no feed exists |
| Consolidation | Your spreadsheet or reporting tool | One dataset with entity and source columns |
| Portfolio performance | Portfolio accounting software | Nothing — that is not us |
Multi-currency, handled honestly
Accounts in different currencies cannot simply be added. A consolidated total requires a rate, a rate requires a date convention, and the choice between closing rate, average rate and transaction-date rate changes the answer materially — which is a policy decision for the office's accountant, not a technical default.
What extraction does is preserve what the statement actually said: the amount as printed, in the currency of the account, with European and Anglo decimal conventions both parsed correctly. Converting to a reporting currency happens afterwards, with your rates and your policy, visibly.
Never let a tool silently convert. A consolidated figure produced with an unstated rate is a number nobody can reproduce next quarter, and reproducibility is most of what family office reporting is for.
Proof per account, before consolidation
Consolidation multiplies errors. A single dropped transaction in one of fifteen accounts is invisible in a combined total and impossible to find later, because the combined total has no arithmetic of its own to check against.
The discipline that prevents it is checking each account individually before anything is combined: opening balance plus transactions equals closing balance, per account and per period. We run that automatically on every statement and flag failures rather than passing them on.
Then check the seams. Each month's closing balance must equal the next month's opening — the test that finds the statement nobody downloaded. In a fifteen-account structure that check is the difference between a consolidated report you can sign and one you merely hope is right.
The checks to run before anything is consolidated
Consolidation hides errors, so the checking happens before it, per account and per period. Each of these is mechanical, takes seconds once the data exists, and answers a question that becomes unanswerable after everything is added together.
Run them in this order. Each one narrows what the next has to explain, and the first three are the ones that catch the errors nobody would otherwise find.
| Check | What it catches | Run at |
|---|---|---|
| Opening + transactions = closing | A dropped or misread row in one account | Per account, per statement |
| Closing = next opening | A missing statement or period | Per account, across months |
| Currency consistency | Amounts summed across currencies | Before any total |
| Internal transfer pairing | Double-counted inflows and outflows | Across all accounts in the perimeter |
| Entity tag present | Rows that cannot be attributed | Every row, at conversion |
| Capital call settled | A notice with no matching wire | Register against bank data |
| Distribution received | A notice that never arrived as cash | Register against bank data |
What the family actually asks for
Principals rarely ask for portfolio analytics. They ask three things: how much cash do we have and where, what went out this quarter and to whom, and are we committed to anything we have to fund. All three are answerable from consolidated transaction data plus a commitments register.
That is worth remembering when someone proposes a large system implementation. A great deal of family office reporting is a cash and flows question that a well-built workbook answers, provided the underlying data is complete and tagged. The sophistication that matters is in the data hygiene, not the dashboard.
Where genuine performance measurement is required — returns net of fees, benchmark comparison, attribution — that is portfolio accounting software's job, and it should be fed by custodian data rather than by anything reconstructed from PDFs.
Fees are the quiet line worth extracting
Fees leave in small amounts from many places: custody fees, management fees, performance fees inside funds, bank charges, wire fees, FX spreads that never appear as a line at all. Individually trivial, collectively one of the largest and least examined costs a family bears.
Getting them into one dataset is the only practical way to see the total. Filter by narrative across every account and entity, group by counterparty, and the annual figure usually surprises somebody — which is precisely the conversation the office exists to enable.
The caveat is honest: fees embedded inside fund NAVs do not appear as transactions anywhere, and no amount of statement conversion will surface them. Those come from fund reporting, and knowing the difference between visible and embedded costs is part of the job.
Foundations and philanthropic entities have their own reporting
A family foundation or donor-advised structure usually has its own accounts, its own board, and reporting obligations that look more like a charity's than an investment vehicle's. Grants out, investment income in, administrative costs, and often a required distribution level.
Keeping that entity's data cleanly separated within the consolidated set is important — mixing philanthropic flows into family cash reporting produces a picture that is wrong in both directions. The entity column does this if it is applied consistently from the start.
Where the foundation's own reporting resembles nonprofit accounting, bank statement converter for nonprofits covers the restricted-fund discipline in more detail.
The family's operating businesses complicate everything
Many family offices sit alongside operating companies, and the boundary between them is often blurred by shareholder loans, management charges and cash sweeps. Those transactions are internal from the family's perspective and external from the company's, and both views are legitimate.
Deciding the consolidation boundary explicitly — which entities are inside the reporting perimeter and which are investments — is a policy decision that has to be made once and applied consistently. It is not a data question, but the data has to support both views without being restructured.
Practically that means tagging by entity rather than by classification, so the perimeter can be redrawn in a pivot instead of in a rebuild. Classification changes; the underlying rows should not have to.
Taking on a structure that has never been consolidated
New family office mandates frequently begin with a decade of documents and no dataset. The realistic first deliverable is not a dashboard, it is a complete, proven transaction history by entity for a defined period — usually two to three years.
That is a batch job: convert everything at once, merge with source and entity columns, run the per-account and month-seam checks, and produce a gap list of missing statements to request. The gap list is often the most valuable output of the exercise, because nobody knew what was missing.
Only then is it worth arguing about reporting formats. A beautiful report built on an incomplete history is a liability, and in a family context it is a liability that gets quoted back at you for years.
Discretion, and what that means technically
Family office documents are sensitive in a way ordinary business documents are not: they name individuals, reveal wealth structure, and often involve people who have strong reasons to limit circulation. That deserves a straight answer rather than reassurance.
Technically: documents travel over TLS, processing happens in the EU, originals are deleted immediately after extraction, extracted data is encrypted at rest, and no customer document is used to train models. The security page lists sub-processors.
What we do not offer is on-premise or air-gapped deployment. If the office's policy is that documents must never leave its own infrastructure — a legitimate position at this end of the market — then no hosted service qualifies, and building in-house is the honest alternative. That comparison is on parsing statements in Python.
Tax sits downstream, and stays there
Consolidated transaction data is an input to tax work across several jurisdictions, and it is a good one — but it is not a tax computation and it does not become one. Characterisation of a distribution, treatment of a partnership allocation, residence questions and reporting obligations are all professional judgements.
We do not issue, interpret or reconcile any tax form, including partnership schedules, and we do not decide whether something is income, return of capital or a gain. Where a fund's notice states the split, extraction reports what the notice says; the accounting treatment remains a decision for the office's advisers.
What good data does is shorten the adviser's questions. A complete, entity-tagged transaction history with supporting notices attached is the difference between a fee estimate and a fee surprise.
Where this sits beside real systems
Family offices at scale run portfolio accounting or general ledger software, sometimes both, plus a document management system. Those are the right homes for positions, valuations, partner capital and archives, and this is not a replacement for any of them.
The gap it fills is the same one every office describes: the institutions with no feed, the private fund notices that arrive as email attachments, the historical periods before the current system, the offshore account nobody has ever managed to automate, and the operating company that sends a PDF.
Where a genuine custodian feed exists, use the feed. Conversion is for the documents that never became data — which, in a multi-entity, multi-jurisdiction structure, is a surprisingly stable share of the total.
The boundary, stated plainly
FlowParse is a document-extraction engine. It is not portfolio accounting or performance software: no cost basis, no unrealised gains, no time-weighted or money-weighted returns, no attribution, no benchmark comparison. It is not partnership accounting: no partner capital accounts, no allocations, no waterfalls.
It is not a custodian aggregator — there are no feeds, no credentials and no account connections; where a feed exists you should use it. It issues, interprets and reconciles no tax forms, and it gives no investment, tax or legal advice of any kind.
It offers no on-premise or air-gapped deployment, and it is not an archive: originals are deleted immediately after extraction, so the documents themselves must live in the office's own storage. The extracted data is a working record; the institution's statement remains the evidence.
A worked example: nine entities, three currencies
A single-family office reported quarterly to two principals across nine entities, five banks in three countries, two custodians and eleven fund commitments. The quarterly pack took an analyst about six working days, most of it retyping, and the cash figures never quite agreed with what the principals saw in their own online banking.
The rebuild was unglamorous. Every account converted for the period in one batch, entity and source tagged per row, each statement proven against its own balances, month seams checked, then internal transfers paired and flagged for elimination. Fund notices extracted into a commitments register and matched to the wires that settled them.
Two things came out of the first run. The consolidated inflow figure the office had been reporting was materially overstated by internal funding that had never been eliminated, and one custodian statement for a prior quarter had never been received at all — found by the closing-to-opening check rather than by anyone noticing. The pack now takes about a day and a half, and the numbers reconcile to the accounts.
Where to start
Resist starting with the reporting format. Every family office that builds the report before the dataset rebuilds the report within a year, usually the week after somebody asks a question the data cannot answer.
1. List the accounts
Every entity, every institution, every currency. The list itself is usually the first surprise.
2. One quarter, everything
Convert one full period across all accounts rather than a year of one account.
3. Tag at conversion
Entity and source columns on every row, named consistently and permanently.
4. Prove each account
Opening plus transactions equals closing, per account, before anything is combined.
5. Check the seams
Each closing balance against the next opening balance — this is what finds missing statements.
6. Pair the internal transfers
Same amount, opposite signs, both accounts yours. Flag them before totalling anything.
7. Then report
Cash by entity, flows by counterparty, commitments outstanding. Dashboards last, data first.
Where to go next
For the mechanics see bank statement to Excel and investment statement converter; for many documents at once see batch processing; for combining entities and periods see consolidate bank statements and merge PDF to Excel.
For the completeness argument, bank statement validation. For specific document types, brokerage statement to Excel, dividend statement to Excel and crypto statement to Excel.
If the office builds its own tooling, the document extraction API and parsing statements in Python cover the developer path, including the case for keeping everything in house.
One dataset, every entity
Convert every account for the period, prove each one against its own balances, and eliminate the internal transfers before anything is totalled.