A private equity distribution notice reports one GP's allocation of a payout across a fund's waterfall tiers, return of capital, preferred return, GP catch-up, and residual carry. It is a bilateral figure by design: the LP is the party best positioned to check the arithmetic before it relies on the reported number. ILPA's own reporting-template guidance says its templates were not built to check the GP's own math. In practice, most LPs either take the notice on faith or rebuild the tier math by hand from the capital account statement. This pack gives both sides the same one-node recompute to run, so each side reaches its own answer from its own declared inputs, and can hand the other a signed receipt that its own recomputation matched.
Written for fund-oversight staff and LP back-office operations checking a GP's reported distribution allocation against a fund's own declared cashflows and waterfall terms.
The pack has a single computational stage. What makes it a bilateral evidence pack rather than a one-sided calculator is who runs it and how the two runs are tied together: the GP runs it once to arrive at the reported allocation, the LP runs it again over the identical declared cashflows and waterfall terms to check it, and because the kernel is deterministic and the tier comparison is exact fixed-point equality with no declared tolerance, an honest recomputation reaches the identical execution hash. Either side can then countersign a receipt of its own run.
The recompute. You declare a batch of dated cashflows, each a contribution or a distribution with an amount, and a waterfall parameterization: the preferred return rate and its compounding basis, the GP catch-up percentage, the carry percentage, and whether the fund runs a European whole-fund or an American deal-by-deal tier structure. The node applies the standard four-tier waterfall, return of capital, preferred return, GP catch-up, then residual carry split, to the declared cashflows, then diffs the recomputed LP and GP amount for every tier against a declared GP-reported allocation. A run with no GP-reported allocation to diff against is reported INDETERMINATE rather than silently passed. Every amount is fixed-point BigInt money math, so a small mismatch is never a floating-point artifact.
Recomputing the same allocation twice is only useful if each side can prove, to the other or to a third party, which run it actually did. SPEC.md section 27.12 defines a small, additive record type for exactly that: a counter-signed receipt.
| Step | What happens |
|---|---|
| 1. GP recomputes | Runs recompute_pe_waterfall_lp over the distribution's declared cashflows and waterfall terms against its own reported allocation, seals the resulting artifact, and gets an execution hash. |
| 2. Declared inputs travel | The GP sends the LP the declared cashflows, the waterfall parameterization, and the sealed artifact, however the two sides already exchange the distribution notice. No relay or registry of AINumbers' sits between them. |
| 3. LP recomputes | Runs the identical node over the identical declared inputs on its own side. A correctly matching recomputation reaches the identical execution hash. |
| 4. LP countersigns | Mints a counter_signed_receipt record: subject_hash names the matched execution hash, kernel_pin names the exact kernel it verified against, role is checker, and replay_verified: true states that it actually re-ran the computation. |
| 5. Either side, or a third party, verifies offline | Recomputes the execution hash from the declared inputs, confirms it matches subject_hash, and checks the receipt's own signature. No connection to either party's systems is needed. |
The recompute names two distinct subjects and gives each its own verdict from the same three-value vocabulary. The counter-signed receipt names a third, narrower fact and carries no verdict of its own.
| The receipt proves | The receipt does NOT prove |
|---|---|
| That the declared cashflows and waterfall parameterization, run through the standard four-tier formula and diffed against the declared GP-reported figures, produce the recorded per-tier and overall verdicts. | That the declared cashflows are real, that they match the fund's actual capital account records, or that the declared waterfall parameterization is what the limited partnership agreement authorizes. A batch copied from a mistaken spreadsheet matches or diverges exactly as well as a true one. |
| That a counter-signed receipt's signer independently re-ran the identical kernel over the identical declared inputs and reached the identical execution hash. | That the LP approves the distribution, that the true-up is closed, or that a later dispute over the underlying waterfall's terms is foreclosed. |
| That a third party can replay the same arithmetic from the same declared inputs and reach the same execution hash, entirely offline, without contacting either party's systems. | That a capital call or distribution has been paid, that ILPA endorses this pack, or that any regulatory or market-practice duty has been discharged. |
Carried here as orientation, not restated as facts of our own. Confirm current guidance text with ILPA and with the fund's own LPA and counsel before relying on any of it for a live distribution.
As read on 2026-08-08: ILPA's own reporting-template guidance states its templates were "not designed for verifying any of the GP's calculations." This pack produces the LP-side check that gap leaves open, running the same arithmetic the GP already ran, over declared inputs the LP itself supplies. It does not source or verify cashflows, their dates, or their amounts from any fund administrator feed, and it makes no ILPA endorsement claim and no claim of being ILPA-compliant.
As landed 2026-08-08: SPEC.md section 27.12 adds the counter_signed_receipt record type and the checker role to the existing section 27.2 accountability-record shape, plus two optional sibling fields, kernel_pin and replay_verified. Nothing about the underlying artifact's execution hash, and nothing about any other artifact or record already in the standard, moves as a result.