A household buys a family membership at the front desk and adds a $50 donation to the same order. A week later, the same couple mails in a check for the annual fund, which gets entered in a back-office batch. Ideally they get thanked for all of it, accurately, with the right deductible amounts. In practice, many Altru organizations end up sending one letter that misses the donation, two letters that contradict each other, or nothing at all for the order.
The root issue is that gifts and memberships reach Altru through different doors. Building one acknowledgement process means deciding which door you treat as the source of truth, then designing a single query and letter that understand both.
Why the two paths split apart
Back-office entry (revenue records, batches, pledges and payments, memberships added directly on a constituent record) is where development staff usually live, and it is what most acknowledgement setups are built around.
Orders are different. Daily sales, advance sales, and online web form checkouts create a sales order that can bundle tickets, a membership, and a donation in one transaction. That order still produces revenue in Altru, but the way it is structured, and whether it flows into the same acknowledgement tools as back-office revenue, is not something to assume. Before you design anything, confirm it:
- In a sandbox or test environment, ring up an order that includes a membership and a donation, and enter a matching back-office gift.
- Run your current acknowledgement process and see which of those transactions appears, and how it is described.
- If order revenue does not show up where you expect, ask Blackbaud support how your version handles acknowledging sales order donations and memberships. Behavior can depend on configuration, so a test beats a guess.
Build around revenue, not around the department
The most dependable approach is to make revenue the base of your acknowledgement query, because both back-office entries and orders ultimately produce revenue. From there, add the fields that tell your letter what it is looking at:
- Application type for each line: donation, membership, or other (tickets, merchandise).
- Amount per application, so a $150 order can be described as $100 membership plus $50 gift.
- Membership level and program, plus the membership dates if you want to mention them.
- Benefits value or deductible amount, so the letter can state what portion is tax-deductible.
- Channel or source (back office, daily sales, web) for your own auditing, even if it never prints.
- Addressee and salutation from the constituent or household, so a couple gets one letter, not two.
- An acknowledged status or date, so you can exclude anything already thanked.
If your query tool cannot reach a field you need through the revenue record, smart fields on the constituent are worth a look for things like current membership level. Keep the first version simple and add fields once the core output is right.
One letter or several?
You have two reasonable designs. Pick based on volume and how much your letters differ.
A single letter with conditional paragraphs
One template, with sections that appear only when the transaction includes a donation, a membership, or both. This works well when your mail merge supports conditional fields and someone on staff is comfortable maintaining them. The benefit is one process and one place to fix wording. The risk is that a broken condition can quietly print the wrong paragraph, so proof a sample of each combination every time you change the template.
A small set of letter versions
Three versions (gift only, membership only, membership plus gift), each fed by a filtered copy of the same query. This is easier for most teams to read and troubleshoot. The trade-off is that you have to keep the shared language in sync across versions, and any transaction that doesn’t fit cleanly into one bucket needs a home. Add a fourth “review” output for anything unusual rather than forcing it into the wrong letter.
Get the tax language right
Combined acknowledgements are where deductibility mistakes creep in. A membership with meaningful benefits is usually only partly deductible, while the add-on donation in the same order may be fully deductible. Your letter should state the amount received, describe the goods or services provided in exchange, and give the deductible amount. Make sure benefit values are actually recorded on your membership levels; if they are blank, the letter will overstate the deduction. Have your finance lead or accountant approve the wording once, then lock it.
Per transaction or per period?
Decide whether you thank each transaction or roll a constituent’s activity into one letter for a period, such as weekly. Per-transaction letters are faster and simpler to query. A periodic roll-up handles the couple in the opening example more gracefully, since their order and mailed check land in one letter, but it needs a date range, a grouping by constituent or household, and a firm rule about what happens to a gift that arrives the day after the cutoff.
Many organizations send per-transaction letters for anything over a set threshold and a periodic summary for smaller activity. Whatever you choose, write it down so development and admissions staff aren’t each running their own version.
Close the loop
- Run the query and review the output before merging, sorting by channel to spot gaps.
- Merge, proof a sample of each letter type, and send.
- Mark the revenue as acknowledged in Altru so it drops out of the next run.
- Once a month, run the query without the acknowledged filter for the prior period and compare counts. Anything never marked is a transaction that fell through.
Quick answers
Do web order donations need a separate acknowledgement from the online receipt?
Often the order confirmation is not written as a proper gift acknowledgement. Check whether yours states the deductible amount; if not, include web orders in your regular letter run.
What about memberships given as gifts?
Acknowledge the purchaser, not the recipient, and make sure your query pulls the paying constituent. Test this case specifically, since it is easy to address the letter to the wrong person.
