Two people pull “December donations” from Altru and come back with different totals. Neither query is broken. One filtered on the date the gift was given, the other on the date someone typed it in. In January, when year-end checks are still arriving and the batch backlog is real, that gap can be thousands of dollars.
Altru stores several dates on every payment, and the query field list doesn’t always make it obvious which is which. This guide sorts them out, explains what each one is good for, and suggests which to use for the reports people actually ask for.
The dates you’ll find on a revenue record
Exact labels vary depending on which query source you start from (revenue, revenue application, constituent, membership, sales order), so expand the field tree and read carefully. Broadly, you’ll run into these:
The revenue date (what most people mean by “gift date” or “transaction date”)
This is the date entered on the payment itself: the day the donor gave, the day the ticket was sold, the date on the check. In many query sources it’s labeled simply Date. Staff can set it when entering a gift, which is why a check dated December 30 that’s keyed in on January 8 can still carry a December date.
In everyday Altru conversation, “gift date” and “transaction date” usually both point here. Altru doesn’t keep a separate “gift date” that differs from the revenue date on a normal payment, as far as most admins encounter it. If your organization uses the terms differently (for example, treating the check date and the receipt date as distinct), confirm which one your staff are actually typing into that field.
Date added (the entry date)
This is a system stamp recording when the record was created in the database. Nobody chooses it; Altru sets it. It answers “what got entered this week?” rather than “what was given this week?”
Date changed
Another system stamp, updated when the record is edited. Useful for audits and for spotting records someone touched after the fact. Not useful for revenue totals, because a typo fix in March moves a December gift into March under this field.
Post date and post status
If you post to a general ledger, revenue also carries a post date and a status (not yet posted, posted, do not post). Finance reconciles against this. It can differ from both the revenue date and the entry date, especially around fiscal year-end.
Dates that belong to something else
Sales order and membership queries add their own dates: the event or visit date on a ticket, the membership’s start and expiration dates, a pledge’s installment due dates. These describe the thing purchased, not the payment. A ticket bought in November for a December program has a November transaction and a December event date.
Which date to filter on
- Fundraising totals, donor acknowledgments, year-end giving statements: the revenue date. It reflects when the donor gave, which is what tax receipts and donor communications should reflect.
- “What did the team enter yesterday?” and batch spot checks: date added. It catches everything keyed in a window, regardless of what date was put on the gift.
- Matching finance or the GL: post date, plus post status. Ask your finance lead which they reconcile against before building anything.
- Attendance and capacity questions: the event or visit date on the sales order, not the payment date.
- Cleanup audits: date changed, to find records edited after a report already went out.
Where totals drift apart
A few situations reliably produce mismatched numbers:
- Backdated entries. Mail gifts entered after the fact carry an earlier revenue date than date added. Month-end reports run on date added will undercount the month the gifts belong to.
- Reports rerun later. A December total pulled on January 2 will be smaller than the same query run on January 20, because late entries keep landing in December by revenue date. Note the run date on anything you send to leadership.
- Adjustments and edits. Changing an amount or date on a posted gift may create an adjustment with its own date. If your numbers don’t match finance after edits, look at adjustments before assuming the query is wrong.
- Mixing query sources. A revenue query and a revenue application query can count the same payment differently when one payment covers several things (a membership plus a donation, for example). Pick one source for a given report and stick with it.
Habits that keep this from recurring
- Rename output columns in your queries so the header says “Gift date (revenue date)” or “Entered on (date added)” instead of just “Date.”
- Put the date logic in the query name or description: “Revenue by gift date, current FY” tells the next person what they’re looking at.
- When two reports disagree, add both date fields to one query and sort by the difference. The outliers usually explain the gap in a few minutes.
- If you’re unsure whether a particular field is user-entered or system-set, create a test gift in a sandbox, backdate it, edit it, and watch which fields change.
When the query feeds another tool
The same choice matters when Altru data leaves Altru. A spreadsheet or email platform fed by a query inherits whatever date that query used, and nobody downstream will know a “Date” column means entry date unless you say so. Data Bridge syncs Altru queries to Google Sheets, Mailchimp, ActiveCampaign and other tools, so the date decisions above carry straight through to those destinations. Settle which date each query uses and label the columns clearly before you connect it.
Quick answers
Is “transaction date” different from “gift date” in Altru?
For a typical payment, both usually refer to the revenue date entered on the record. The meaningfully different dates are date added, date changed, and post date.
Can staff change the date added?
Generally no. It’s set by the system when the record is created, which is what makes it reliable for entry audits.
