Operations
Who Owns Your Distribution Waterfall
Quick Answer
Fund administration software handles the ledger, NAV and investor statements, but bespoke LP and GP economics usually stay in a workbook because the waterfall is a contract. American and European structures, preferred return, catch-up, clawback reserves, side letters and transfers are the terms that break general platforms. Treating terms as versioned data creates an allocation engine in which every number traces to a named clause.
In our experience, fund administration software is excellent at what it was built to do, which is books, NAV, capital activity, investor statements, and portals. But your waterfall is not a ledger entry. It is a contract, usually a bespoke one. That is why the distribution still runs through a workbook on your CFO’s laptop after you bought the platform, and why buying a bigger platform does not make the spreadsheet disappear.
The useful distinction is not “software versus no software.” It is ledger versus allocation engine.
| Question | Who answers it today | Where the answer lives | What happens when it is wrong |
|---|---|---|---|
| What did the fund receive and spend? | Administrator | General ledger | The period is restated |
| What is the fund worth? | Administrator and valuation policy | NAV / fund accounting | The NAV is restated |
| What does each LP get from this distribution? | Owner or CFO | Workbook | You wire the wrong amount to a real person |
| What does the GP get, and is any of it clawed back? | Owner or CFO | Workbook | You take money you may have to give back |
That third and fourth row is the article. Everything else is support.
Fund Administration, Fund Accounting, and the Thing Neither of Them Is
Fund administration is the operating layer around a fund, covering books and records, capital activity, investor reporting, portal delivery, and often coordination with tax, audit, and payments. Fund accounting is the bookkeeping and financial reporting discipline underneath it, covering transactions, balances, NAV, trial balance, and statements. In practice, the terms overlap because vendors bundle them.
Fund administration vs fund accounting is the wrong comparison if your real problem is investor economics. Fund accounting records what happened. Your waterfall determines how what happened is shared.
That third category has no clean standard name in the market. Call it the allocation engine, meaning the logic that takes cash flows plus contract terms and derives, per investor, who gets what. A good platform can post the cash movement. It may even support standard carried-interest waterfalls. But your vehicle-specific economics, side letters, exceptions, and timing rules are the part that still ends up in Excel.
The Terms That Break General-purpose Platforms
This is where the search intent turns mechanical. People do not just want “best fund administration software.” They want to know if a real waterfall calculation software package can model the terms in their documents without hand-editing the answer.
| Term | What it means in one sentence | Why a standard platform struggles | What it must model correctly |
|---|---|---|---|
| American waterfall | Carry is calculated deal by deal | Needs asset-level tracking, not only fund-level results | Realized proceeds by deal, then GP/LP split |
| European waterfall | Carry is calculated at the whole-fund level | Requires fund-level aggregation and tier sequencing | Total contributed capital, pref, catch-up, then carry |
| Preferred return | LP capital gets a preferred hurdle before carry | Accrual basis, compounding, and timing vary by document | Day-count, compounding frequency, and cash-flow timing |
| GP catch-up | GP receives a tier after LP pref is met | Catch-up sequencing differs across vehicles | Exact tier order and percentage split |
| Clawback reserve | Carry is held back for future true-up | Needs forecast and reserve logic, not just a payout rule | Reserve policy, release timing, and recalculation rules |
| Subscription line | Borrowing temporarily changes IRR timing | IRR-based hurdles can be distorted by financing timing | If the line is in or out of the hurdle calculation |
| Recycling | Distributions can be reinvested into later deals | Requires basis tracking across multiple cash cycles | Eligibility, limits, and reuse of returned capital |
| Co-invest / SPV participation | Some vehicles participate in only part of the deal set | Parallel economics are not one-size-fits-all | Which assets, which dates, which LPs, which ratios |
| Fee offsets and waivers | Management fees may be reduced by other income | Offsets often live in side documents or deal terms | Which income offsets which fee, and when |
| Side-letter overrides | One LP has negotiated terms that differ from the LPA | Standard templates assume one agreement set for all LPs | LP-specific overrides with effective dates |
| Transfers and equalization | A late buyer or partial assignee joins mid-period | Requires proration and date-specific treatment | Transfer date, accrued pref, and split-period allocations |
Those are not edge cases. They are the reason a platform that is good at fund accounting still leaves the waterfall on a spreadsheet.
The Side Letter Nobody Told the Model About
The common failure mode is simple. Side letters are negotiated separately from the LPA and stored separately from it. The accounting model gets updated against the LPA, not against a versioned side-letter registry. Then the output looks clean, the capital account statement goes out, and the negotiated LP discovers the override never made it into the run.
This is not a diligence problem. It is a data-model problem.
The fix is also simple in concept, even if it is disciplined in practice. Treat each side letter as a first-class, versioned input. Each LP row should carry a reference to the terms that override the base document, and the override should be visible in the output rather than buried in a formula. If your registry is a folder of PDFs, the model does not know what it is supposed to honor.
Defending the Number to the LP Who Asks
Here is the traceability standard that matters.
Can this number be traced to a named term, in a named document, version-effective from a date, applied to a specific set of cash flows?
If the answer is no, you do not have an allocation engine. You have a workbook with a lot of trust in it.
Excel is useful because it is flexible. It is dangerous because it is flexible. It has no meaningful version history for logic, no regression test suite, no separation between input data and calculation rules, and no durable audit trail from an investor-facing number back to the clause that created it. That matters when an LP challenges a statement, when the auditor asks how the result was produced, or when a prospective institutional investor asks for the model during diligence.
The best vendor pages already hint at this when they ask buyers to trace one investor-facing number back to source transactions. That is necessary, but not sufficient. A capital account number should trace all the way back to the document term, not just to a journal entry.
The Single-person Risk in Distribution Runs
In most owner-operated private capital firms, the most consequential calculation in the business is maintained by one person, such as the founder, the CFO, or the controller who knows where every override lives. That person is often the only one who can tell if the distribution is right.
The risk is practical, not dramatic. If that person is unavailable on distribution day, the money does not move. If they leave, the firm inherits a logic file nobody else can explain. If the auditor or a new LP asks for support, the answer depends on one brain and one workbook. And if an over-distribution goes out, unwinding it after cash has left the account is far more painful than getting the calculation right the first time.
What Changes When the Terms Are Data
This is where the real argument lives. The useful pattern is not replacing your administrator. It is turning the economics into versioned logic so the administrator can run cleanly.
We have seen the same class of problem in financial services work such as UTR8 and AllOptions, where contract terms are expressed as deterministic logic with an audit trail from output back to source. The point is not a fund admin product. The point is software that can survive scrutiny.
When the terms are data, distribution runs become reproducible, so you can:
- re-run them
- diff them
- explain them
- test them
That is the difference between a capital account statement that is merely formatted and one that is defensible.
Buy This, Keep This, Build This
Buy the ledger, NAV, fund accounting core, investor portal, document delivery, subscription onboarding, KYC/AML workflow, and treasury/payments workflow. Those are commodities at this size and worth paying for. We describe our work on regulated financial software on our fintech software development page.
Keep the administrator. This article is not an argument for insourcing fund administration. For most managers in this range, that would be the wrong move.
Build the allocation engine, including terms as versioned data, a versioned side-letter registry, deterministic calculation runs, and a regression test suite of worked examples signed off by fund counsel and the auditor. The output should feed the administrator and the portal, not compete with them.
Do not build if you have one or two vehicles, one standard waterfall shape, no side letters, and no co-invest complexity. In that case, buy the platform, keep the workbook, and write the test cases anyway. The point is not to over-engineer. The point is to know where the software boundary actually is.
Where the Waterfall Spreadsheet Ends and the Operating Model Begins
For owner-operated private capital firms, the decision is rarely if to use software. It is which part of the economics belongs in the platform, which part belongs in the administrator, and which part must remain a controlled, testable allocation engine. That is where the spreadsheet ends and the operating model begins. For related reading, see why a factoring ledger is not a risk system and RIA billing software versus reconciliation, or talk to Better Software about your own allocation engine.
Frequently Asked Questions
What Is a Distribution Waterfall?
It is the order in which cash from a fund is allocated among LPs and the GP. In our view it can include return of capital, preferred return, catch-up tiers and carried interest, and the exact sequence comes from the fund documents rather than from the accounting ledger.
What Is the Difference Between an American and a European Waterfall?
An American waterfall calculates carry deal by deal, so each realized investment can trigger a split. A European waterfall calculates carry at the whole-fund level, so LPs generally get priority until the broader hurdle is met. We note the practical difference is where the logic must live, asset-level or fund-level.
What Is the Difference Between Fund Administration and Fund Accounting?
Fund accounting records transactions, balances and NAV. Fund administration is broader and often adds investor servicing and operations around the accounting core. If the question is who calculates the waterfall, we find neither term answers it, because the missing piece is the allocation engine.
Can Fund Administration Software Calculate My Waterfall?
Usually yes for standard shapes, and often very well. We see the issue as fidelity, meaning if it can model your side letters, transfers, co-invest vehicles, pref structures, clawback reserve and other bespoke terms without manual intervention.
Should We Build Our Own Fund Administration System?
Usually no. We would buy the ledger, accounting core, portal and onboarding stack, keep the administrator, and build only the allocation layer if the economics justify it. The bounded and valuable thing to build is the waterfall engine that the administrator can consume.
About the author
Better Software Team
Product and engineering team
Better Software Team is the product and engineering team at Better Software. We build custom software for established businesses in healthcare, energy and finance.