Planned Giving and Bequest Administration Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a planned giving build turn into a rebuild of the calculation engine?

The project that gets approved is an administration project. Agreements are held properly, payment runs are generated rather than typed, deaths are caught, state filings have a work queue, and estate cases stop going quiet.

Then somebody asks why the system cannot also produce the deduction calculation and the illustration for a prospective donor, since the contract data is right there. It is a reasonable question and it is the single most common way these builds go wrong. Actuarial calculation for charitable gift annuities and charitable remainder arrangements is genuinely specialist work, it is where the regulatory and tax exposure sits, and PG Calc and Crescendo exist because getting it right is hard and getting it slightly wrong is expensive.

A team that starts rebuilding calculation loses months to a problem that was already solved, and ends up with a competing calculator that your gift planning officers will not trust against the one they have used for years.

The discipline is to draw the line at the point of gift. Illustration and deduction calculation stay with your existing engine, and you integrate with it. Everything after the contract is signed, the forty year obligation, belongs in the build. In Digital Heroes delivery experience the first release covering structured agreement records, generated payment runs with approval and variance review, annuitant verification cycles, reserve calculation inputs by state cohort and a bequest and estate pipeline runs $70,000 to $150,000 in 12 to 18 weeks. The full platform, adding trust accounting for charitable remainder arrangements, tax reporting file preparation, per state filing schedules and audit liability reporting, runs $180,000 to $420,000 phased over 7 to 12 months. Keeping calculation out removes the highest risk engineering in the project.

What goes wrong digitising decades of paper gift annuity contracts?

The migration here is unlike any other, because a meaningful share of your source data is paper, and the paper is old.

Three specific problems. The first is ambiguity in the terms. Older agreements were drafted before your current templates existed, and some contain language about survivorship, deferral start dates or payment frequency that a modern system has no field for. A build that cannot represent an unusual legacy agreement pushes it straight back into a spreadsheet, which recreates the exact risk you were removing.

The second is incompleteness. Files are missing, signature pages are absent, and in some institutions the only record of a contract's terms is a schedule in a workbook maintained by someone who has retired. Deciding what to do about a contract you are honouring but cannot fully evidence is a governance decision, not a data decision, and it needs your general counsel rather than your developer.

The third is drift. The workbook has been maintained by three people over fifteen years and contains at least one manual override nobody can explain. Reconciling the workbook against the paper is where the real work is, and it is work only your administrator can do.

What makes this survivable is sequencing. Start the contract review before development begins, not alongside it. Document extraction genuinely helps, pulling dates, names, amounts and frequencies off scanned agreements into structured records for an administrator to confirm rather than transcribe, but it is assistance rather than a substitute for the review. And build a deliberate escape hatch for the handful of genuinely unusual agreements, a structured way to record non standard terms with a required explanation, so they stay inside the system rather than outside it.

Why do the calculation engine, accounting and payment file integrations break after launch?

The integrations in this category fail on a quarterly rhythm, which means a break can sit undiscovered for three months.

The payment file is the one that matters most. Whatever format your treasury or bank accepts, the file is generated, transmitted and either accepted or partially rejected. Partial rejection is the dangerous case: most payments go, a handful fail on a stale account detail, and if the rejection report is not read back into the system those annuitants simply do not get paid and nobody knows until one of them telephones. Every run needs a reconciliation step that matches what was sent against what was accepted, with unmatched items raised as work rather than logged.

Accounting integration breaks at the chart of accounts. A fund is renamed, an account is restructured after an audit recommendation, and postings that ran cleanly for a year start landing in the wrong place or failing outright. Fee lines and payment postings should carry their account and fund explicitly, and a nightly or monthly reconciliation should compare totals rather than trusting the transfer.

The calculation engine integration breaks on assumptions. Rate tables and mortality assumptions get updated, and if the version used for a given calculation is not recorded alongside the result, you cannot later explain why two similar contracts priced differently. Record the engine version and the assumption set with every stored result.

What happens when state registration and reserve reporting are not covered?

