500+ statements, one run.

The engagement

An early-stage fund, 500+ LPs, three requirements. Automate the computation of fees and NAV so the figures are right. Generate customised account statements in the fund's defined format, with variations for selected investors. And distribute them to LPs through secure channels.

Most platforms treat those as three systems: an accounting engine, a document generator, and a delivery mechanism. The reason this fund's quarter used to take a fortnight — two people, ten working days — is that a human sat between each pair. The same cycle now runs in three working days, one person, with half a day of review from a second.

Where the fortnight went

Fees computed in a workbook. NAV assembled from the workbook. Statements mail-merged from an export of the workbook. Then someone opens twenty at random to check them, finds one wrong, fixes the workbook, and has to work out which statements were produced before the fix.

The failure isn't any single step. It's that "the numbers" and "the documents" are two artefacts that have to be kept in agreement by a person who is tired.

Step one — the numbers are computed, per folio, from formulas

Each folio's account entries are produced by fund formulas: named rules the fund defines, evaluated per commitment with that commitment's own data in scope. Management fees, custody fees, admin costs, audit fees, bank charges — each becomes an account entry against each folio, with the fund-level totals rolled up alongside.

Formulas can carry period semantics, so the same underlying rule produces Quarterly, YTD and Since Inception views, and entries are named accordingly ("Quarterly Management Fees", "YTD Management Fees"). One rule type generates entries for several fee types at once — a reporting set that used to need fifteen formulas collapses to three, with identical output.

Re-running a period is safe: entries from the previous run for that period are replaced, not duplicated. This is the single property that makes iterating on a close bearable.

Step two — the run that also writes the documents

An allocation run takes a fund and a date range and does the work in one pass: computes the entries, optionally computes fund ratios, and — if you ask it to — generates the investor statements from the same numbers in the same run.

You choose what the statement is for:

• Commitment — one statement per folio.
• Investing entity — one combined statement per investor across their folios, which is what an LP holding four folios actually wants to receive.

Runs are recorded, and a locked run blocks a new run that overlaps its period. Once a quarter has been reported, you cannot casually recompute it underneath the statements you already sent — the platform tells you which locked run stands in the way, with its dates.

Step three — the fund's own format, with variations

Statements are produced from Word templates that the fund controls. The template is filled from a context built for that specific commitment: committed amounts before the period start, before the period end and the movement between; called, collected and uncalled; every remittance and remittance payment ordered by date; distributions with income, cost of investment, reinvestment, gross and net payable; the folio's account entries and the fund's; fund ratios; commitment adjustments. Amounts appear in both fund and folio currency, and the committed amount is also rendered in words.

"Variations for select investors" is not a fork of the process. A different template is selected — templates can be attached at fund level or against a specific commitment — and the same run produces the different document for the investors who need it.

Step four — the refusals, which are the important output

A bulk statement run does not silently do its best. It refuses in three specific cases, and reports each one by name:

1. The commitment is flagged to skip document generation.
2. The commitment has no linked investor KYC.
3. The commitment's KYC exists but is not verified.

Each refusal is collected, counted, and emailed to the person who started the run as an itemised error list — "completed with 11 errors", with the eleven commitments named. Everything else completes.

That behaviour is worth more than it sounds. The alternative — generating a statement against an unverified identity record — is exactly the failure you find out about from a regulator rather than from a job notification.

⚙️ Under the hood: three details that carried the 5×

The statement is filed, not just produced. Each document lands in that commitment's statement folder, stamped with the period start and end dates in its name and an "as of" date equal to the period end. Nobody assembles a folder afterwards; the investor's file assembles itself.

Delivery can be password-protected per notification. Where a fund enables it, the attached PDF is encrypted before it is sent, with the password taken from a configured attribute of the investor's own record — so it is something the investor already knows and nobody has to distribute a key. Where a link is more appropriate than an attachment, the download link expires after a week rather than living forever in an inbox.

The follow-up question has a self-serve answer. The predictable email after any statement run is "why is my management fee higher this quarter?" The Account Entries Period Report answers it at folio level: totals for the period, a breakdown by entry type, a trailing-period trend against recent quarters, and the individual entries underneath. An investor with portal access can open their own folio's report; employees can open the fund-level view and drill into any folio. On demand — and only on demand — an AI commentary can be generated for a section, in plain language, flagging anomalies against the trailing history: "Management Fee is 42% above its trailing 4-quarter average."

It never runs on page load. Nothing fires unless someone clicks Generate, so opening a report stays fast and nothing is being written on your behalf in the background.

📊 The impact

Before: ten working days of elapsed time per quarter with two people on it for most of them — roughly 20 person-days — and the exceptions found by opening twenty statements at random and hoping the twenty-first was fine.

After: three working days, one person, plus half a day of review from a second — roughly 3.5 person-days, which is the over 5× above. Every exception is named in an itemised list emailed when the run finishes, so none of them is found by sampling.

That came from three structural changes rather than from anyone working faster. The numbers and the documents stopped being separate artefacts — one run produces both, from the same entries, so they cannot disagree. Re-running a period replaces rather than duplicates, so correcting a fee mid-close is a re-run instead of an archaeology exercise. And the exceptions became an itemised list emailed to the person who ran the job, rather than a silence you interpret afterwards.

Five hundred statements is not five hundred pieces of work. It is one piece of work and a short list of exceptions.

On these figures. The workflow and platform behaviour described above are exactly as CapHive runs them. The before-and-after figures in this section are a modelled composite — built from the platform's own behaviour and the hand-run baseline typical of a fund of this size — not a measurement taken at a single named client.

What to take from this

Where this goes next

Statements depend on verified investor records — see onboarding 200+ LPs — and on the entries produced by the same engine described in multi-currency computations and reporting. To see a statement run on your own structure, book a walkthrough.

Client name withheld, and the before-and-after figures in The impact are a modelled composite rather than a client-verified measurement — see the note there. The workflow, platform mechanics and behaviour described are exactly as CapHive runs them.