Community Foundation Fund Software: Getting Pooled Investment Returns Down to 400 Component Funds

The monthly allocation nobody outside finance understands

A community foundation with 400 component funds does not have 400 investment accounts. It has three or four pooled portfolios at a custodian, and every fund owns a slice of them. On the fifth working day of the month somebody opens a spreadsheet, pulls the custodian statement, works out the pool value, divides by units outstanding, prices the units, then pushes gains, losses, management fees and administrative fees down to every fund in proportion. Contributions and grants that happened mid month have to buy and sell units at the right price, which means the sheet needs a transaction date, not just a month.

That spreadsheet is the foundation. It sits underneath the donor statements, the spendable balance every fund advisor asks about, the annual audit, and the 990. It is usually maintained by one controller, it usually has tabs nobody else can follow, and it usually works. The problem is not that it is wrong. The problem is that it is the only copy of a calculation that determines how several hundred million dollars gets attributed, and it lives on one laptop.

The second problem is speed. Because allocation is a monthly manual event, everything downstream waits on it. A fund advisor calls in the third week asking what she can grant. The answer is last month's number adjusted by feel. A development officer wants to tell a donor what their fund earned. Same answer. Nobody is lying, but the foundation is running a real time relationship on a batch calculation, and the gap is where the awkward conversations live.

What Foundant and Blackbaud FIMS do well, and where they run out

Foundant CommunitySuite is genuinely built for this. It understands component funds, unitization and grantmaking as one system rather than three, and for a foundation with a conventional structure it is usually the right answer. Blackbaud FIMS has decades of community foundation history behind it and holds a large installed base, particularly at foundations with long legacy fund records. If your operation looks like the operation those products were designed for, buy one and stop reading.

Where they run out is structural specificity. Community foundations look similar from outside and are not similar inside. Your spending policy might be four and a half percent of a trailing twenty quarter average market value with a floor and a smoothing rule negotiated with your investment committee in 2011. Another foundation nearby uses a trailing twelve quarter average with a corridor. Packaged products support a set of common policies well and unusual ones by workaround, which in practice means a spreadsheet on the side and you are back where you started.

The same applies to fund structure. Quasi endowment that the board can invade under specific conditions. Agency funds that are legally liabilities rather than net assets under accounting standards and have to report differently. Field of interest funds with a restriction that requires a committee vote before a grant leaves. Scholarship funds with selection committees, applicant portals and multi year renewals. Donor advised funds where the advisor is a family with successor advisors named across two generations. Each of those is a different object with different rules, and a product that models them all as fund with a type code will make you enforce the differences by hand.

The third gap is the general ledger. Most foundations run a real accounting package, often Sage Intacct or a QuickBooks environment for smaller shops, and the fund system has to post to it in a way the auditor accepts. Reconciling a fund subledger to a general ledger is where implementations bog down, and it is worth asking about before anything else.

Problem one: unitization that has to be right to the cent

Unitization is not conceptually hard. It is operationally unforgiving. Units are priced from the pool value at a valuation date. Contributions buy units, grants and fees sell them, and rounding has to be handled so units outstanding always reconcile to the pool. Then somebody wires in a gift on the 12th and the custodian statement does not arrive until the 8th of the following month, so the transaction has to be priced retroactively without disturbing everything that happened after it.

What a custom build does is make the pool a proper ledger. Every unit transaction is an immutable event with a trade date, a unit count and a price, and the fund balance is derived from events rather than stored as a number somebody can overwrite. Restatement becomes a supported operation: when the custodian sends a corrected valuation, you reprice from that date forward and the system produces a variance report showing exactly which funds moved and by how much, which is what your auditor will ask for. Multiple pools with different risk profiles, funds split across pools, and funds that move between pools mid year all become normal cases instead of exceptions handled by hand.

Problem two: spending policy that is genuinely yours

Spendable balance is the number every fund advisor cares about and the number hardest to compute consistently. It depends on your averaging window, your rate, whether you apply a floor when the market drops, how you treat funds that are underwater against historic gift value, what happens for funds established mid period without a full history, and whether administrative fees come out before or after the spending calculation.

