TL;DR. A fund's admin stack has six layers. They are a management-company general ledger, a fund ledger the firm usually does not operate, bill pay, cards and travel, an investor-facing layer and reporting. The seventh layer, deciding which entity bears each shared cost, is a spreadsheet at most firms.
What does fund administration involve?
Ask the question and most answers name a service. That is the right answer as far as it goes.
Fund administration is the outsourced service a GP buys to run a fund's middle and back office. It covers fund accounting plus investor servicing and onboarding, capital calls and distributions, the investor register and reporting package, AML and KYC checks, and support for audit, tax, and regulatory filings.
What that definition leaves out is the machinery. A fund does not run a fund administration tool the way a company runs a payroll system. It runs six of them, most of which it did not choose together, and the work of the finance team is largely the work of moving decisions between them. The service and the accounting function underneath it are two different things, which our explainer on fund administration vs fund accounting separates properly, and the products themselves are ranked in our guide to fund administration software. This page does neither. It inventories the stack.
The six layers in a fund's admin stack
Every stack we have looked at has the same shape, whatever the firm's size. What changes is which product sits at each layer and how much of the connective tissue is a person.
| Layer | What it holds | What typically runs there | What it hands to the next layer |
|---|---|---|---|
| Management-company general ledger | The firm's own books | QuickBooks at 51% of teams, NetSuite at 23%, Sage at 5% | Coded transactions and the due-from-funds balance |
| Fund ledger | Fund books, capital accounts, partnership allocations | A third-party platform, usually operated by an administrator | Trial balances, capital statements and the reporting package |
| Bill pay and accounts payable | Vendor invoices and approvals | Bill.com in 39% of stacks | An approved invoice, coded, with a payment instruction |
| Cards, travel and expense | Employee spend and receipts | Ramp in 49% of stacks, Expensify in 30%, Concur in 11% | Coded card lines with a memo attached |
| Investor-facing | Subscriptions, the register, the portal, capital notices | The administrator's portal or the platform's own | Investor-level positions and the quarterly package |
| Reporting | Standard and ad hoc answers | A spreadsheet or a request queue | Whatever somebody asked for |
Of the 80 fund finance teams we spoke with in 2026, QuickBooks and NetSuite together carry 73% of those ledgers, and every share in the table above comes from that same set.
What does each tool do and what does it hand off?
The management-company general ledger
This is the layer the firm owns outright and the one it is least likely to change. It carries payroll, rent, the firm's own vendors, and the due-from-funds balance that everything else eventually lands in. Nothing about it is fund-specific, which is exactly why it works and exactly why the entity split has to happen somewhere else before the entries arrive. For the half of the market sitting on QuickBooks, our walkthrough of fund expense allocation in QuickBooks covers how far the ledger itself gets you.
The fund ledger
Usually a third-party system, and usually operated by somebody else. That single fact shapes more of the stack than any feature, because the products here are written for the administration firm rather than for you, and our breakdown of fund administration software providers groups them by who actually licenses and operates each one. LemonEdge offers multiple ledger types "including parallel GLs (e.g. IFRS with local GAAP)" out of the box, which is what a book spanning jurisdictions needs. Relevant EquityWorks sells to administrators openly, naming multi-client operational workflows and ILPA-compliant investor reporting.
What comes back to the firm is a trial balance and a reporting package, and often it arrives through a window rather than through access. Allvue builds that window as a Client Hub, where an administrator can "Collaborate and communicate with their clients, auditors, and other third parties via direct access to shared documents, real-time reports, and much more". Several finance teams told us they keep their own books alongside whatever comes through it.
Bill pay and accounts payable
Vendor invoices arrive, someone approves them, something pays them. The layer looks simple until you notice how many payment paths come off one approval. One controller described three, running off a single allocation. Bills the administrator pays from the fund. Bills the firm pays on the fund's behalf and recovers later. Management-company bills that go out through the card platform. The tool executes the routing. Something upstream has to decide it.
Cards and T&E
The capture layer, and the one that has improved most in the last few years. It collects the receipt, applies the policy, and codes the transaction. Some products in this layer publish a split capability scoped to their own ledger. Carta's Ramp integration says that with custom rules "you control how and where expenses are allocated" including "splitting transactions between funds", inside Carta's own general ledger.
The hand-off is a coded line with a memo attached, and the quality of that memo is the quality of everything downstream. It is also the one input at this layer that no tool supplies, because the memo is written by whoever happened to make the purchase. The original vendor invoice number belongs in it too, since a downstream system that mints its own identifiers breaks the trail it was bought to protect. One finance leader watching a tool do exactly that said immediately that it would challenge the paper trail, because today the allocation carries the law firm's or agent's own number alongside the fund.
The investor-facing layer
Subscriptions, the register, capital call and distribution notices, and the portal LPs actually log into. Allvue markets its Investor Portal on "a branded look and feel, customizable dashboards and secure document sharing", which is the shape most of them take. At most firms this layer belongs to the administrator, and the general partner's involvement is reviewing the package before it goes out. Investor reporting is a deep subject and this page does not go into it.
Reporting
The layer that is least often a tool. One venture CFO asked a plain question, which law firms the firm had used across all its deals over five to ten years and what it had spent with each. It took months, because the administrator had to go into every fund and assemble it by hand. In most stacks the reporting layer is a request queue, and the connection to the administrator is email. The stack differs by segment here more than anywhere else, which our guides to the VC finance stack and the private equity tech stack work through.
The seventh layer and why it is usually a spreadsheet
Between the spend tools and the ledgers sits the decision every one of them assumes has already been made. Which fund, SPV, general partner entity or management company bears this cost, in what proportion, and on what basis. 81% of those teams still make that decision in Excel, and 92% run allocations across systems that do not pass the split between them. This page comes from a company that sells into exactly this gap, which is why the rest of the section argues why the gap is hard rather than what to buy.
The published scope of the tools above says the same thing four times over. The word allocation is absent from Allvue's fund administrator page. It appears once on LemonEdge's, attached to GP allocations inside the Algorithms feature. On Dynamo's fund administration page it means investor allocations, handled by a general ledger the page describes as purpose-built for GPs. Carta's version of it lives on the Ramp integration and stops at card transactions inside Carta's own ledger. Nobody is hiding anything. The layer is simply not what these products are for.
The honest reason is not that the tools are bad. An outsourced chief financial officer who runs this stack for several firms explained that where investor mandates override available capital, and where expenses have to follow how the underlying trades were booked, a straight formula does not reach the answer.
It feels like there's more exceptions than rules.
The cadence makes it worse rather than better, because nothing about this work is monthly. One venture finance lead described an annual state fees and dues bill of about $13,000 splitting across eight funds and across both general partner and limited partner entities, concentrated in the first half of the year, with legal costs arriving on no schedule at all and depending entirely on which stage each fund is at. Allocation runs 1 to 5 days a quarter for the teams that measure it, and it lands in the narrowest part of the close.
What does the stack have to produce at the end?
One document, and the specification for it comes from buyers rather than from vendors.
A controller described what he sends his administrator each cycle as a paper trail, and explained why it has to be a document rather than a screen. The firm generates an invoice to the fund. The fund keeps it as support. When the fund is audited, it has actual invoice support for every expense billed to it. He called it old school himself, and every tool in the stack exists to produce or consume it.
A chief financial officer at another firm specified the same artifact in a single breath. One report carrying the invoice number, the vendor, the dollars by fund, the project it was for and the general ledger line it hits, living in perpetuity. It goes to the administrator, who cuts the wires from it. It carries a documented approval from each approver and a way to mark the item paid. And it never touches her own general ledger at all.
Two details in that list decide whether any of it is usable. The dollars have to be broken out by fund and by expense account rather than arriving as a total. And the invoice number has to be the vendor's own, because a system that mints its own identifiers breaks the trail.
Can you build the allocation layer yourself?
Two firms in our research did, and both are worth taking seriously rather than dismissing.
One growth-equity firm runs its fund ledger in house and says it does not really outsource anything. Its own developers wrote an allocation application that reads current fund commitments and cost of investment out of that ledger to derive the basis, calculates the split, and exports a file in a format built specifically so the expense system could import it. From there the entries flow into the management-company ledger. Their assessment of their own tool is favorable. Stable, no failures in a year, much better than the spreadsheet it replaced. A separate large-cap buyout firm built the same architecture independently, keeping the whole chain from management-company finance through the fund team to compliance review inside the building.
Two firms is two firms, and neither is evidence that this is common. What makes the first case useful is that its own team named the two things it still does not reach. Vehicles exist that the ledger does not track, co-invest vehicles among them, and those still have to bear expense, so the basis cannot be sourced entirely from the ledger. And the hard cases are not the rules. They are the precedents. When something odd comes up the question is what the firm did last time, there is no log of that, and somebody has to remember.
What breaks between the layers?
Not the sync. The sync is usually fine. What breaks is the ordering, the document, and the reconstruction.
The ordering
That second buyout firm walked us through the sequence its tools run in, and the sequence is the point. The law firm sends the invoice as a spreadsheet rather than a PDF. The finance team takes a first pass and sends questions back. Compliance and the fund team review the entity assignment line by line. Only then does the allocation calculate, aggregating every line tagged to the same entity and splitting that sum once rather than splitting line by line. They had tried it the other way, allocating first and reviewing afterwards, and were booking reclasses constantly.
The document
At one firm a shared legal bill lands as $14,000 on one fund and $9,000 on another. The administrator's trial balance carries both. The supporting evidence is a screenshot of the allocation stapled to the original invoice, and no document ties the two halves together. That gap is why the layer above keeps producing spreadsheets.
The reconstruction
A vendor calls to say a $47,500 invoice went unpaid. It was paid, in ten transactions, from ten funds, allocated by committed capital across a $1.9B base. The largest vehicle at $500M carried $12,500 and the smallest at $25M carried $625, with $10,000, $7,500, $5,000, $3,750, $3,000, $2,250, $1,750 and $1,125 in between. Not one of those payments matches the invoice total, which is why the vendor's own records show nothing that looks like settlement. Answering the call means holding, in one place, the dollars by fund, the rule used, what the spend was for, the general ledger line it hit, and the original invoice number. Assembled after the fact, that is an afternoon. Held as a record, it is a query.
The same three failures explain the shapes buyers describe. One firm keeps a full shadow set of books because the administrator holds the fund platform. One never touches that platform and receives spreadsheets instead. One moved corporate cards to a spend platform and now allocates in two places, cards in one system and vendor bills in the other. At a buyout firm there is no direct connection between the management-company ledger and the fund accounting system at all, and nearly all of the allocation calculation happens in Excel, in a separate file per vendor. Audit fees one way, tax fees another, legal a third.
The bottom of the range is not a worse tool. It is no tool. At one venture manager the allocation is done on a calculator, not even in a spreadsheet, and the result is passed to the fund accountant.
Where does Ceviche fit?
Ceviche is the seventh layer and nothing else. It reads from the spend and accounts payable tools already sitting in the stack, applies the methodology each fund agreement sets out line by line, and hands finished entries with their rationale to whichever ledger the firm already keeps. Flybridge does that across 18+ fund entities, on a Bill.com and QuickBooks Online setup that did not change, with the entries posting straight to QuickBooks Online. It is not a fund administrator, a general ledger or a managed service, and it does not do the allocations for you, so a firm missing one of the layers above buys that layer first. See how Ceviche handles fund expense allocation.
FAQ
What is fund management software? The term usually covers the front office, meaning deal pipeline, portfolio monitoring, investor relationships and fundraising, while fund accounting software covers the books. Plenty of vendors sell both under one brand, which is where the confusion starts. Our comparison of fund management and fund accounting software separates the two and says which questions belong to each.
How do firms keep a history of special and broken-deal allocations? Very few keep one, which is why the odd cases cost the most time. The practical version is not a separate log but the reasoning held on the entry itself, beside the dollars by fund and the rule applied. If a split can be re-read two years later without asking the person who made it, the precedent is recorded. If it cannot, the firm is relying on tenure.
Can we build our own allocation tool on top of the fund ledger? Two firms with in-house development teams did, and both like what they built. Budget for the review surface rather than the arithmetic. Compliance at one of them needs every line of a several-hundred-line invoice on one screen with its entity beside it and somewhere to leave a comment, and building that is more work than the calculation underneath it.
Does an allocation tool have to write to our general ledger, or can it stop at a report? A report is a legitimate endpoint, and one chief financial officer's requirements list excluded any ledger implementation outright. What follows is the payment question. One controller asked whether the allocation can tell the payment tool how to pay each share, or whether somebody goes back and re-enters it there. A report that stops short of that leaves a manual step behind it.
Will a new tool keep the original vendor invoice number? Ask it in the demo, because the answer decides whether the audit trail survives a change of system. Test the number in the export rather than the one on screen, since a tool can display the vendor's reference and still write its own identifier into the ledger. Ask to see one finished entry and check which number actually reached it.
