Say a donor buys a $250 gala ticket. Dinner, drinks, and entertainment are worth about $90. The receipt they get afterward needs to say two things clearly: the value of what they received ($90) and the portion they can treat as a charitable contribution ($160). A receipt that just says “Thank you for your $250 gift” is wrong, and it’s the kind of thing a donor’s accountant will call about.
Getting Altru to produce that receipt is less about one setting and more about making sure three numbers exist somewhere Altru can pull them: what the person paid, what the benefits were worth, and the difference. Below is how to set that up, plus the edge cases that tend to break it.
What the receipt has to say
Under IRS rules for U.S. nonprofits, when someone pays more than $75 and gets goods or services in return (a quid pro quo contribution), you have to give them a written statement that:
- tells them only the amount above the value of the goods or services is deductible, and
- gives a good-faith estimate of that value.
Separately, any single contribution of $250 or more needs a written acknowledgment that states whether anything was provided in return. A gala receipt usually has to satisfy both. This isn’t legal advice, so have your finance lead or auditor sign off on the wording, but those are the pieces your template needs to carry.
Step 1: Decide where the benefit value lives
This is the part that trips people up. The ticket price is easy, since it’s on the registration revenue. The fair market value of the benefits has to be recorded somewhere too, or no receipt can print it.
Check your own database before assuming anything. Depending on how your events and prices were set up, you may already have a way to record a deductible or benefit amount on the event price or registration option. Open one of last year’s gala events, look at its price setup and a completed registration, and see whether a benefit value or deductible amount is stored anywhere. If you’re not sure what you’re looking at, test in a sandbox or ask Blackbaud support whether your version supports a deductible amount on event registrations.
If there’s no native field, pick one consistent workaround and stick with it:
- An attribute on the event holding the per-ticket benefit value. This works well when every ticket at that event has the same value.
- An attribute or note on each price level when you sell tiers (individual, patron, table) with different benefits.
- A small lookup sheet kept by finance, used only if the first two aren’t possible. It’s the most fragile option, because someone has to remember to update it.
Whatever you choose, record the value before tickets go on sale. Changing it after receipts go out means reissuing them.
Step 2: Build the query behind the receipt
Your receipt is only as good as the query feeding it. Build an event registration query (or a revenue query filtered to the event) that returns one row per payer with:
- constituent name and address (the payer, not necessarily the attendee)
- number of tickets and the total amount paid
- the benefit value per ticket, from wherever you stored it in Step 1
- total benefit value (tickets times per-ticket value)
- deductible amount (amount paid minus total benefit value, never below zero)
If your query tool can’t do the subtraction directly, export the results and calculate the deductible column in a spreadsheet before the merge. That’s fine for a once-a-year gala. For events you run monthly, it’s worth getting a smart field or calculated output so nobody has to remember the formula.
Step 3: Write the template
Use your normal acknowledgment or letter process in Altru, or a mail merge from the query export, whichever your team already trusts. A clear version reads something like:
“Thank you for your payment of $250 for the Spring Gala. In exchange, you received dinner and entertainment with an estimated fair market value of $90. The amount of your payment that is deductible as a charitable contribution is $160.”
Keep the three numbers on separate lines or in a small table if the letter is for multiple tickets. Donors read these at tax time, months later, and they won’t remember the event details.
Edge cases to settle before the event
Extra gifts on top of the ticket
Paddle raises, “add a donation” at checkout, and auction overbids should be recorded as separate revenue where possible. If a gift gets lumped into the registration payment, your deductible math will undercount it.
Auction items
Auction purchases are their own quid pro quo calculation (price paid minus item value) and are usually better handled on a separate receipt than squeezed into the event letter.
Declined benefits
Someone who buys a ticket and states up front that they won’t attend may be able to treat the full amount as a gift, but only if they actually declined the benefit. Decide your policy with finance and record it on the registration so the receipt query can treat those rows differently.
Comps, sponsors, and tables
Sponsors often get a table plus recognition. The table seats have a value; the logo on the program generally doesn’t count the same way. Track sponsor packages as their own price level with their own benefit value so they don’t inherit the individual ticket math.
Refunds and transfers
Run the receipt query after refunds are processed, not the morning after the event. Otherwise you’ll mail receipts for money you gave back.
Check it before it goes out
Pull five registrations by hand: a single ticket, a multi-ticket purchase, a sponsor, someone who added a donation, and a comp. Work out what each receipt should say on paper, then compare it to the merged output. If all five match, the rest almost always will. If one doesn’t, it’s usually a payer-versus-attendee mix-up or a gift that got combined with the ticket.
