Operations
Your Fund Administrator Does Not Own Your Waterfall
By Better Software · Mon Sep 14 2026 · 10 min read
Fund administration software is excellent at what it was built to do: books, NAV, capital activity, investor statements, 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: 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: transactions, balances, NAV, trial balance, 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: 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 whether 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 | Whether 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 equalisation | 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.
Could you defend this 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 most owner-operated private capital firms, the most consequential calculation in the business is maintained by one person: the founder, the CFO, or the controller who knows where every override lives. That person is often the only one who can tell whether 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 better software argument actually lives. The useful pattern is not replacing your administrator. It is turning the economics into versioned logic so the administrator can run cleanly.
At Better, the relevant experience is in ledger-and-allocation-grade systems where the number must be defensible and traceable, not merely displayed. In financial services work like UTR8 and AllOptions, the same class of problem shows up repeatedly: contract terms 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. 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. If you want a public price anchor, FundCount publishes Fund Administration from 24,449 USD/year and Fund Admin Incubator from 5,000 USD per fund per year, up to 5 funds and 50M USD AUA per fund. That is one vendor’s list price, not a market rate, but it is useful as a sanity check.
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: 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.
FAQ
What is meant by fund administration?
Fund administration is the operating and reporting layer around a fund: books and records, capital activity, investor statements, portal delivery, coordination with tax and audit, and often payments support. It is not the same thing as defining investor economics. That distinction matters when you are evaluating fund administration software.
What is the difference between fund administration and fund accounting?
Fund accounting is the bookkeeping and reporting discipline that records transactions, balances, and NAV. Fund administration is broader and often includes investor servicing and operations around the accounting core. If your question is who calculates the waterfall, neither term fully answers it; the missing piece is the allocation engine.
What is a distribution waterfall?
A distribution waterfall is the order in which cash from a fund is allocated among LPs and the GP. It can include return of capital, preferred return, catch-up tiers, and carried interest. The exact sequence comes from the fund documents, not 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 distribution split. A European waterfall calculates carry at the whole-fund level, so LPs generally receive priority until the broader hurdle is met. The practical difference is where the logic must live: asset-level or fund-level.
How is preferred return calculated?
Preferred return depends on the document terms: the rate, the compounding basis, the day-count convention, and when cash flows are treated as contributed or distributed. That is why “waterfall calculation in fund accounting” often becomes Excel. The platform may hold the numbers, but the terms drive the math.
What is a capital call, and what happens if an LP misses one?
A capital call is a request for an LP to fund its share of investments, fees, or expenses. If an LP misses one, the partnership agreement usually sets out remedies such as default interest, dilution, forfeiture, or forced sale. The exact consequences are document-specific and should be checked with fund counsel.
Can fund administration software calculate my waterfall?
Usually yes for standard shapes, and often very well. The issue is not whether the software can calculate a common carried interest waterfall. The issue is whether it can faithfully 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. Buy the ledger, accounting core, portal, and onboarding stack; keep the administrator; build only the allocation layer if your economics justify it. For most firms, the bounded and valuable thing to build is not fund administration software as a whole, but the waterfall engine that your administrator can consume.
How much does fund administration software cost?
Pricing varies by vehicle count, AUA, complexity, and services bundled into the contract, which is why “fund administration fees” are often discussed as a package rather than a clean software-only price. One public anchor from FundCount is 24,449 USD/year for Fund Administration and 5,000 USD per fund per year for Fund Admin Incubator, up to 5 funds and 50M USD AUA per fund. Treat that as a vendor list price, not a universal benchmark.
For owner-operated private capital firms, the decision is rarely whether 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.