Planned Giving and Bequest Administration Software: Why Gift Annuities Outlive Your Spreadsheets

Why planned giving breaks the tools that fundraising built

The first of the quarter at a university foundation. Six hundred and ten active gift annuity contracts are due for payment. The gift planning administrator opens the workbook she inherited, filters for active, exports a payment file and sends it to treasury. Three things go wrong that nobody notices this week. An annuitant moved to assisted living in November and the address change went to the alumni database rather than the annuity record, so a paper cheque is going to an empty house. Another annuitant died in February, the family did not notify the foundation, and three quarterly payments have gone out since, which means the foundation now has to ask a grieving family to return money. A third contract is one of a handful issued to residents of a state with its own annuity registration and reserve requirements, and the annual filing for that state is due in six weeks with figures nobody has started.

The tools in this sector are good at what they are, which is not administration. PG Calc and Crescendo are calculation and illustration engines, and they are the standard for a reason: computing a charitable deduction, an annuity rate and a payout schedule correctly is genuinely specialist work and you should not reinvent it. Stelter is marketing and donor communication. FreeWill is top of funnel, generating bequest intentions at volume. None of them is a ledger that pays a 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.

So the administration lives in Excel, in a filing cabinet, and in one person's memory of which contracts are unusual. Across planned giving and foundation projects we have delivered, the recurring pattern is that the workbook has been maintained by three people over fifteen years, the formulas contain at least one manual override nobody can explain, and the institutional knowledge about the awkward contracts is held by an administrator who is within a decade of retirement. That is the actual risk here. A gift annuity obligation can run forty years. Your spreadsheet custodian will not.

Problem 1: the calculation is the easy part, the forty year obligation is not

Illustration software answers the question a donor asks at the point of gift. What is my deduction, what is my rate, what is my payment. That question is answered once. Then the obligation begins, and it is an obligation to a specific human being that survives every staffing change, system migration and reorganisation your institution goes through.

Administration means holding contract terms permanently and unambiguously: single or two life, joint and survivor treatment, immediate or deferred with a start date, payment frequency, whether payments are made by cheque or transfer, and what happens on the first death in a two life agreement. Spreadsheets hold most of that as text in a comments column, which is fine until somebody applies a filter wrong.

What a custom build does: the agreement is a structured record with typed terms, and the payment schedule is generated from those terms rather than maintained by hand. Changes to an agreement, an address, a payment method or a beneficiary are versioned with dates and users, so the question of what the terms were in 2019 has an answer. Payment runs are generated, reviewed and approved as a batch with a variance report against the previous run, which is how the empty house and the missing annuitant get caught before the file goes to treasury rather than afterwards.

Problem 2: death notification is the failure mode, and overpayment recovery is brutal

The single most common operational failure in gift annuity administration is continued payment after death. Families do not think to notify the charity. Post gets forwarded. Payments continue by direct transfer into an account nobody has closed. Six months later the foundation discovers it and has to write to a bereaved family asking for the return of funds, which is both a financial recovery problem and a relationship problem in a programme built entirely on relationships.

What a custom build does: a defined verification cycle rather than a hope. Annual or semi annual confirmation contact appropriate to the annuitant's age band, a payment method check, and an escalation when contact fails. This is where machine assistance has one narrow and genuinely valuable role: matching your annuitant list against published death records and obituary sources, and raising a candidate for a human to verify. It must never suspend 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 any developer who proposes automating that decision has not thought about who is on the other end. Where a match is confirmed, the system computes the correct final payment, the recoverable amount, and generates the correspondence with the terms of the agreement cited.

Problem 3: state regulation of gift annuities is per state and it is not optional

Several states regulate charitable gift annuities directly, with requirements that can include registration or a permit before issuing 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 is a substitute for the statute.

What a custom build does: agreements carry the annuitant's state of residence at issue, reserve calculations run per cohort on the assumption set you configure, and the filing calendar is a work queue with the supporting schedules generated rather than assembled. Your actuary still owns the assumptions and should. The system's job is to make sure the underlying contract data feeding them is complete and current, which is exactly what breaks when it lives in a workbook.

