Donor Receipting and Acknowledgement Playbook

Overview

Receipting and acknowledging gifts is not a single process. Most advancement offices need several coordinated workflows: an immediate thank-you after an online gift, a formal receipt, a printed letter when appropriate, a review path for special gifts, and a way to identify gifts that still need attention.

Slate supports these workflows through forms, Deliver, documents, print fulfillment, queries, recipient lists, and mail merge tools. These tools are flexible by design. In most cases, the same donor, gift, payment, fund, and communication data can be used across multiple channels, allowing schools to create highly personalized, donor-centered acknowledgements.

The channel determines how and when the acknowledgement is delivered. The content can still be dynamic, conditional, and tailored to the donor.

Important: Receipt content, timing, and substantiation language are governed by institutional policy and applicable tax law. Slate provides tools for selecting records, generating communications, rendering documents, and recording activity. Your institution is responsible for determining appropriate receipt language, review requirements, and compliance practices.

Receipts, acknowledgements, and thank-you messages

Schools often use these terms differently. Before building the workflow, it is helpful to define what each communication is meant to accomplish.

These can be separate communications. For example, a donor may receive an immediate form thank-you seconds after giving online and later receive a formal receipt through a daily Deliver process.

How the receipting tools work together

Think of Slate's receipting options as delivery and workflow layers. Each layer serves a different purpose.

These mechanisms are not mutually exclusive. A donor may receive an immediate form thank-you, while the formal receipt is generated later through Deliver. A major donor may be excluded from the automatic email process and routed to a reviewed PDF or personalized letter. A donor without email may be routed to print.

Dynamic content across channels

One of the most important parts of Slate receipting is that acknowledgement content can be highly dynamic.

Across form communications, Deliver messages, documents, and merge-based workflows, schools can use donor and gift data to personalize the message. Depending on the configuration and data available to the message, query, or recipient list, acknowledgement content can include:

This means schools do not need separate static letters for every possible scenario. A single template can often adapt based on the donor and gift data.

For example:

• A donor to the Annual Fund can receive Annual Fund impact language.
• A donor to a scholarship fund can receive scholarship-specific stewardship language.
• A donor with multiple eligible gifts can receive a table of those gifts.
• A donor whose gift includes a benefit can receive different receipt language.
• A company donor can receive organization-specific acknowledgement language.
• A major donor can be routed to a reviewed version of the communication.

Tools for personalization

Slate acknowledgements can use several personalization tools.

The result is a donor-centered process: the message can reflect who the donor is, what they gave, how they gave, what they supported, and how the institution wants to acknowledge that relationship.

Choosing the right channel

Because the same data and dynamic content tools can often be used across channels, the main decision is usually not "Which channel has the right data?" but rather "Which channel fits the workflow?"

This keeps the choice focused on timing, delivery, review, and tracking.

The receipting channels

Form communications: immediate donor response

Form communications are best for the first donor touchpoint after an online gift. They can be configured on a giving form to send when the form is submitted.

Use form communications for:

• immediate thank-yous;
• online gift confirmations;
• recurring gift setup confirmations;
• simple acknowledgements tied directly to the form submission;
• messages that should reach the donor immediately or close to immediately.

A form communication is less ideal when the receipt needs batch review, aggregation, special routing, or formal print/PDF handling. In those cases, the form communication can provide the immediate thank-you while Deliver handles the formal receipt.

Example

A donor gives $50 through an online giving form. The form immediately sends a warm thank-you and confirms the gift. The school may decide that this message is sufficient for lower-complexity gifts.

Deliver email: scheduled electronic receipts

Deliver email is best when the school wants an automated, scheduled, trackable electronic receipt process.

Use Deliver email for:

• daily or weekly receipt batches;
• donors with email preference;
• gifts that do not require manual review;
• standardized formal receipt templates;
• messages that should appear in the donor's communication history.

A common Deliver email workflow identifies newly eligible gifts, applies donor and gift filters, sends a formal receipt, and records that message on the donor record.

Example

A school creates a daily Deliver email receipt process for received gifts where the donor has a valid email address, has not opted out of email, and does not require manual review. The message uses merge fields, content blocks, and Liquid to personalize the receipt by donor, gift, fund, and payment details.

Deliver Documents: polished PDFs and review workflows

Deliver Documents are best when the school wants a rendered document before fulfillment. This can be helpful when staff need to review, approve, download, print, or archive the output.

Use Deliver Documents for:

• formal PDFs
• reviewed letters
• major gift acknowledgements
• letters requiring specific layout or signatory formatting
• local print workflows
• gifts requiring approval before sending

A Deliver Document can still use dynamic content. The document can include merge fields, content blocks, Liquid conditions, and repeated rows for gifts or allocations. In the review phase of a Deliver Document, users can manually override any merge fields for that particular send.

Example

A school routes all gifts of $5,000 or more to a Deliver Document workflow. Staff review the generated letters, confirm any special stewardship language, and then print or fulfill the approved documents.

