How we onboard a fund: every number tied back to your books.

Every fund manager who has changed systems knows the moment. The new platform is configured, the demo looked right, and now ten years of drawdowns, distributions, TDS, units and side arrangements have to move across. Usually that means somebody retyping values into upload templates, an import that reports "completed", and a quiet hope that the totals still match.

We don't think a migration should rest on hope. It should end with proof: a reconciliation, row by row and total by total, against the figures you already trust, and a written report that shows exactly how your data became ours.

This piece describes how we do it: the people, the rules they never waive, the tooling they built, and the reconciliation every onboarding has to pass before it is allowed to go live.

It starts with people who have done this before

CapHive was built by a team with deep experience in private capital markets and in capital-markets technology, and our onboarding is run by fund-operations people, not by implementation generalists. They know what a capital call is for, why a redemption and a gain distribution are taxed differently, and why a unit balance that is right in total can still be wrong for one folio.

That matters more than any tool, and we learned it the useful way. On an early rehearsal, our automated reconciliation passed 10,992 checks out of 10,992. A fund-ops reviewer then read the result the way an auditor would, and found three things the green ticks had missed:

• Capital calls that never happened. The source recorded drawdowns per investor. Grouping "each investor's first drawdown" into one call produced a call that spanned eight years, which is not a fund event. Calls are now built only from real fund-level events, and when the data cannot say which drawdowns belong together, the question goes to the client instead of being guessed.
• Values nobody gave us. Payment references had been filled in to look tidy. Now an optional field stays blank unless the client supplied it.
• Tax modelled in the wrong place. TDS had been stored alongside each payment as information, so the platform's net payable still equalled gross. TDS now goes in as account entries linked to the distribution as a tax fee, and the distribution is recomputed, so what investors see is net of tax, exactly as in the client's books.

Each finding became a rule in the method, and the reconciliation was rebuilt so that it compares the client's figures with what the platform computes and shows investors, not with values we wrote ourselves. That is also why no onboarding goes live without a fund-ops reviewer's sign-off, however green the checks are.

Mapping: every column has exactly one home

A client's workbook is the product of years of good practice and local habit. Before we write a line of transformation, every column in it is accounted for. Each one ends in exactly one of three places, and a mapping file records which, and why:

Nothing falls through the gaps, and nothing is quietly turned into free text. A typed field created up front is the difference between "Initial ownership (%)" you can sort and total, and a text box nobody can use.

Reshaping: written as code, never retyped

No value is typed by hand. The transformation from the client's layout into the platform's import templates is a script, so it is repeatable: run it twice and you get the same file, and a rebuilt file can be proven identical to one already loaded. Our tools already read the layouts funds actually use:

• One row per folio, with payments as repeated date-and-amount column pairs.
• Folio blocks: an opening row with the commitment, then a row per drawdown underneath.
• One column per call, as in a quarterly capital-account pack, with call dates taken from the schedule and the folio's receipts allocated oldest first.
• Monthly MIS packs for portfolio KPIs, where a P&L file and a cash-flow file for the same month are merged into one workbook, cell for cell, with a check that every cell equals its source.

The details are where migrations usually go wrong, so the tooling carries the lessons. A few that each cost someone, somewhere, a bad quarter-end:

• Dates are written as real dates, never as text. Text is parsed by locale, and 05/04/2021 quietly becomes 4 May instead of 5 April.
• Invisible characters are cleaned. Names with embedded line breaks and byte-order marks look identical on screen and match nothing.
• One remittance per folio per call. When an investor paid a call in several instalments, the instalments stay as separate payments under one remittance, which is how the call actually happened.
• Money is modelled the platform's way. Tax, fees and expenses go through the mechanisms that drive net payable and capital accounts, never into a side field that looks right and computes nothing.
• Labels are matched the way the reader matches them. Before any KPI is mapped, every line label is checked against the actual MIS, so a mapping that could never fill is caught on day one, not discovered blank a quarter later.

The script also checks itself before it stops. If a folio's payments do not add up to the client's received total, or called does not equal received plus outstanding, the build refuses to produce files at all.

Reconciliation: tick and tie, then prove the check can fail

The reconciliation is the heart of the method, and it is deliberately independent of the transformation. It does not reuse the script that built the files. It reads your raw rows again with its own reader, reads the platform through its API, and compares the two. A mistake in the transformation cannot hide by being repeated in the check.

It works like a careful auditor's tick and tie. Each source row is matched to a platform record by folio, date and amount, and that record is taken out of the pool so it cannot be counted twice. Then it runs these tests:

1. Source to platform. Every folio, drawdown, payment and distribution in your file exists in the platform, with the right amount, date, class and fields.
2. Platform to source. Nothing is left over: no record in the platform without a row in your file.
3. Per folio. Committed, called, received, outstanding and the number of payments, for every investor.
4. Per call. Each call equals the sum of its remittances and of your rows. Collected equals the sum of payments. Each call is a real event, checked against your own drawdown dates, and approved.
5. Your own totals. The total cells and summary rows in your workbook, compared with the fund's figures in the platform.
6. Distributions. Every entry is matched to one payment. Gross, tax and the platform's computed net payable all equal yours.
7. Units. Issued, redeemed and the balance for every folio, to four decimal places, against your register.

Tolerances are tight: one paisa or cent on money, 0.0001 on units, and dates exact. The portfolio side follows the same discipline: companies, investments and valuations are reconciled to your holdings, and every KPI value is tied to the exact cell it came from in your MIS before it is approved.

The report you keep

Every onboarding ends with a written report, and the tooling will not let it be skipped: the run cannot move on to investor access until the report is newer than the latest reconciliation and carries its result. It has four parts:

• The checklist: every stage, and its status.
• How your data was mapped: each modelling decision with its reason, following one ordinary folio from your rows, through the records built from it, to its units arithmetic.
• The proof: the reconciliation's results, with the full per-folio tables in an appendix.
• The log: what ran, when, and what it read back.

Alongside it is the list of questions for you, each assumption with its number, so you can see exactly what we inferred and confirm or correct it. Go-live is blocked while any question marked "needed before go-live" is open.