A $250 payment shows up on a constituent record with the wrong designation, or applied to the wrong pledge, or entered twice. Finance wants to know who keyed it so they can ask what happened. You open the payment in Altru, scan the page, and the person who entered it isn’t obvious anywhere.
That’s a common frustration with payments entered in the back office. The information usually exists in the database; it just isn’t displayed prominently on the payment itself. Below is where to look, what to set up so you can answer the question in seconds next time, and a few habits that make “who did this?” easier to resolve.
Why the payment screen doesn’t tell you
Altru’s revenue pages are built around the money: amount, date, payment method, designation, application to pledges or memberships. Who entered the transaction is treated as system information rather than revenue information, so it tends to live in the background. Depending on your version and how your pages are laid out, you may see it in a record’s history or not at all on the page itself.
The good news is that Altru, like most Blackbaud databases, generally stamps records with system fields when they’re created and changed: a date added, a date changed, and the user who did each. Those fields are what you want, and the most reliable way to get at them is a query.
Build a “payments with entered-by” query
This is the approach I’d start with, because once it’s saved, anyone with query rights can answer the question without calling an admin.
- Start an ad-hoc query on revenue. Choose the revenue source your organization normally uses for payment reporting.
- Look for system fields. Browse the field list for items like date added, date changed, added by, and changed by. They’re often grouped under a system or record-information node rather than with the transaction fields, so expand everything before deciding they’re missing.
- Add the useful context. Constituent name and lookup ID, amount, transaction date, payment method, designation, and transaction type. Include the batch number if one is available, so you can tell batch entries from one-off entries.
- Filter tightly. Filter on transaction type (payments only), a date range, and optionally a specific constituent or amount. A broad query across all revenue will be slow and noisy.
- Save it to a shared folder with a plain name, for example “Payments – who entered,” so finance can find it.
One caution: if you can’t find an added-by field in the revenue source you’re using, don’t assume it doesn’t exist anywhere. Try a different revenue-related source, or ask Blackbaud support which query view exposes the user who added a payment in your version. Test in a sandbox if you have one before rolling the query out.
Added by versus changed by
These answer different questions. Added by is who created the payment. Changed by is the last person who edited it, which might be someone who fixed a designation weeks later. If you’re investigating an error, look at both, and look at date changed. A payment added correctly and then edited badly is a different conversation from one that was wrong from the start.
Check whether it came through a batch
Many back office payments are entered through revenue batches, especially gift processing and mailed checks. Batches typically carry their own ownership and history: who created the batch, who it’s assigned to, and who committed it. If your team uses batches consistently, the batch is often a faster trail than the payment itself.
That said, the person who committed a batch isn’t always the person who typed each row. If two people share a batch, you may still need the payment-level added-by field to pin down a single entry.
Daily sales are a different trail
Payments taken at the register through daily sales are tied to the sales session and drawer, and to the user logged in at the time. If the payment in question started as a ticket or membership sale at the front desk, look at the order and the related reconciliation rather than back office revenue. Mixing the two up is a common reason people conclude “Altru doesn’t track this.”
About audit history
Some Blackbaud platforms support auditing that keeps a fuller history of changes, not just the most recent editor. Whether that’s available and turned on in your Altru database is something to confirm with Blackbaud support rather than assume. If you need a full edit history for compliance or a dispute, ask before you need it; auditing generally only captures changes made after it’s enabled.
Habits that make this easier
- Use individual logins. A shared “frontdesk” or “finance” account makes every added-by field useless. This is the single biggest factor.
- One owner per batch. If batches are split between people, split them into separate batches instead.
- Keep a reference field convention. If your payment entry includes a reference or note field, some teams add initials and a source (check number, email, phone). It’s redundant with system fields, but it’s visible on the record without a query.
- Review security roles. Limit who can edit committed payments. Fewer editors means changed-by actually points somewhere.
- Run the query weekly during heavy periods. Year-end giving and membership drives are when entry mistakes pile up; a quick review catches them while people still remember the call.
Quick answers
Can I add an “added by” column to the payment page itself?
Page layouts in Altru aren’t freely customizable the way a spreadsheet is. If you don’t see it, a saved query is the practical substitute.
Does added by show the staff member or the donor for online payments?
Online gifts are usually created by a system or web user rather than a staff login, so added by will typically show that account. To identify the donor, look at the constituent on the payment instead.
