Community Foundation Fund Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does putting the donor and advisor portals in release one go wrong so often?

Because the portal is the visible part and the ledger is the load bearing part. Boards fund projects on what they can see, so the specification opens with donor logins, fund dashboards, grant recommendation forms and statement downloads, and the unitized pool sits somewhere in the middle of the backlog.

What happens next is that the portal gets built against a balance nobody can defend. An advisor logs in, sees a spendable figure, and calls the controller because it does not match the statement she received. The controller checks the spreadsheet, which is still the real system, and explains that the portal number is approximate. Confidence in the project ends there, and it ends with your most engaged donors rather than internally.

Sequence it the other way. Ship component fund ledgers, the unitized pool with monthly allocation, and spending policy calculation first, which is $85,000 to $170,000 over 14 to 20 weeks. Run it in parallel with the spreadsheet for two full month end cycles before anybody outside finance sees a number. Portals belong in phase two, and they are much easier to build once the balance behind them is derived from an event log rather than assembled. Foundations that do this also find the portal specification shrinks, because half of it was compensating for numbers nobody trusted.

What goes wrong when you migrate legacy fund history?

Balances and transaction history export reasonably well from Blackbaud FIMS or a decades old internal system. The records that matter most in a dispute do not. Original gift instruments, historic gift value, restriction language and correspondence about donor intent are often attachments, scanned documents or free text notes, and they are the records you cannot recreate if they are lost or mismapped.

There is a second, quieter problem. Unit history may not exist in reconstructable form, because the legacy system stored a balance per fund per month rather than unit transactions with trade dates. Loading those balances into an event based model produces funds whose units do not tie to the pool, and the difference has to go somewhere. Teams discover this in week three of migration and it is usually the single largest schedule risk on the project.

Two fixes. Insist any developer works from a real export of your data before they quote the migration, rather than quoting a category. And decide deliberately how far back unit level reconstruction goes: a cut over date with opening unit positions derived from the last reconciled valuation, full document migration for gift instruments and restriction language, and summarised history before that with the legacy records retained and linked. A history that reconciles from a defensible starting point is worth more than one that claims to go back thirty years and does not tie.

Why do custodian and general ledger integrations break after launch?

The custodian feed breaks on timing rather than format. Statements arrive after month end, corrections arrive later still, and a system that assumes valuations are final will happily price units on a figure that changes a fortnight later. Nothing errors. The allocation simply becomes wrong, and it stays wrong until somebody notices a discrepancy in a statement.

The general ledger breaks on reconciliation. Your fund system is a subledger and it has to post summarised entries into Sage Intacct or your QuickBooks environment in a way your auditor will test. What usually goes wrong is not the posting, it is the tie: fees are recognised in one place and allocated in another, or a mid month unit transaction posts to a period the accounting package has already closed. The result is a subledger that is internally correct and externally unreconciled, which is the version an auditor finds.

The fixes are structural. Treat every valuation as provisional until confirmed, support repricing from an effective date forward, and produce a variance report showing which funds moved and by how much whenever a correction lands. That report is what your auditor will ask for and what you use to decide whether reissued statements are warranted. On the ledger side, agree the posting model and the tie report with your auditor before it is built, and run the tie every month rather than at year end, because a twelve month drift is very expensive to unpick.

What happens when spending policy versions are not covered?

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

If that policy is held as configuration values, you have one version and you need several. The investment committee changes the rate for the coming year, somebody updates the field, and last year's statements no longer recompute the way they were issued. A donor family asks about a figure from two years ago and the system produces a different one. Nobody did anything wrong and the foundation now looks careless about its own numbers.

Encode the policy as a versioned rule set with effective dates, applied per fund class. A committee change becomes a new version rather than an edit, and any historical statement reproduces exactly as issued. The same discipline applies to your administrative fee schedule, which changes more often than most foundations expect. The value is not in the calculation, which is arithmetic. It is in being able to reproduce a published number years later without argument.

Should you build custom or configure what you already own?

Under about 50 component funds with one investment pool, a standard spending policy and a straightforward donor advised fund programme, configure. Foundant CommunitySuite was designed for exactly this operation and understands funds, unitization and grantmaking as one system rather than three, and total cost of ownership sits far below a build. If your finance team is two people and nobody can own a product, that settles it.

The honest test after implementation is simple and uncomfortable: does your controller still maintain a parallel workbook. If she does, the packaged tool is not holding something your operation genuinely requires, and the workbook is where the risk lives. That is the signal to look further, not the fund count.

Build when several conditions cluster. Your spending policy or fee schedule cannot be expressed without a side spreadsheet. You run multiple pools with funds moving between them. You hold agency funds, supporting organisations or a separately incorporated entity whose accounting must consolidate. You administer scholarships at volume with committees and applicant portals, which is effectively a second application. Or you are past roughly 150 funds and month end has become a bottleneck that delays donor conversations.

How do hidden costs get into the quote?

Five items drive the overrun. Migration, which is the most commonly underestimated line in this category and should be quoted separately after the developer has seen a real export. The number of genuinely distinct fund types, since quasi endowment, agency funds that report as liabilities, field of interest funds requiring a committee vote and scholarship funds are different objects rather than a type code. Scholarship administration, which is an application intake, committee review and multi year renewal system in its own right. Investment reporting depth, if the board wants performance attribution rather than balances. And audit readiness work, because your auditor will want to see how the subledger ties before signing anything.

Make them visible by asking for migration as its own line with a named reconciliation period, scholarships as their own phase, and the general ledger tie report as a named deliverable with your auditor's sign off attached. Then ask what the parallel run looks like: two full month end cycles is the right answer, and it is your controller's time rather than developer time, which is why it never appears in a quote unless you ask.

What separates a build that works from one that fails here?

The working ones 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 anyone can overwrite. Restatement is a supported operation rather than an emergency, so a corrected custodian valuation reprices from its effective date forward and produces a variance report. Multiple pools, funds split across pools and funds moving between pools mid year are normal cases rather than exceptions handled by hand.

The failing ones share one shape. Percentages. If a developer describes unitization as percentage ownership recalculated each month, they have not built one, because percentages break the moment a fund transacts mid period and the breakage is silent. The second shape is a spending policy stored as a rate field, which guarantees you cannot reproduce a statement you have already sent.

The test before signing is to ask the developer to explain unitization back to you before you talk about screens, then ask how they would handle a retroactive custodian correction. The right answer involves units, a valuation date, a price, an event log, a reprice from an effective date and a variance report. If it involves a manual adjusting entry, the audit trail is being broken to save an afternoon, and you will pay for that afternoon repeatedly.