The engagement
A venture capital fund with over 100 LPs, asking for five things: automate the computations, include the specified fees, generate customised notices, monitor payments, and remind investors who haven't paid.
Every fund asks for those five. The interesting part is the order they break in.
Where drawdowns actually go wrong
Not in the arithmetic. Twelve per cent of a commitment is not a hard sum. It goes wrong in the gap between the workbook that computed the amounts and the letters that went out — because the workbook keeps being edited after the letters are sent.
Someone spots a fee that should have applied to only two closes. Someone corrects a commitment that was adjusted mid-quarter. The master file now says something different from the notice sitting in an investor's inbox, and there is no moment in the process that says which one is authoritative.
A capital call notice is a legal instruction to move money. The moment it is sent, the figures inside it stop being a draft — whether or not your process agrees.
Step one — computation, by the basis the fund actually uses
A call is created against the fund with a name, a call date, a due date and a basis. There are three bases, and they exist because funds genuinely differ:
- Percentage of commitment — one percentage, applied to every investor's committed amount. An investor who committed $4,000,000 called at 25% owes $1,000,000 before fees.
- Investable capital percentage — you set one total to be called for the fund, and each investor's share comes from their most recent stored ratio on or before the due date. This is the basis you need when excused or defaulting investors change everyone else's share.
- Upload — amounts decided elsewhere, taken from a file exactly as given. No computation, no argument.
Closes are first-class. Select which closes a call applies to, and give each its own percentage — First Close at 25%, Second Close at 10%, Third Close excluded — which is how a true-up actually works. Only investors in the selected closes get a remittance.
Step two — fees that can be traced back to their components
Fees attach to the call and are worked out per investor. They come in three behaviours: fees part of capital, which are added into the call amount and count toward called capital; other fees, which sit alongside as a separate line; and an investment amount earmarked within the call.
The standard mechanism links a fee to a named charge already recorded against each investor: give the fee a name and a date window, and every matching charge inside that window is summed. That is how recurring management fees and one-off upfront fees land without anyone retyping them.
And for every investor, the full breakdown is kept — the name, date and amount of each charge that made up the fee. When an LP queries a management fee, the answer is a list, not a recalculation.
Step three — one remittance per investor, generated not typed
Saving the call creates one remittance per eligible investor: their slice of this call. Generation is idempotent — running it again never produces duplicates — and re-runs itself automatically if you change the percentage or the total.
Every remittance carries two currencies, permanently. The folio currency is what the investor actually wires. The fund currency is what fund-level totals are built from, converted at the rate on the remittance date. Neither is derived on demand from the other at report time, which is precisely why called and collected can be compared without a footnote.
Step four — notices, approved one at a time
Notices are generated from the fund's Call Template — one per investor, in the background, or one at a time from a single remittance. Where a fund is set to notice per KYC, an investor with several folios gets one combined letter rather than four.
Then the part people try to skip: every notice must be individually approved. Open it, read it, approve it. Only approved notices are attached to the investor email, and any unapproved notice blocks the call's approval outright.
That is a deliberate friction. It guarantees a person has read each letter before it reaches an investor, and it is the reason approval can safely be irreversible.
Step five — a checklist runs before you send
The Call Notice Agent runs against one specific call and walks a fixed sequence, each step gating the next:
- Every investor on the call has a KYC record, and it is verified. If not, the checklist stops here — nothing later even runs.
- The fund has at least one Call Notice template, and notices have actually been generated for each investor in scope.
- All generated notices have been approved.
- An active email notification is configured for this call.
- A final confirmation that every gate has cleared.
No AI, no configuration, nothing to skip — every check is a yes/no comparison against records you already have. It answers one question: is this call safe to send? Its warning banner also lists every fund with no Call Notice template uploaded, so that gap surfaces before a send rather than during one.
Step six — approval locks the call
Approving sends the notices with their approved documents attached, makes the call visible in the investor portal, records who approved it — and disables edit, delete, fee refresh and document generation.
That lock is the whole answer to the workbook problem. After approval, the numbers investors hold and the numbers the system holds cannot diverge, because there is no longer a mechanism by which they could.
| Before approval | After approval |
|---|---|
| Edit amounts, dates, investor list | Locked |
| Refresh fees | Disabled |
| Generate documents | Disabled |
| Notices not yet sent | Sent, with the approved document attached |
| Not visible to investors | Visible in the portal |
| — | Fund unit allocation still available |
⚙️ Under the hood: monitoring, which is where the time really goes
Payments are records, not edits. Money in is entered as a payment against a remittance — amount in the investor's currency, payment date, a bank reference that must be unique within the fund, and an attached proof. Conversion to fund currency uses the rate on the payment date. The collected amount and payment date update themselves; nothing is recalculated by hand.
An investor paying in instalments simply has several payments. And a payment cannot be deleted once fund units have been allocated against it — you unwind the allocation first, deliberately.
Verification is a toggle with consequences. Verifying refreshes the fees, recalculates the call amount, sets the status, updates the payment date and — if enabled — emails the investor a payment-received confirmation. Add a payment to an already-verified remittance and it un-verifies itself, so somebody looks at the new total before re-confirming. That single behaviour catches the partial-payment errors that otherwise surface at audit.
Overdue maintains itself. A daily job flips unpaid pending remittances to Overdue once the due date passes. The overdue list is therefore always current without anyone producing it, which is what makes chasing a routine rather than a project. Paid allows a small rounding tolerance so a two-cent FX difference doesn't hold a remittance open; overpayment gets its own status rather than being quietly netted.
Arrears carry. An unpaid balance from an earlier call is tracked on the remittance as an arrear amount, so the investor's true position travels with them from call to call instead of living in a side list.
Collection efficiency is not a reporting problem. It is a consequence of whether your overdue list is produced automatically or produced by a person who is busy.
📊 The impact
The five verbs, answered: computation follows the basis the fund actually uses, including different rates per close; fees come from recorded charges with a traceable breakdown; notices are generated from a template and approved individually; payments post against remittances with proof, in both currencies; and overdue status is maintained daily rather than assembled.
What changed operationally is smaller and more important than any of those. There is exactly one set of figures. It becomes authoritative at a specific moment — approval — and after that moment the platform will not let it move.
What to take from this
- Pick your basis explicitly. "Percentage of commitment" and "share of investable capital" diverge the moment someone is excused. Most workbooks never state which they use.
- Approve notices one by one. It feels slow at ten investors and it is the only reason approval at a hundred is safe.
- Lock after send. If your figures can still be edited after investors have them, you do not have a record — you have a draft with a distribution list.
- Keep folio and fund currency side by side. Converting at report time is how called and collected stop reconciling.
- Automate the overdue flip. A list that maintains itself gets acted on. A list someone has to build gets built late.
Where this goes next
Drawdowns depend on verified investor records — see onboarding 200+ LPs — and feed straight into investor statements. To walk a real call end to end, book a walkthrough.
Client name withheld. The workflow, platform mechanics and behaviour described are exactly as CapHive runs them; supporting detail is illustrative of how engagements of this shape run.