Slate Print: physical mail

Whereas Deliver Documents allows for the local printing and fulfilling of physical mail, Slate Print allows for a more automated print and fulfillment process.

Use Slate Print workflows for:

• donors without email
• donors with mail preference
• formal mailed receipts
• standardized non-special types of receipting and acknowledgement

The same dynamic content principles apply. Printed letters can still include donor-specific details, gift information, conditional content, fund-specific language, and appropriate signatory blocks.

Example

A school runs a weekly printed receipt workflow for donors who do not have a valid email address or who prefer mail. The printed letter uses the same core receipt language as the email version but is formatted for physical mail.

Query and mail merge: review, exceptions, and manual workflows

Query is best when staff need to find, review, export, or manually process gifts before sending anything.

Use Query for:

• catch-up receipts
• imported gifts
• exceptions
• Excel review
• cleanup workflows

Query workflows can be especially helpful when gift processing staff need to review results before generating output. Query result history can also help document that a donor was included in a receipt run, depending on how the query is configured.

Example

A gift processing team runs a weekly query to identify gifts that need formal printed acknowledgements. The team reviews the results, exports to Excel for approval, and then generates a mail merge for printing.

Building a donor-centered routing model

Rather than creating entirely separate receipt processes for every gift scenario, schools should define routing rules that determine which channel handles each donor or gift.

Common routing factors include:

These factors can be used across channels. The same gift amount, donor preference, or fund designation might determine whether someone receives an email, a printed letter, a reviewed PDF, or a manual follow-up.

Recommended workflow

A strong receipting process usually includes five connected paths.

1. Immediate online gift thank-you

Use form communications to thank online donors right away.

This message should be warm, concise, and donor-centered. It can include basic gift details, but it does not need to carry the full burden of the formal receipt if that is handled later.

2. Standard automated receipt path

Use Deliver email for gifts that can be receipted automatically.

This path is usually for donors who:

• have a valid email
• have not opted out of email
• made a gift that is eligible for automatic receipt
• do not require manual review
• do not need special handling

3. Print or mail path

Use a print or letter workflow for donors who should not receive email.

This path is usually for donors who:

• do not have a valid email
• prefer mail
• should receive a formal printed letter
• are excluded from email for policy reasons

4. Review path

Use Deliver Outbox for gifts that need review before sending.

This path is usually for:

• major gifts
• gifts with benefits
• in-kind gifts
• stock gifts
• planned gifts
• tribute gifts
• gifts with unusual allocations
• donors requiring personalized stewardship

5. Exception and cleanup path

Use Query for catch-up processing and exceptions.

This path is useful for:

• imports
• missed receipts
• failed emails
• address cleanup
• bounced communications
• one-time projects.

Finding gifts since the last run

Recurring receipt workflows need a reliable way to identify gifts that are newly eligible since the last time the process ran. This applies to tracking queries, Deliver recipient lists, recurring email messages, Document workflows, and other ongoing acknowledgement processes.

At a high level, the process uses the created date of the gift to determine whether the gift was created since the prior query, mailing, document, or recipient-list run. The the core pattern is:

1. Configure the query or recipient list so result history can be used for tracking.
2. Add a dependent subquery filter that joins to Gifts.
3. Compare Gifts Created Date to the current query run timestamp start and stop values.
4. Use the same criteria anywhere gift details are displayed, especially in subquery exports or repeated gift rows.
5. Execute and test the process, rather than relying only on preview behavior.

The important concept is that the person is selected because they have a gift that was created during the current run window, and the receipt content should display only the gifts that meet that same run-window logic.

Secondary key for recurring recipient lists

For ongoing mailings, Documents, recipient lists, and similar recurring acknowledgement workflows, configure the recipient list with @run as the secondary key.

This ensures the process can evaluate the current run context and identify gifts created since the last time the acknowledgement process ran. This is especially important when the same donor may give more than once over time and should be eligible for a future acknowledgement when a new gift is created.

Avoiding duplicates and missed acknowledgements

Because the same donor and gift data can be used across multiple channels, schools should design the process so each gift flows to the correct path once.

The key is to decide how the institution tracks receipt eligibility and completion.

Questions to answer:

1. Is the receipt tracked by donor, by gift, or by run?
2. Should one donor receive one receipt for multiple gifts?
3. Should each gift receive its own receipt?
4. Which date determines eligibility for a batch?
5. Which gifts have already been included in a previous run?
6. Which channel has priority if a donor qualifies for more than one?

For most recurring acknowledgement workflows, the gift's created date is the right field to identify gifts that entered Slate since the last run. The donor-facing receipt can still display the gift date, while the process uses created date to identify newly created gift records.

Match donor selection to gift detail

One of the most common receipting issues occurs when the query selects the right donor but the template displays the wrong gifts.

For example:

• The recipient list finds donors with gifts from the current batch.
• The template displays all gifts on the donor record.
• The donor receives a receipt showing old gifts.

