A year-end statement is the last place to find a bad total

Do not start a year-end giving statement with the letter template. Start with the completed gifts that belong in the reporting year, resolve donor and payment exceptions in the source records, then prove the generated documents and delivery list before anything leaves your system. That is the practical work behind accurate nonprofit year-end giving statements.

That sequence turns the annual statement into a controlled fundraising-operations batch instead of a January mail merge. It also keeps a bad donor total from becoming a polished PDF that your team has to correct later.

Define the statement set before choosing the wording

Write the inclusion rule in one place before anyone generates a document. At minimum, name:

• the reporting year;
• the payment states included;
• the donor or household grouping rule;
• the gift types handled outside the standard cash-gift path;
• the owner who approves statement and disclosure language.

Current products do not make identical choices for you. Givebutter's current year-end summary guidance includes online and offline transactions and labels refunded transactions. Bloomerang's current statement guidance separates monetary, in-kind, and indirect support and says refunded transactions do not appear in its tax-summary section. Those are product behaviors, not a universal policy.

Your team should decide which completed records form the donor-facing set, then configure or review the product against that decision. Keep failed or pending payments out of a completed-gift total. Treat a refund, reversal, soft credit, in-kind item, event benefit, or employer match according to your approved procedure instead of forcing it into the default row.

This article covers the operational batch, not legal or tax language. In the United States, the IRS explains that substantiation and disclosure requirements vary by contribution and can require specific acknowledgments or disclosures. Use current authoritative guidance or a qualified adviser for the wording and treatment your organization needs.

Clear record exceptions before generating statements

A statement tool can only summarize the records it receives. Build an exception queue for records that are not ready:

1. Identity exceptions. One person may have gifts under two email addresses, while two household members may need separate records. Resolve the identity decision before combining totals. The duplicate-record checks should protect gift ownership, communication preferences, and household relationships.
2. Payment exceptions. Review pending, failed, refunded, reversed, or disputed transactions. Confirm that the displayed amount and status match the source payment record.
3. Channel exceptions. Confirm that checks, cash, imported gifts, and other offline transactions were entered once and linked to the correct donor. A missing check is a source-record problem, not a PDF problem.
4. Gift-type exceptions. Route in-kind, indirect, benefit-linked, or other nonstandard gifts through the procedure and language your organization has approved.
5. Delivery exceptions. Hold records with no usable email or mailing address in a named queue instead of silently dropping them from the batch.

Give every exception a record ID, reason, owner, and next action. Do not write “review later” beside a donor total and proceed with the rest of that person's statement.

Generate a proof set before the full batch

Create test statements from real, reviewed records before generating the entire audience. A useful proof set covers the shapes your data actually contains, such as:

• one donor with a single completed gift;
• one donor with several recurring payments;
• one donor with an offline gift;
• one record with a refund or adjustment;
• one resolved duplicate or household case;
• one donor who needs a non-email delivery path.

For each sample, trace every displayed line back to its source gift. Check the donor name, reporting year, gift dates, amounts, total, organization details, approved language, and delivery address or account access. The test is not whether the PDF looks tidy. The test is whether another person can reproduce its total from the same records.

This annual batch comes after the immediate receipt and acknowledgment workflow. It does not repair a missing receipt or replace the record of what happened when the gift arrived.

Reconcile the audience in both directions

After the proof set passes, compare the full batch in two directions:

• Every eligible donor should have exactly one generated statement or one documented exception.
• Every generated statement should map to one eligible donor record and the completed gifts that support its total.

Record the expected donor count, generated statement count, total exceptions, and chosen delivery path. If those counts do not reconcile, stop before delivery. A segment filter, duplicate contact, missing address, or product default may have changed the audience.

Keep a simple delivery ledger with states such as generated, test-checked, available in portal, delivered, mailed, failed, or held. The exact labels matter less than preserving what happened to each document. A batch-level “sent” note cannot answer a donor who says their statement never arrived.

Correct the source record, not the finished document

When review finds a wrong name, missing gift, or incorrect total, fix the underlying donor or gift record first. Regenerate the statement and preserve which version replaced the prior one.

Editing one PDF may solve the immediate appearance problem while leaving the CRM, donor portal, and next report wrong. The durable correction is the one that makes every future view of the same gift agree.

Release only after three proofs pass

Use three observable proofs for the final decision:

• Gift-set proof: included and excluded records follow the written rule, and every exception has an owner.
• Document proof: sampled statements reproduce their totals from source gifts and use approved language.
• Delivery proof: every generated statement has a delivery path or a visible hold reason.

If one proof fails, keep the batch open. If all three pass, your team can deliver the statements without turning January into a search for missing gifts, split donors, and edited PDFs.