The engagement
A venture capital fund with a multi-currency portfolio, asking for six things: automated computation of portfolio-related fund accounting to remove errors; allocation to investors using ratios that fluctuate with each capital call; portfolios spanning multiple currencies; real-time dashboards; custom fields retained on individual investments; and oversight of financial instruments converting into other instruments.
That list looks like six features. Operationally it is one question asked six times: when this number is expressed in a different currency, which day's rate applies?
Why the workbook version drifts
Every multi-currency GP has built the consolidation spreadsheet. Someone builds it for Q1, makes a dozen reasonable rate-date decisions, most of them undocumented and some buried in cell formulas. Next quarter, under deadline, someone extends it. A year later a different person adds a fund and picks a defensible date — a different defensible date.
Nothing there is negligent. It is what happens when a rule lives in a formula instead of a policy. You usually discover it when an auditor asks why the same commitment converts at two different rates in two different reports.
Converting currency is trivial. Choosing the date is the whole job — and a rule applied by a person is a rule that drifts.
Layer one — the instrument's own currency
An investment instrument is the actual security: "Series A Equity", a 10% unsecured note, a convertible note. Each belongs to exactly one company and carries a fixed currency that cannot be changed later, because every amount calculation stands on it.
When the fund buys, the amount is recorded in the instrument's currency and converted to the fund's currency at the rate on the investment date — with the rate used stored, not just applied. FMV is calculated in the instrument's currency and converted at the rate on the valuation date, which is a different date and moves every time a new valuation lands.
And if no rate exists between the instrument and fund currencies on the transaction date, the transaction is rejected outright. You set the rate up first. That refusal is the feature: the alternative is a holding recorded at a rate nobody chose.
Layer two — the fund's base currency
The fund's books stay in the fund's own currency. Its LPs, its accounts, its LPA all continue to speak it. Nothing about multi-currency reporting restates the fund's actual books, and that is deliberate.
Within a fund, each investor's folio can still commit and pay in its own currency, so remittances carry folio and fund amounts side by side permanently rather than deriving one from the other at report time.
Layer three — the tracking currency
The tracking currency is a reporting lens laid over the top: a single currency in which activity is restated so a JPY fund, a EUR fund and a GBP fund can be read side by side in USD. It runs automatically for any fund whose tracking currency differs from its base, and the restated figure sits beside the original — it never replaces it.
What gets restated, and on which date, is the actual product:
| Record | Rate date used |
|---|---|
| Account entries | The reporting date |
| Remittance payments | The date the money was received |
| Capital calls | The remittance (call) date |
| Distributions | The distribution's payment date |
| Commitment adjustments | The adjustment's "as of" date |
| Capital commitments | The commitment date |
| Portfolio investment — cost | The investment date |
| Portfolio investment — FMV | The date of the latest valuation |
Take a capital call. Two amounts matter: what was called and what was actually collected. Those happened on different days, and the rate moved between them. Convert both at one date and you have manufactured a shortfall that exists only in your reporting.
⚙️ Under the hood: three rules that keep it honest
Percentages are never converted. An ownership stake or an allocation share is currency-neutral and stays exactly as it is. Obvious when stated; a classic workbook bug when an adjacent column gets multiplied by a rate.
Cost freezes, FMV refreshes. An investment's cost is fixed at its investment-date rate and never moves. Its tracking FMV is recomputed on every run against the most recent valuation and that valuation's rate. Two figures on one record, one deliberately frozen and one deliberately live — because they describe different kinds of fact.
Missing rates skip; they never guess. If a rate isn't available for a date a conversion needs, that record is skipped and administrators are alerted so the rate can be supplied. It is not interpolated from a neighbouring day, and it is not carried forward from the last known rate. Carrying yesterday's rate forward produces a complete, confident report containing a figure no market ever offered. A gap that announces itself is worth more.
When a historical rate is later corrected — as they are — an administrator forces a recalculation and the restated figures come back into line, rather than an error being preserved because it has already been reported.
Ratios that move with every capital call
This was the requirement that ruled out most alternatives. Investor allocation shares here are not static percentages set at close; they follow figures that change every time capital is called.
So they are computed, not stored by hand. During a run the engine takes each commitment's latest recorded value for the driving field as at the period end, totals them across the fund, and writes each commitment's share as a percentage entry for that reporting date. The previous run's generated percentages for the same date are removed first, so re-running a period replaces rather than accumulates.
Portfolio investments are then allocated across commitments on those shares — every investment up to the period end, or only those inside the window where a formula asks for it, and with the option to report at the investment date rather than the period end where that is the correct treatment. Proforma investments are allocated separately from actual ones, so a modelled scenario never contaminates the books.
Instruments that turn into other instruments
A stock conversion records one security becoming another — convertible notes converting to equity. It captures the instrument and lot surrendered, the quantity given up, the destination instrument, the quantity received and the date. On save, the original holding is reduced, a new holding is created in the destination instrument carrying the original cost across at the rate on the original investment date, and both aggregate views update.
A conversion is cost-preserving: it creates no gain and reduces no cost, it just moves cost. And in Gross Portfolio IRR, conversions are netted out so the converted cost isn't double-counted as a fresh investment. Stock adjustments — bonus shares, rights issues, corrections — change the share count without pretending to be a transaction.
Custom fields ride along on individual investments, so the things this fund tracks that no schema anticipated stay on the record they belong to rather than in a parallel sheet.
📊 The impact
Before: a quarterly workbook restating four funds into one currency — about five working days of assembly per close, none of the eight rate-date rules written down anywhere outside a cell formula, and two to three rate-basis queries to answer at each audit because no two reports could be shown to have used the same rule.
After: the restatement is part of the close rather than a step after it — no separate assembly day at all — with all eight rate-date rules documented, every restated figure sitting beside its base-currency original, and missing rates arriving as a named exception list (typically a handful of dates a quarter) before the report is issued rather than as an audit question after it. Investor allocations are recomputed from the ratios as they stand at each period end rather than as they stood at close.
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.
The question worth asking your own team: for the last consolidated report you produced, which date's rate was used for the capital calls — and can two people answer that the same way without opening the file?
What to take from this
- Write down your rate-date table. Eight rows. It is the highest-value hour available to a multi-currency finance team, whatever software you use.
- Called and collected are different dates. Convert them at one rate and you invent a variance that never happened.
- Never carry a rate forward to fill a gap. A visible gap gets fixed; a silently interpolated rate reports as confidently as a right one.
- Keep cost frozen and FMV live. They are different kinds of fact and should not refresh on the same cadence.
- Restate for reporting; don't convert the books. The fund's base currency belongs to the fund. A tracking currency is a lens, not a migration.
Where this goes next
The same computed entries are what investor statements are built from, and the portfolio side of it feeds portfolio reports across 50+ companies. For the longer treatment of rate dates, read converting currency is trivial; choosing the date is the whole job.
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.