To avoid this, the gift detail used in the message should match the same logic that selected the donor.

If the process is selecting gifts created during the current run window, the gift rows in the receipt should also be limited to gifts created during that same run window.

Test multiple runs

A recurring receipt process should be tested more than once.

For example:

1. Create a test donor and test gift.
2. Run the query, mailing, Document, or recipient list process.
3. Confirm the donor receives or appears in the expected output.
4. Run the same process again without adding a new gift.
5. Confirm the donor does not appear again.
6. Add a second test gift for the same donor.
7. Run the process again.
8. Confirm the donor appears with only the new eligible gift, or with the expected batch of gifts.

This is the best way to confirm that the process avoids both duplicate and missed receipts.

Receipt content considerations

Slate templates can be dynamic, but the institution controls the language.

Common receipt content includes:

Dynamic content can make the receipt feel personal without requiring separate templates for every donor segment.

Troubleshooting

A donor received a duplicate receipt

Check whether the same gift qualified for more than one channel.

Look for:

• overlapping email and print filters;
• multiple active Deliver mailings;
• a form communication that is also being used as a formal receipt;
• query or recipient-list logic that does not exclude previously processed gifts;
• gift detail loops that include older gifts;
• a missing @run secondary key on an ongoing recipient list.

A gift was missing from the receipt run

Check whether the gift met all eligibility criteria.

Review:

• gift status
• gift type
• gift amount
• gift date
• gift created date
• donor email or address
• communication preferences
• review-required filters
• prior run or query history
• whether the recipient list has @run as the secondary key where required

The donor was selected, but the receipt showed the wrong gifts

Check the gift-detail logic in the query or subquery export.

The gift detail should use the same criteria as the recipient selection. If the recipient list selects donors with gifts created during the current run window, the repeated gift rows should also be limited to gifts created during that same run window.

Preview results do not match execution

Some query or run-based behavior may only apply when the process is fully executed.

For receipt workflows, test with actual execution in a controlled environment rather than relying only on preview.

A donor without email did not receive a printed receipt

Confirm that the print workflow is a separate path and that the donor qualifies for it.

Check address availability, mail preferences, and print recipient filters.

The receipt does not appear on the donor timeline

Tracking depends on the mechanism.

Messages sent through Slate communication tools are typically visible as communication history. Query exports and external mail merges may document that a query was run, but they may not create the same sent-message timeline record unless the fulfillment also happens through Slate.

Frequently asked questions

Do I need separate templates for every receipt scenario?

Usually, no. A well-designed template can use merge fields, content blocks, and Liquid logic to adapt based on donor and gift data.

Should the immediate form thank-you also be the formal receipt?

It can be, but it does not have to be. Many schools use the form communication for immediate gratitude and a separate Deliver or document process for the formal receipt.

Can one receipt include multiple gifts?

Yes, if the query / recipient list is designed to return the correct gift rows for that donor.

How do we prevent the same gift from being receipted twice?

Use a consistent tracking strategy, mutually exclusive routing filters, the gift created date/run-window pattern, and @run as the secondary key for recurring recipient-list workflows where required. Make sure the same gift cannot flow into both email and print unless that is intentional.

Can receipts be personalized by fund or designation?

Yes. Receipt content can include fund-specific or designation-specific language through merge fields, content blocks, and conditional logic.

Can major gifts be excluded from automatic receipts?

Yes. Use routing filters to exclude them from automatic paths and include them in a review workflow.

Can annual summary receipts be created?

Yes, but they require intentional query and template design. The process should define the reporting period, included gifts, display format, and tracking approach.

Practical implementation checklist

Define the policy

• Which gifts receive formal receipts?
• Which gifts receive only a thank-you?
• Which gifts require review?
• What gift amount thresholds matter?
• Which donors receive email versus print?
• How should bounced emails be handled?
• How should annual summaries be handled?
• Who approves receipt language?

Define the routing

• What qualifies for automatic email?
• What qualifies for print?
• What qualifies for review?
• What qualifies for exception processing?
• Which channel has priority?
• How are duplicates prevented?

Define the content

• Which receipt template is used?
• Which content blocks are shared?
• Which language is conditional?
• Which gift fields display to the donor?
• Which repeated gift rows appear?
• Which signatory appears?
• Which contact information appears?

Define the tracking

• Which query, mailing, document, or recipient list identifies new gifts?
• Does the process use gift created date to find gifts since the last run?
• Are current query run timestamp start and stop values used where appropriate?
• Is @run entered as the secondary key on recurring recipient lists where required?
• Do subquery exports or repeated gift rows use the same new-gift criteria as the recipient selection?

Test the process

• Test an online gift.
• Test a donor with email.
• Test a donor without email.
• Test a donor with mail preference.
• Test a major gift.
• Test a gift with multiple designations.
• Test a second gift from the same donor.
• Test a missing address.
• Test repeated runs.