Ask a fund CFO what keeps them up and almost none will say "the IRR calculation."
They'll say the wire.
Distributions are the one moment in fund operations where a mistake is immediate, external, and very hard to reverse. The money is gone. The LP has seen an amount that doesn't match their notice. And whatever process produced the error also produced forty-nine other payments that same afternoon.
The checklist exists. It just isn't written down.
Every fund has a release process. Ask three people on the same team to state it and you'll get three overlapping lists — accurate in outline, different in detail, and dependent on who happens to be doing it that day.
That's not sloppiness. It's what an undocumented process looks like when it lives in experienced people. It works right up until the quarter your controller is on leave, the distribution is larger than usual, and one investor's KYC lapsed three weeks ago.
So we wrote the checklist down and made it executable.
The five checks
Run against every payment on a single distribution:
1. KYC is verified. Every paying investor must have a KYC record, and it must be marked verified. Not present — verified.
2. The net payable is actually computed. The amount must exist and be non-zero. A zero payable is almost never a real instruction to pay nothing; it's almost always a calculation that didn't run.
3. Notices have been generated. First a fund-level check — does this fund even have a Distribution Template uploaded? If not, that single fact blocks the entire distribution, with the fix stated plainly. Then, per payment: does a generated notice document actually exist?
4. Notices are approved. Generated isn't approved. Anything still sitting in pending approval blocks the release.
5. Bank details are on file. Every paying investor must have a bank account number recorded on their KYC.
Only if all five pass does the distribution get marked ready to pay. Otherwise the report finalises as Blocked, naming what stopped it.
| Check | Result | Detail |
|---|---|---|
| KYC verified | ✅ Passed | 48 of 48 payments |
| Net payable computed | ✅ Passed | 48 of 48 payments |
| Notices generated | ⛔ Blocked | 3 payments have no generated notice |
| Notices approved | ⏸ Pending | not run — blocked upstream |
| Bank details on file | ⏸ Pending | not run — blocked upstream |
Status: BLOCKED — 3 payments require notice generation before release.
"We always check that" is not a control. A control is something that produces a record when it passes and stops the process when it doesn't.
⚙️ Under the hood: pending is not passed
Look at that mock report again. Checks 4 and 5 say Pending, not passed and not failed.
That's the design decision I'd most want to defend, because the alternative is so tempting.
The agent stops at the first failing check. It doesn't carry on to evaluate the rest. So when notice generation fails, the approval and bank-detail checks genuinely have not run — and the report says exactly that, instead of showing a hopeful green tick or an alarming red cross that nobody verified.
Why does this matter? Because a readiness report is read in thirty seconds by someone under time pressure who wants to release payments. If that report ever shows something as passed that wasn't actually evaluated, it has done worse than nothing: it has manufactured false confidence at the exact moment confidence should be earned.
The same principle drove a smaller feature that took a surprising amount of argument.
Each of the five checks can be turned off. Reasonable — not every fund needs every gate. But a check that has been turned off, or was never explicitly configured, produces no failure. And a silently skipped check looks exactly like a passed one.
So the agent's page carries a warning banner that names every toggle that has never been given a value, and flags the case where all checks are off — a configuration that would cheerfully mark every distribution "ready to pay" while verifying nothing at all. An explicit "No" is respected and not flagged: deciding not to check something is legitimate; not knowing whether you're checking it is not.
A check you turned off and a check that silently never ran produce the same green screen. Only one of them was a decision.
No AI anywhere near it
Worth stating plainly, because in 2026 the assumption runs the other way: this agent makes no AI calls. It works with no AI key configured at all.
Every one of the five checks is a deterministic comparison against records you already own. Is this KYC verified — yes or no. Does this amount exist and is it non-zero — yes or no.
There is no judgment to exercise here, and therefore nothing for a model to add. Introducing one would trade a guarantee for a probability, immediately before moving money. We use AI heavily elsewhere in the platform, on problems where reading and summarising are the work. This is not one of them.
And it doesn't run on a schedule
There's no Schedule tab. That's deliberate too.
A readiness check that ran nightly would tell you a distribution was ready at 3am, based on the data as it stood at 3am. Then someone edits a payment at 10am and releases at noon, reassured by a green tick that describes a state of the world that no longer exists.
So it runs when you run it — from the distribution's own page, with a live step-by-step panel showing each check completing. The check is part of the release, not a background reassurance.
| Undocumented release process | Executable pre-wire gate | |
|---|---|---|
| Where the checklist lives | In experienced people | In the system, same every time |
| Consistency when someone's away | Depends who's covering | Identical |
| Evidence it happened | None | A saved Ready/Blocked report per distribution |
| What "not checked" looks like | Same as checked | Explicitly "Pending" |
| Time to run | Varies | Seconds, on the distribution page |
📊 The impact
Before: a release process that lives in the team's heads, applied a bit differently by whoever runs it, with no artifact left behind proving it was applied at all.
After: five deterministic checks, run in seconds against every payment on the distribution, producing a saved Ready or Blocked report that names the blocker — and that never reports a check as passed when it didn't run.
The error class removed is specific and worth naming: payments released against unverified KYC, uncomputed amounts, unapproved notices, or missing bank details. Not "fewer errors" — those four, gone, or the release stops.
What to take from this
- Write your release checklist down this week. Whether or not you automate it. The exercise of getting three people to agree on the list is where most of the value is.
- Distinguish "checked" from "not checked" everywhere in your reporting. A dashboard that shows green for both is worse than one with a gap in it.
- Zero is a red flag, not a value. A zero payable, a zero fee, a zero allocation — treat each as "the calculation didn't run" until proven otherwise.
- Generated is not approved. The most common near-miss we see isn't a missing document. It's a document that exists, looks finished, and never went through approval.
- Keep AI out of the release gate. Use it to read documents, draft narrative, and summarise. Don't use it where a deterministic comparison is available and money is about to move.
See it on your own structure
If you run distributions quarterly, the useful test is to take last quarter's and ask: what evidence exists that each of these five things was true before we paid?
If the answer is "we'd have noticed", DM me — I'll show you what the recorded version looks like.
Question for fund CFOs and controllers: what's on your pre-wire checklist that isn't on my list of five? Genuinely asking — I'd like to know what we're missing, and so would everyone else reading this.