Several states regulate charitable gift annuities directly, and the requirements can include registration or a permit before you issue to a resident, segregated reserve funds, specified reserve valuation assumptions and annual filings. New York, California, New Jersey and Washington are among the states with their own regimes and the details differ meaningfully between them. Confirm your current obligations with counsel and with each state, because these rules are revised and no summary substitutes for the statute.

The system consequence is a field that looks trivial and is not: the annuitant's state of residence at issue. If that is not captured at the point of gift, and captured as of that date rather than as a current address that gets overwritten when someone moves, your cohorts are wrong and every reserve calculation built on them is wrong. This is the single most common structural gap we find in institutions that grew a programme faster than their record keeping.

The second consequence is that the filing calendar has to be a work queue rather than a note in a diary. Each state, each due date, each supporting schedule, each owner, with the underlying figures generated rather than assembled by hand the week before.

Your actuary still owns the assumptions and should. The build's job is to make certain the contract data feeding them is complete, current and correctly cohorted, which is exactly what fails when it lives in a workbook.

Should you build custom or keep the calculation engine and a disciplined administrator?

For a large number of institutions the right answer is do not build, and we say so regularly.

If you hold fewer than roughly 60 active agreements, issue in one or two states and have a competent administrator working a documented process, PG Calc or Crescendo for the calculations plus a well maintained workbook genuinely works. The money belongs in donor facing effort. FreeWill and Stelter remain sensible regardless of what you run for administration, because they solve a different problem at the top of the funnel and neither is trying to be a ledger.

The honest middle case is that many programmes have a good calculation engine and a bad process rather than bad software. If your payment run fails because nobody defined who checks the variance report, custom software will encode that gap at higher speed. Fix the process first and see what is left.

Where those tools genuinely run out is that none of them is a ledger that pays a named person every quarter for thirty years, tracks their death, holds a reserve calculation a state regulator will read, and follows an estate through probate for four years. That is not a limitation anyone should hold against them, because they were never built for it.

Our position, stated plainly: the reason to build in this category is continuity, not efficiency. A gift annuity is a promise to pay a living person for the rest of their life, and honouring it should not depend on the continued employment of the one administrator who knows which rows carry manual overrides. That is a governance argument, and in our experience it is the one that persuades boards.

How do hidden costs get into the quote?

Five things drive the number in this category and the first is usually the only one discussed.

The number of states you are registered in, because each regime is separate analysis rather than a configuration row. Charitable remainder trusts, which bring trust accounting and unitrust valuations and are materially more work than annuities. Historic data, since digitising decades of paper contracts is a real project. Investment platform integration for pooled funds. And the output formats your auditors and tax preparer require, which are institution specific and should be specified before the build rather than discovered during it.

Then the ones that never appear on a proposal. Your administrator's time, which is substantial and cannot be delegated, because only they can arbitrate an ambiguous legacy contract. Legal review of how you handle contracts you honour but cannot fully evidence. Actuarial time to confirm the assumption set the system will use. And the running cost after launch, including hosting and support, which should be a number on the page before you sign.

Ask for exclusions in writing and ask specifically whether calculation is in or out of scope, because a proposal that quietly includes rebuilding actuarial computation is both more expensive and more dangerous than one that does not.

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

Ask one question in the first meeting: what happens when a death record match comes back for an active annuitant. The correct answer is that it raises a candidate for human verification and never suspends a payment automatically. Stopping a living annuitant's income because of a name match is a far worse outcome than a quarter of overpayment, and a developer who proposes automating that decision has not thought about who is on the other end of it.

Ask how they will represent a legacy agreement whose terms do not fit the standard model. Every institution has a handful, and a system that cannot hold them will push them back into a spreadsheet within a month of go live.

The builds that work generate the payment run as a reviewable batch with a variance report against the previous run, so an address change that went to the alumni database instead of the annuity record and a missing annuitant both surface before the file reaches treasury rather than afterwards. The builds that fail generate a file and call it done.

The other marker is versioning. Changes to an agreement, an address, a payment method or a beneficiary should be recorded with dates and users, so the question of what the terms were in 2019 has an answer. That is what makes the system defensible to an auditor and to a family.

Settle ownership before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. When your obligations run four decades, a vendor dependency is not a procurement detail. It is a risk to promises you made to living people.