TL;DR. Evaluate integration coverage first, because a tool that misses either your ledger or your spend systems recreates the bottleneck you are buying it to remove. Then test the allocation engine on entity depth and judgment per line rather than transaction volume. The checklist below covers the engine, the audit trail, security, contract terms and exit.
Start with what you are actually buying
The criteria in circulation for this category are corporate ones. They ask about transaction volume, close complexity, and fit against a single enterprise resource planning system. A fund complex fails all three as a description of itself, and a checklist built on them picks the wrong tool competently.
Close automation software for a fund records, allocates, and posts period-end accounting entries across multiple fund entities. It applies LPA-based allocation rules to shared expenses, splitting each invoice line across funds and SPVs by the correct methodology, then writes audit-ready journal entries to the general ledger.
Ceviche sells software in this category, so run every item below against us too. The test we set ourselves was that no item should be one only we would pass, and the sections on building it yourself and on not buying at all are where you can check that. If you want vendor names rather than method, we keep a list of financial close software for funds, and the category distinction sits in financial close software and close automation.
Buyers now raise one objection before any other, which is why they should not just build this themselves with a language model. It is the right question and it reframes the purchase, because what a fund is buying here was never the allocation math.
Why is volume the wrong first question at a fund?
Volume is the right first variable for a corporate close, where difficulty scales with how many transactions have to be matched. A fund's difficulty scales with entity depth and judgment per line. An engineering lead at a large alternatives manager opened his firm's evaluation with three numbers and none was a transaction count. The engine had to model four levels of parent and child entity. One invoice line resolved to 1,800 allocation lines. The firm ran millions of allocations a year. Its complaint about the incumbent was not throughput either. The system carried a rigid definition of how things should allocate and did not track the relationships behind the allocation, which is the worse failure, because relationships change and definitions do not.
The stack numbers point the same way. Of the 80 fund finance teams we spoke with in 2026, 92% split shared costs across systems that do not talk to each other, and roughly half have a gap in the allocation audit trail.
Both ends of that chain are concentrated enough to test quickly. QuickBooks and NetSuite hold 73% of management-company general ledgers in the fund finance tech stack data, and upstream of them Ramp appears in 49% of stacks, Bill.com in 39% and Expensify in 30%. Six questions do most of the filtering.
| The question to ask | Why it is different at a fund | What a good answer sounds like |
|---|---|---|
| How many levels of parent and child entity can the engine model | Master funds, feeders, blockers and SPVs nest, and a flat entity list cannot express them | A named depth, demonstrated on your own structure |
| How many allocation lines can one invoice line produce | A single line can fan out across the whole complex | A number, and an example at your scale |
| Can one invoice line carry more than one methodology and project code | A legal bill mixes deal work, formation work and firm overhead | Yes, per line, with the basis recorded per line |
| Does it track deal ownership and entity relationships as of a date | Splits change mid-invoice when ownership changes | Relationships are dated and the engine reads the date |
| Who maintains the rules after go-live | Rule maintenance is where errors enter | Your team, with an audit log on every rule change |
| Can you get the full record out in a form you can re-perform | The record has to survive the contract | Machine-readable export, during the term, not only at exit |
The vendor checklist

