The 20% in your LPA doesn’t compute anything.

Here's a sentence that has caused more than one confused support conversation, and that I've come to think is the most defensible decision in our performance engine:

The carry percentage stored against a fund's unit class does not deduct carry from any calculation. It's reference information, shown on reports.

The natural reaction is that something must be broken. Twenty percent is right there in the settings. Surely the Net IRR uses it?

It doesn't. Carry reaches performance through exactly one route: an explicit Estimated Carry line item, which is subtracted from the value still held when Net IRR is computed. No line item, no deduction — no matter what the settings say.

That's the argument I want to make: implicit multipliers are how performance numbers become undefendable.

Why an implicit rate is worse than an explicit line

Imagine carry were applied automatically wherever a rate was configured. Convenient. And then an LP asks the question every LP eventually asks:

"Walk me through how you got to that net number."

With an implicit multiplier, the honest answer is "the system applied the rate." Which invites the immediate follow-up — applied to what, exactly? — and now you're reconstructing, from the outside, a calculation that happened inside a black box, months ago, under settings that may since have changed.

With an explicit line item there's a record: an amount, on a date, produced by a named formula, sitting in the ledger where anyone can open it.

The Estimated Carry line is normally produced by a fund formula rather than typed in — derived from current fair market value, distributions to date, any hurdle, and the carry rate from unit settings. So the rate does participate. It participates through a formula that writes down its answer, instead of silently modifying a result at read time.

What actually separates Gross from Net

The mechanics are simpler than the mystique around them.

Both IRRs run off the same cash flows: capital called in, distributions out, and the value still held at the end. Net IRR differs in exactly one input — the estimated carry is subtracted from that ending value.

	Amount
Paid in by investors	40.0
Distributions to date	10.0
Value still held (FMV + cash)	62.0
Total value	72.0
Profit above paid-in	32.0
Estimated carry at 20%	6.4
Ending value for Gross IRR	62.0
Ending value for Net IRR	55.6

Illustrative figures only. Not a fund, not a return, not a projection.

One subtraction. That's the entire difference between the number you show in a pitch and the number an LP actually experiences.

And note what didn't happen: no carry was deducted from any distribution. The distributions are what they are. Carry is a claim on future profit, estimated at a point in time for the purpose of stating a net return — not a cash movement.

⚙️ Under the hood: your economics don't fit the standard formula, and that's normal

Every performance engine ships with a standard recipe: called capital, distributions, fair market value, cash, net current assets. It's correct for the median fund and wrong for a great many real ones.

Because real funds have particulars. A fee rebate negotiated with an anchor LP. A side-pocket investment that shouldn't sit in the main calculation. An expense that genuinely should reduce the return but isn't in the standard ingredient list.

The usual industry answer is a spreadsheet: export the platform's number, adjust it by hand, publish the adjusted one. Which means the number in your investor report is not the number in your system — and reconciling them is somebody's quarterly chore.

Ratio formulas exist for this. They let a ratio fold in additional amounts you've recorded against the fund, so the metric reflects your actual economics rather than a one-size-fits-all recipe. The adjustment lives in the system, is applied consistently, and produces the same answer for everyone who asks.

That's the point. Not that the calculation is customisable — that the customisation is inside the system rather than in a workbook on someone's laptop.

Then make it repeatable

The second half of the problem is nobody's favourite topic: re-running.

Performance isn't computed once. It's computed at quarter-end, then again after a late valuation lands, then again for the annual report, then again for an LP who wants the number as at a date nobody else asked for. Each re-run means reassembling the same filters — funds, date, scope — and each reassembly is a chance to do it slightly differently.

Ratio run templates save the parameter set once and re-run it for any date in a click. Individually, all at once, or grouped by tag. Same inputs, different date, no reconstruction.

	Export-and-adjust	Configured in the system
Where fund-specific economics live	A workbook	A ratio formula
Who can reproduce the number	The person with the workbook	Anyone with access
Re-running for a new date	Rebuild the filters	Re-run a saved template
What carry does	Applied by hand, or implied	An explicit line item in the ledger
Answer to "walk me through this"	Reconstruction	Open the line item

One more thing that confuses LPs — and shouldn't

Metrics exist at two levels: the fund's, and each investor's.

They differ. Routinely and legitimately. An investor's DPI or XIRR isn't the fund's, because that investor joined at a different time and was called and distributed on a different schedule. Two LPs in the same fund can hold different XIRRs without anything being wrong.

Some metrics — MOIC, Gross Portfolio IRR — only exist at the fund level, because they describe the portfolio rather than any one investor's experience of it.

Being able to state this clearly, with both numbers visible, ends a conversation that otherwise recurs every reporting cycle.

📊 The impact

Before: a standard calculation that doesn't quite fit the fund, adjusted in a workbook, re-derived by hand whenever someone asks how carry was applied — with the report number and the system number quietly diverging.

After: carry enters through one explicit, inspectable line item; fund-specific economics live in ratio formulas inside the system; and any date's numbers are reproduced by re-running a saved template rather than rebuilding filters.

The measurable thing isn't speed. It's this: how long does it take you to answer "walk me through this net number" — and does the answer depend on one person being available?

What to take from this

See it on your own structure

The test I'd run: take your last reported Net IRR and try to trace the carry deduction to a specific, dated amount in your system. Not to a percentage in a settings screen — to an amount.

If the trail runs into a spreadsheet, DM me and I'll show you what it looks like when it doesn't.