Problem 4: tax reporting and accounting treatment are two different obligations and both need clean data

Your tax preparer, your annuitants and your auditors all draw on the same contract data and none of them accepts the others' output. When the source is a spreadsheet, each one gets a bespoke extract prepared by hand, and the three do not reconcile. We have walked into engagements where the audited liability and the administrator's own contract list disagreed on the number of active agreements.

What a custom build does: one contract dataset with the attributes each consumer needs, and generated outputs for each. Tax reporting files are prepared for your provider's format rather than typed. Liability schedules run with the assumption set as a parameter, so the auditor's sensitivity question is a rerun rather than a fortnight. Have your tax advisers and auditors specify the outputs before the build, since the details differ by institution and change with guidance.

Problem 5: a bequest is a case that lasts years, and no donor CRM (Customer Relationship Management) models it

A bequest expectancy is recorded when a donor tells you. Then nothing happens for a decade or three. Then a solicitor writes, and an estate administration case begins that may run three or four years through probate, involving partial distributions, a residuary calculation that depends on other assets, occasionally a contested will, and correspondence with an executor who does not return calls.

What a custom build does: expectancy and estate are separate objects with a link, each with their own lifecycle. The expectancy carries documentation status, whether the gift is revocable, and the stewardship record. The estate is a case with an executor contact, key dates, expected and received distributions, and a task queue that escalates when nothing has happened for ninety days, because the most expensive failure in bequest administration is a case going quiet. Document extraction has an honest use here: wills, trust deeds and legacy contract scans in varied formats become structured records with dates, names and amounts pulled for an administrator to confirm, which matters enormously when you are digitising a filing cabinet of paper contracts as part of the project.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the honest shape. A first release covering structured agreement records, generated payment runs with approval and variance review, annuitant verification cycles with death record candidate matching, reserve calculation inputs by state cohort, and a bequest expectancy and estate case pipeline runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding trust accounting for charitable remainder arrangements with unitrust valuations, tax reporting file preparation, per state filing schedules, liability reporting for audit and donor and adviser portals runs $180,000 to $420,000 phased over 7 to 12 months.

What pushes cost up specifically here: the number of states you are registered in, because each regime is separate analysis. Charitable remainder trusts, which bring trust accounting and are materially more work than annuities. Historic data, since digitising decades of paper contracts is a real project and the terms in old agreements are often ambiguous. Investment platform integration for pooled funds. And auditor and tax preparer output formats, which are institution specific.

What keeps cost down: keeping PG Calc or Crescendo for calculation and illustration and integrating with it rather than rebuilding actuarial computation. That is our standard recommendation and it removes the highest risk engineering in the project. You want the administration ledger, not a competing calculator.

Build versus buy, and when buying is the right call

Buy if you hold fewer than about 60 active agreements, issue in one or two states, and have a competent administrator with a documented process. PG Calc plus a disciplined workbook genuinely works at that size, and the money belongs in donor facing effort. FreeWill and Stelter remain sensible regardless of what you run for administration, since they solve a different problem at the top of the funnel.

Build when two or more of these are true. You hold more than about 200 active life income agreements. You are registered in several states with different reserve and filing regimes. You administer charitable remainder trusts alongside annuities. Your payment run depends on one person who understands the workbook's quirks. Or you have had an overpayment after death that had to be recovered from an estate.

Our position, stated plainly: the reason to build in this category is continuity, not efficiency. A gift annuity is a promise to pay a named 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 have manual overrides. That is a governance argument, and it is the one that persuades boards.

How to choose a developer for planned giving administration software

Ask them what they would do when a death record match comes back for an active annuitant. The correct answer is raise it for human verification and never suspend payment automatically. If they describe an automated stop, they do not understand that the person on the other end may be alive and dependent on that income.

Ask how they will handle historic contracts where the terms are ambiguous or the paperwork is partial. Every institution has them, and a system that cannot represent an unusual legacy agreement will push it straight back into a spreadsheet.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. 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.