A build encodes the policy as a rule set, versioned by effective date, applied per fund class. When the investment committee changes the rate for the coming year, you add a version rather than editing history, and last year's statements still recompute the way they were issued. This is the same discipline as versioning a risk model or a pay rule: the value is not in the calculation, it is in being able to reproduce a number you published two years ago when a donor family asks about it.

Problem three: donor advised funds are a workflow, not a balance

A DAF advisor logs in, sees a spendable balance, and recommends a grant to an organisation. What has to happen next is charity verification against current exempt status, a check for prohibited benefit such as fulfilling a personal pledge or paying for a table at a gala, staff review, board or committee approval depending on amount, then payment and acknowledgement. Multiply by however many recommendations arrive in December, because they all arrive in December.

The build has to treat this as a case with states, not a form. Verification against the IRS exempt organisations data should be automatic and dated, because the answer matters as of the grant date. Approval thresholds are your policy. Payment goes out as check or ACH in a batch with the grant letter and the conditions attached. Recurring recommendations, multi year pledges from the fund, and anonymous grants where the grantee sees the foundation and not the donor all have to work. And the advisor portal has to be simple enough for an 80 year old founding donor and their 40 year old successor advisor to both use, which is a design constraint most fund systems ignore.

Cost, timeline and what drives the number

In Digital Heroes delivery experience, a first release covering component fund ledgers, unitized pool allocation and spending policy calculation runs $85,000 to $170,000 and ships in 14 to 20 weeks. The full platform with DAF grant workflow, donor and advisor portals, statement generation, scholarship administration and general ledger integration runs $200,000 to $450,000 phased over 9 to 15 months.

Price drivers specific to community foundations: the number of distinct fund types and how different their rules genuinely are. Migration, which is almost always underestimated, because legacy fund history from FIMS or a decades old system carries gift dates, historic gift value, donor intent documents and unit history that has to arrive intact and reconcile to the penny. Scholarship programs, which are effectively a second application built into the first. Investment reporting depth, if the board wants performance attribution rather than just balances. And audit readiness work, since your auditor will want to see how the subledger ties to the general ledger before they will sign anything.

What keeps it down: doing the pool and the fund ledger first, running it in parallel with the spreadsheet for two full month end cycles, and leaving the portals to phase two. The parallel run is not overhead. It is how you find the rules nobody wrote down.

When buying is the right call

Buy if you have under about 50 component funds, one investment pool, a standard spending policy and a straightforward DAF program. Buy if your finance team is two people and nobody can own a product. Foundant CommunitySuite is a good product and the total cost of ownership is far below a build.

Build when several of these are true. Your spending policy or fee schedule cannot be expressed in a packaged product without a side spreadsheet. You run multiple pools with funds moving between them. You have agency funds, supporting organisations or a separately incorporated entity whose accounting has to consolidate. You administer scholarships at volume with committees and applicant portals. Your legacy fund history is a strategic asset and every migration quote you have received made you nervous. Or you are past roughly 150 funds and month end has become a bottleneck that delays donor conversations.

How to choose a developer

Ask them to explain unitization back to you before you talk about screens. If they describe it as percentage ownership recalculated each month, they have not built one, because percentages break the moment a fund transacts mid period. The answer you want involves units, a valuation date, a price and an event log.

Ask how they would handle a retroactive custodian correction. The right answer includes a variance report and reissued statements, not a manual adjustment entry.

Ask what they have migrated. Fund accounting migrations are their own discipline and the honest developers will want to see an export from your current system before they quote. Ask specifically about how historic gift value and donor intent documentation carry across, since those are the records you cannot recreate.

Ask how the subledger posts to your general ledger and whether they have worked with your specific accounting package. Then settle ownership before kickoff: the repository, the cloud accounts and the right to hire anyone else should be yours in writing. At Digital Heroes the client owns the code from the first commit, and a foundation with a fifty year horizon should not accept anything less.