TL;DR
Ceviche runs an allocation layer between your AP system and your GL. It encodes your LPA methodologies as versioned rules, AUM-based, deal-specific, and pro-rata by committed capital, then applies them automatically to every incoming invoice and writes audit-ready journal entries back to QuickBooks Online, NetSuite, or Sage. A 25-line legal invoice that produces 125 manual entries across five funds becomes a line-by-line split with a full audit trail. You keep your existing GL, chart of accounts, and close process.
The Scale Problem: Why Does Expense Allocation Break at Three Funds?
Allocation volume grows multiplicatively with entity count, not in a straight line. Every shared expense your management company incurs, including outside counsel, audit fees, deal costs, and overhead, needs a separate allocation decision for each fund it touches. Add a fund and you do not add one more decision per invoice. You add one more decision per line item per invoice.
The outside-counsel invoice shows the math plainly. A single 25-line-item legal invoice across five funds produces up to 125 allocation entries, because each line item can split differently across each entity. The same invoice across ten funds produces 250. Each entry carries its own methodology, its own percentage, and its own journal entry. Controllers at this scale report spending one to five days per quarter on allocation alone, and the error rate climbs with each fund added because the methodology lives in a spreadsheet that no two people read the same way.
The bottleneck is structural, not a question of staffing. Adding a second controller does not encode the rules. It splits the same manual lookups across two people who now disagree more often. Ceviche's 2026 research found that 96 percent of firms cite multi-entity complexity as their core allocation problem, 92 percent run disconnected upstream and downstream systems, and 81 percent still allocate in Excel. You can read the full research here.
Three funds is the threshold where the spreadsheet stops scaling. At one or two funds, a controller holds the methodology in their head and the math stays checkable. At three, the lookups compound, the exceptions multiply, and the close stretches to fill the time the manual work demands.
Definition: Fund Expense Allocation
Fund expense allocation is the process of attributing shared management-company expenses, such as outside counsel, audit fees, and overhead, to specific fund entities according to the methodologies each LPA mandates. The output is a set of journal entries the general ledger can absorb, with each entry tied to a source invoice, an allocation rule, and a percentage per entity.
Why Is a Longer Close a Systems Problem, Not a Staffing One?
A three-week close at five funds does not get shorter when you add a second controller. The work is slow because the allocation methodology lives in a spreadsheet, in someone's memory, and in the LPAs, but nowhere a machine can read. Every invoice forces a human to stop, look up the correct method for that expense type, apply it across entities by hand, and check the arithmetic. Two controllers running the same lookup twice as fast still run the same lookup.
The lookup is the friction, and it repeats per line item, not per invoice. A 25-line legal bill is 25 separate methodology decisions, because outside counsel work for Fund II deal diligence allocates differently than firm-level overhead on the same invoice. The controller carries the rule in their head, and the rule is rarely written down in a form that survives the person leaving.
Then a new fund launches, or an LP amends a side letter, and the allocation method changes. There is no mechanism to propagate that change. The controller updates the spreadsheet they remember and misses the three other tabs where the old percentage still sits. Q3 splits an audit fee one way, Q4 splits it another, and nothing in the record explains why. The methodology drifted because the methodology was never encoded, only re-typed.
That drift compounds. Each quarter introduces small inconsistencies, and they stack because no prior-period rule is locked. By the time the audit arrives, the same expense category has been allocated three slightly different ways across the year, and the controller cannot reconstruct the reasoning for any single entry. The SEC samples 20 to 50 transactions and tests whether the methodology is applied consistently. Inconsistency is exactly what drift produces.
Headcount cannot fix an absent rule engine. What the close needs is a place to encode each allocation rule once, apply it automatically to every incoming invoice, and version it so a mid-year amendment never silently rewrites last quarter. The lookup disappears when the rule, not the person, owns the methodology.
How Do Automated Allocation Rules Work?
Three allocation methodologies cover almost every shared expense a PE firm encounters, and each becomes a rule the software runs without a controller looking anything up. The methodologies are AUM-based, deal-specific, and pro-rata by committed capital. Encoding them once and versioning every change is the mechanism that ends the propagation failure described above.
AUM-based allocation
AUM-based allocation splits an expense proportionally to each fund's assets under management on a stated date. Audit fees and management-company overhead usually fall here, because no single fund caused the cost. In software, the rule references a live AUM figure per entity and computes each fund's share at the moment the invoice posts. When AUM shifts quarter to quarter, the rule pulls the current values, so the controller never re-derives percentages by hand.
Deal-specific allocation
Deal-specific allocation attributes a cost directly to the fund that sourced or owns the deal. Broken-deal expenses, deal-specific legal work, and diligence costs run this way, since one fund bears the full amount. The rule maps the expense to a deal identifier, and the deal maps to a fund entity, so a 100 percent allocation lands on the correct fund with no split math. Co-invest structures sit here too, where an SPV carries its portion alongside the lead fund.
Pro-rata by committed capital
Pro-rata by committed capital applies a fixed percentage derived from LP commitments at close. Most recurring shared costs default to this method because the LPA defines the split and it rarely moves. The rule stores each fund's committed-capital percentage and applies it to every line item tagged to that method. Most firms over-engineer allocation; a committed-capital default with documented exceptions covers the bulk of recurring spend.
Why does version control matter more than the rules?
Rule versioning is the part that keeps prior periods consistent after an amendment, and it is the half of the system competitors skip. When a new fund launches or an LPA is amended, the committed-capital percentages change for every fund going forward. The software records the change as a new rule version with an effective date, and leaves the prior version attached to every entry it already produced. Q1 entries keep the percentages that were correct in Q1, and Q3 entries use the amended ones.
Without versioning, a controller faces a choice between restating closed quarters or accepting that the spreadsheet now disagrees with itself, which is exactly how allocation drift surfaces during audit. A versioned rule answers both questions at once. The current quarter uses the current rule, and any historical entry still shows the rule that governed it when it posted.
Worked Example: One Outside-Counsel Invoice Across Four Funds
Take a single quarterly invoice from the fund's outside counsel, totaling $90,000 across 25 line items. The firm runs Fund I, Fund II, Fund III, and a co-invest SPV. No single methodology covers the whole invoice, because each block of line items relates to a different kind of work.
One outside-counsel invoice fans out across funds and SPVs, each block by its own methodology.
The first block covers general fund formation and compliance work, $30,000 across eight line items. That cost splits pro rata by committed capital. Fund I holds 40% of committed capital, Fund II holds 35%, Fund III holds 25%, and the SPV holds none. The software reads the committed-capital rule, applies the fixed percentages, and produces Fund I at $12,000, Fund II at $10,500, and Fund III at $7,500.
The second block covers diligence on a specific deal, $40,000 across twelve line items. That deal belongs to Fund III alone, so the deal-specific rule attributes the full $40,000 to Fund III. No split, no proportion. The rule routes every line item in that block to one entity.
The third block covers work on the co-invest structure itself, $20,000 across five line items. That cost is AUM-based across the funds participating in the co-invest. On the allocation date, Fund II carries $200M in relevant AUM and the SPV carries $50M, a 80/20 split. Fund II bears $16,000 and the SPV bears $4,000.
Add it up. Fund I bears $12,000, Fund II bears $26,500, Fund III bears $47,500, and the SPV bears $4,000. One invoice, three methodologies, four entities, and roughly fifteen journal-entry lines once you account for the debit and credit on each split. A controller doing this by hand looks up the methodology for each block, applies it across entities, and checks the arithmetic before posting.
The software does the same work without the lookup. It reads each line item, matches it to the encoded rule for that expense type, applies the rule version in effect on the allocation date, and writes the journal entries to the GL. The committed-capital percentages, the deal-to-fund mapping, and the AUM figures already live as rules, so the only human step is approval. Run the next invoice, and the same logic fires again. The controller never re-derives a single percentage.
What Does the Audit Trail Capture at the Journal-Entry Level?
An auditor pulls a sample and asks why Fund III bore 34% of a Q2 legal invoice. With spreadsheet allocation, answering that means tracing back through tabs, finding the percentage someone typed, and reconstructing the logic from memory. With an encoded allocation layer, the record already holds the answer, and you read it back in seconds.
Each allocation entry captures eight data points:
- Source invoice. The specific AP document the allocation came from, with its line items intact.
- Expense category. The classification that determined which rule applied (outside counsel, audit, deal costs, overhead).
- Rule applied. The methodology that ran for this line, whether AUM-based, deal-specific, or pro-rata by committed capital.
- Rule version. The exact version of the rule in effect on the allocation date, so an LPA amendment in Q3 never rewrites a Q2 entry.
- Allocation percentage per entity. The split applied to each fund, including the 34% that hit Fund III.
- Approver. The person who reviewed and signed off on the entry.
- Timestamp. When the allocation ran and when it was approved.
- GL accounts. The accounts debited and credited when the journal entry posted.
Those fields answer the auditor's question without reconstruction. The 34% on Fund III ties to a committed-capital rule, version 2, in effect for Q2, approved by a named controller on a specific date, posting to specific accounts. You do not defend the number from memory. You show the record that produced it.
The SEC tests allocation methodology against 20 to 50 sampled transactions and checks that the methodology was applied consistently. A spreadsheet cannot prove which rule ran on which date, because the formula in the cell only shows today's logic, not the logic in force last quarter. The versioned record proves consistency by construction, and that consistency is what an examiner is sampling for.
GL Write-Back: How Does the Allocation Layer Fit Your Existing Stack?
Ceviche does not replace your general ledger, and that is the point. The allocation layer sits between the AP system where invoices live and the GL where journal entries land. It reads the approved invoice, applies your encoded rules, and writes the resulting entries back into the GL you already close on.
On the upstream side, Ceviche connects to the AP and spend tools controllers actually run: Ramp, Bill.com, and Expensify. An outside-counsel invoice approved in Bill.com flows into the allocation layer with its line items intact. Ceviche splits each line across the correct fund entities and produces the journal entries.
On the downstream side, those entries write back to NetSuite, QuickBooks Online, or Sage. Ceviche posts to your existing accounts using your existing entity structure. It does not stand up a parallel ledger or ask you to reconcile two sources of truth.
Your chart of accounts stays exactly as it is. Ceviche maps allocations to the GL accounts you already use rather than imposing a new account structure. The same goes for your reporting. Whatever you run today out of NetSuite or QuickBooks keeps running, because the underlying entries arrive in the same place they always have, just allocated correctly and faster.
Your close process does not change either. The controller still reviews, the approver still approves, and the entries still post on the same cadence. What changes is the work that used to happen in a spreadsheet between invoice approval and journal entry. That manual allocation step now runs as encoded rules with a full audit trail.
That is the full scope. Ceviche is not an ERP and not a fund administrator. It is a layer that handles allocation between the two systems you already depend on.
How Flybridge Capital Unified Quarterly Allocations Across 18+ Fund Entities
Flybridge Capital runs 18+ fund entities. Before Ceviche, the controller allocated shared expenses across those entities by hand in spreadsheets. Each invoice meant a lookup, a methodology decision per fund, and a manual check of the arithmetic before anything posted.
The firm runs QuickBooks Online for the general ledger and Bill.com for accounts payable. Ceviche slotted between the two without touching either. Onboarding covered encoding the firm's LPA-based allocation rules and connecting both systems.
The controller reviews exceptions instead of rebuilding the model each quarter. Invoices flow from Bill.com, the encoded rules apply per line item, and the resulting journal entries write back to QuickBooks Online. The controller reviews and approves rather than building entries from scratch.
The number that matters for a 3-to-10-fund firm is 18. Flybridge sits well above the upper bound of this guide's audience. A 25-line-item legal invoice produces up to 450 allocation entries at 18+ entities, far more than the 125 a five-fund firm faces. If the rule engine holds at that volume and accuracy, the same logic carries a smaller structure with room to spare.
The stack also tells you something. QuickBooks Online and Bill.com are common at firms below institutional scale, not enterprise platforms. You do not need NetSuite or a six-figure accounting system for the allocation layer to work. The model runs on the tools a 3-to-10-fund controller already has, and the three-to-four-week timeline means the quarter you onboard is the quarter you stop allocating by hand.
The CFO Business Case: Hours, Audit Risk, and Implementation Cost
The case for an allocation layer comes down to three numbers a CFO already tracks: controller hours, audit risk, and implementation cost.
On hours, a controller managing five to ten funds spends one to five days per quarter on allocation work alone. Encoding the methodology as a rule removes the per-invoice lookup, the manual math, and the verification pass. That recaptures four to twenty controller days per year, time that goes back into actual close review instead of spreadsheet arithmetic.
On audit risk, the exposure is methodology inconsistency. When allocation logic lives in a spreadsheet, no two quarters apply it identically, and the drift surfaces when an auditor samples 20 to 50 transactions. A versioned rule applies the same methodology every quarter and ships an immutable record of which version ran when. That turns "why did Fund III bear 34% of this invoice" into a query, not a defense.
On cost, the allocation-layer model avoids the line item that kills most software decisions: migration. Ceviche onboards in roughly three to four weeks because it leaves your GL, chart of accounts, and close process where they are. Pricing tracks fund-structure complexity, not AUM, so a firm running eight small funds is not penalized for assets it has not deployed.
Compare that to Allvue or Entrilia. Both solve allocation by replacing the accounting stack with a full platform, which means a multi-month implementation, a chart-of-accounts rebuild, and a price that scales with assets. If your only acute problem is quarterly expense allocation, you are buying an ERP to fix a journal-entry problem. The allocation layer sits on top of the stack you already run and writes entries back into it.
Be clear on what Ceviche does not do, because an honest comparison is the credible one. Ceviche is not a fund administrator, not an ERP, and not a managed service. It does not do the allocations for you the way StavPay or an outsourced admin would. It is software your controller runs to produce audit-ready allocation entries faster, with a full trail, on the GL you already use.
Where Does Ceviche Fit?
Ceviche is an allocation layer that sits between your AP system and your general ledger. It pulls invoices from Ramp, Bill.com, or Expensify, applies your LPA-based allocation rules, and writes audit-ready journal entries back to NetSuite, QuickBooks Online, or Sage. It is built for controllers at firms running three to ten funds, where shared expenses like outside counsel and audit fees drive most of the manual close work.
Ceviche does not replace your GL, run your fund administration, or do the allocations for you. You keep your chart of accounts, your close process, and your reporting structure. The software runs the allocation math and the audit trail, faster and more consistently than a spreadsheet. To see how it handles your stack, visit ceviche.ai.
FAQ
How long does onboarding take?
Most firms onboard in about three to four weeks. The work involves mapping your chart of accounts, connecting your AP and GL systems, and encoding your allocation rules from the LPAs. There is no platform migration, so your close process keeps running during setup.
Does this replace our GL?
No. Ceviche sits between your AP system and your general ledger. It applies allocation rules and writes journal entries back to NetSuite, QuickBooks Online, or Sage. Your chart of accounts, close process, and reporting structure stay exactly as they are. The GL remains the system of record, and Ceviche feeds it audit-ready entries.
How does the software handle a methodology change mid-year?
Rule changes are versioned. When a new fund launches or an LPA is amended, you update the rule, and the new version applies from its effective date forward. Prior periods keep the version that was in effect when those entries posted. An auditor reviewing Q1 sees the Q1 rule, not the amended one, so historical allocations stay consistent.
What if different funds have different allocation rules?
That is the standard case, and the software is built for it. Each expense category can carry its own methodology, and a single invoice can split across AUM-based, deal-specific, and pro-rata rules in the same run. One outside-counsel invoice can allocate line items to Fund I by committed capital and to a co-invest SPV by deal ownership, all without a manual lookup.
Is this a managed service?
No. Ceviche is software your controller runs, not a team that does the allocations for you. You encode the rules, approve the entries, and own the close. Managed-service models like StavPay perform the work on your behalf. Ceviche keeps the allocation logic and the audit trail in your hands while removing the manual math.