Every item below is reconstructed from a question a fund buyer asked on an evaluation call, or from something that went wrong afterward. Steal from it rather than filling it in.
The best-shaped version we have seen was written by a buyer. A finance operations lead replacing a legacy allocation platform asked for five things, in her own order of priority.
- Her own data running through the system, not a generic demonstration.
- A concrete account of what the automation replaces, which in her case was a managed-services team.
- An audit trail she could hand to an examiner, and she was blunt about it, since even a small-business ledger has one.
- Correct handling of the costs the management company absorbs.
- Rule-driven entity selection, because she would not let anyone pick the relevant funds off a list by hand.
1. Integration coverage
Confirm that the tool reads from and writes to the general ledger you actually run, and to your fund platform's corporate module if that is where the management company books sit. Check whether the connection is API-based or a file load. Check that your custom fields flow both ways. Check that exports carry every column the ledger shows on screen, since one controller found the expense-report owner visible in reconciliation vanished from the export.
It is the first filter because a vendor either covers both your ends or does not. An outsourced fund accounting firm found out mid-onboarding that its client's fund platform connected on the fund side but not on the corporate accounting module, which is where the payables live. A controller on a mid-market enterprise ledger told us no provider offered a one-click sync at all.
Insist on your own ledger for the demonstration rather than the vendor's sandbox of a different one. We learned that from the wrong side, having demonstrated on a QuickBooks sandbox to a NetSuite shop, which cost us credibility on the questions they cared about most.
2. The allocation engine
The four fit questions in the table above are the engine questions, and the one to add is whether a rule can decide which entities an expense touches rather than a person selecting them from a list. One buyer on a legacy system could not put multiple project codes on one invoice, so she split each into an A, B and C invoice and pushed them through separately, by hand. The rules the engine encodes come from something written down, which is what a fund expense allocation policy is for. If the policy lives in three people's heads, no engine can hold it.
Bring your ugliest invoice to the demo rather than a clean one.
3. Audit trail and version control
Per line, check that the record shows who allocated, who approved, on what basis and when. Establish whether approved allocations are locked or editable with a trail, and whether correcting a prior quarter leaves a snapshot of the original. Ask for an audit log on the reference data too, meaning the entity list, commitments and ownership, since those drive everything downstream.
Of the teams in our research, roughly half had audit trail gaps in this layer. The gap is rarely the arithmetic. It is that nobody recorded why the denominator was what it was.
Correct a prior period in the sandbox and look at what survives the correction.
4. Portability of your own record
Establish that you can export the full record at any time during the term, in a machine-readable format you can re-perform the calculation from. One general counsel caught that her export right existed only at termination, and had been handed exports before that were technically exports and practically useless.
The sharpest version came from a CFO five weeks into a new job, and it costs nothing to ask. He wanted the allocation calculation attached to the journal entry in his own ledger as a file, not a link back to the vendor's system, because the records outlive the vendor. That separates software that documents your work from software that holds it, and our guide to audit-ready fund expense allocation sets out what the file has to contain.
Export one allocation and rebuild it in a spreadsheet.
5. Security and vendor diligence
The diligence gate at a fund is four artifacts and one conversation. Ask for a completed SOC 2 report, a penetration test result and a due-diligence questionnaire, with an executed mutual non-disclosure agreement in place before any of it moves. Ask whether the vendor keeps that package on a trust page you can read before signing, which lets you check the scope without waiting on a questionnaire. The conversation is with your chief compliance officer, and ask the vendor early what that person needs in order to sign off.
A fund's compliance reviewer does not read the cover page. They read the exceptions and ask five things.
- Who merges code, and what separation of duties exists if the engineering team is small enough that the answer is one person?
- Does a remediation the vendor asserts sit inside the audited window, or after it?
- Which subservice organizations are listed, and is any of them a language model?
- Which trust criteria are in scope, given that a report covering Security alone leaves out Processing Integrity and Confidentiality?
- How long was the observation window, and did anything happen inside it?
The third decides where your financial data goes, how long it is held and whether it trains anything, and it generates the most follow-up. Processing Integrity and Confidentiality are the criteria that matter for anything computing allocations and writing journal entries. A short window with no hires and no incidents means much of the control set was never exercised. Send all five in writing rather than asking them on a call.
6. Implementation plus flexibility and support
Ask how long a change request takes and have the vendor show you one they shipped. Establish who designs the allocation methodologies during implementation, you or them. Get the escalation path in writing for the case where a field you need does not exist.
The market here is scarred and the scars are instructive. One controller emailed his vendor asking for a field he could edit and never got a reply, so his reporting stayed wrong. The same engineering lead ended up designing the allocation methods himself after learning the product, which is the cost of a vendor who will not. One buyer ran a legacy allocation system for six to eight months before abandoning it. Our version is in how onboarding works, and read any vendor's account skeptically, ours included.
Ask for a small change during the trial and time the response.
7. Commercial terms
Get the pricing shape in writing before the number. Establish whether onboarding is included or billed separately. Ask for a term that starts and ends on December 31, which funds prefer because the software cost itself gets allocated to the funds and a calendar-year term makes that clean. Strike automatic renewal, or find out what notice applies if you cannot. Check the cap on indemnity, and check whether it carves out gross negligence, willful misconduct and fraud.
That last one is not boilerplate. A general counsel reading a proposal aloud accepted the cap immediately and stopped at the missing carve-outs, which is the order a lawyer reads it in and a finance team usually does not. Settle early, too, what is software and what is managed service, because the two are priced and renewed on different logic.
8. Exit from your incumbent
If you are replacing something, read its termination clause before you sign the replacement. One CFO read hers on a call, found either party could terminate on thirty days, and budgeted an extra month of overlap rather than cutting it fine. Ask your incumbent how you get everything out, meaning all the backup and all the support, and in what format, and request that export before you sign the replacement rather than after. Budget the overlapping months as part of the purchase.
9. Vendor viability
Ask how much of your operation will sit on this platform, and how young the company is. That is a legitimate question and it ends evaluations. One fund finance team passed before the first demo on that ground alone, saying too much of their process would sit on a new platform.
The mitigations are ordinary. Ask for two references at your entity count and treat a vendor who cannot produce one as a data point, though remember that a vendor's customers are busy, as one controller told us when the firm she was asked to reference never scheduled anything. Then a security package that survives your compliance officer's read, and contract terms that let you leave with your records. No incumbent tool in this category publishes a quantified before-and-after on close, as our fund close-time benchmark says, so any close-time claim you are shown is the vendor's own number.
How do you run the trial so it proves something?
A trial where the vendor screen-shares proves nothing, and nobody logs into an evaluation environment until a scheduled call forces them to, so book the call and let the person who will actually use the system drive while the vendor narrates. Give the vendor two or three real invoices, your allocation spreadsheet and your entity list, and expect roughly a week before a sandbox with your data exists. Time-box it to one or two weeks with one success criterion, which for allocation work means your own invoices going end to end without help.
Send your worst invoices. Six shapes cover most of what can break, and a demo built on a clean invoice tests none of them.
- A multi-line legal bill carrying matter numbers
- A bill in a foreign currency
- A bill carrying GST or VAT
- A card transaction whose memo is the only place the split is written down
- An invoice already paid upstream, which some ledgers will not let you split after the fact
- A prior-quarter allocation whose project code has to change
Make the criterion countable first. One CFO said she could not live on a promise and wrote her own acceptance test on the call, three people each pushing one invoice end to end that week, validation wrapped by Friday. The strongest version adds a reconciliation, tying the intercompany export the trial produces to a quarter the firm already closed. If it matches, you have evidence. If not, you found the gap while you can still walk away.
Who has to be in the room?
The decision is almost never one person. Across the evaluations we run, the recurring shape is a champion in finance, a second person in finance, a security review, and frequently the firm's outside accounting firm, who validates the ledger sync themselves and is the decision-maker nobody puts on the list.
Get the people who run the allocations daily into the demo, not only their manager. At one firm the individual contributors pulled the demo into ledger ingestion edge cases while the controller and the compliance officer asked entirely different questions. If only one of those four sees it, you are buying on a quarter of the information.
When should you run the evaluation?
Between reporting deadlines and outside audit season. A controller at a firm with about 90 entities said the team has bandwidth for one change a year, because January through April is audit season and everything else stops. Quarter-close weeks are equally dead, and our month-end close checklist maps which weeks those are for your structure.
If you are mid-migration to a new ledger, decide whether to implement inside the migration's test window or wait until after go-live. Both are defensible. Drifting into it is not.
Should you build this instead?
Sometimes yes, and any vendor who tells you otherwise is selling. A finance associate at a venture firm built his own allocation originator. He sends himself an email with a hashtagged instruction, lets an assistant pick it up, and describes the time it takes now as almost none at all.
What a home-built tool usually lacks is the audit-grade record, the read-and-write integrations into the ledger and expense systems, and somebody to maintain both after the builder leaves. Basic function is quick. Audit grade is most of the work, and maintenance is a permanent cost carried by someone whose job is not maintenance. With genuine engineering capacity, building it can be the best case. Without one, you are buying maintenance rather than math. Either way the policy matrix built from the fund documents still needs the CFO, the compliance officer and counsel in the room.
When should you not buy at all?
We ran a full evaluation at a firm that said no, and its reasons are the ones a buying guide should teach. The spreadsheet process genuinely worked and the controller said so early. The card platform's split feature already covered most of the volume. The real pain was one recurring quarterly allocation rather than the whole workflow. And the feature the compliance officer liked most was, in his own words, a nice to have.
That firm should not buy anything. Fix the one calculation and revisit when the entity or methodology count grows. Buy when the split is judgment-heavy across many entities, when the audit trail is reconstructed after the fact, and when the work gates your close rather than annoying you.
Where does Ceviche fit?
Ceviche is software a controller runs, and it does not pass every item above. It sits between the spend and payables systems you already have and your general ledger, applies the methodology each partnership agreement specifies per invoice line, and writes audit-ready journal entries back with the basis attached. It is not a fund administrator, a general ledger or a managed service, and it does not do the allocations for you. Our diligence package is a completed SOC 2 report, a penetration test result and a due-diligence questionnaire, sent once a mutual non-disclosure agreement is in place, which is what this page told you to ask every vendor for. Flybridge runs it across 18+ fund entities, and its accounting team runs it themselves. See what it does and does not do.
Frequently asked questions
Why not build this ourselves with AI instead of buying it? Decide it on capacity rather than on the prototype. The honest test is whether a named engineer owns this after the person who built it changes teams, whether the integrations are on someone's roadmap when your ledger ships a breaking change, and whether anyone will still be answering an auditor's questions about it in year three. If all three have names, build. If none does, buy.
Is pricing per seat, per entity, or platform-based? All three exist in this category and almost nobody publishes a number, so ask early and get the shape in writing. Push for something tied to entity count or transaction volume rather than a quote scaled to assets under management, since the first two track the work. A seat-based model gets expensive the moment you add the reviewers this page told you to put in the room.
Which AI or subprocessors see our invoice data, and what is retained? Assume the answer arrives incomplete and plan the follow-up. If a language model provider appears on the subservice list, you need the endpoint, the retention period, whether zero data retention is switched on, and written confirmation that nothing trains on your data. If the vendor cannot answer in the questionnaire, that is your answer, and your compliance officer will reach it faster than you will.
Can we export the full record at any time, in a format we can re-perform? Read the contract, not the feature list. Many agreements grant export only on termination, which is useless when you need the record mid-term, so negotiate export during the term, machine-readable, with a stated turnaround. Add a survival clause covering the period after the agreement ends, because the audit that asks for it will land after you have gone.
What happens to a prior quarter's record when we correct it? Post a correction to a closed period in the sandbox, then go looking for the original allocation, the reason for the change, the approver and the date. If the earlier version is gone, the tool keeps a current state rather than a history, and that only becomes visible when an examiner asks. Check the reference data the same way, since a changed commitment silently restates every split behind it.
What happens when an allocation has to be reversed after the bill is already paid? Ask to see it done, because ledgers differ and some will not accept a negative bill at all. The workable pattern is a separate reversing entry routed through the normal approval flow rather than an edit to the original, which keeps the paid bill as it was paid and leaves both the error and the correction visible.