The development associate keys in forty checks from a mail appeal. On every one of them, the payment screen comes up wanting a decision about how the gift was paid, and on every one they pick “Check” again. Then a cash donation from the front desk lands in the stack, nobody notices the method they picked out of habit, and the deposit is off by one gift at month end.
The short answer: there isn’t a widely known, documented setting in Altru that makes one payment method the default for every back-office transaction. How payment entry behaves depends on where you’re entering it (a back-office sale, a donation, a membership, a pledge payment, or a revenue batch), and your options are different in each place. Below is how to find out what your database can actually do, plus the workarounds that cut down on errors when it can’t.
First, pin down which screen you mean
“Back office” covers a lot of ground in Altru. Before you look for a setting or open a support case, be specific about where the repetitive clicking happens:
- Back-office sales for advance sales, group sales, or phone orders.
- Individual revenue entry on a constituent record: donations, membership payments, pledge payments.
- Revenue batches, where staff enter many gifts at once, usually from mail or events.
Each one has its own form and its own defaults. A fix that works in one may not exist in the others, so it helps to know which one is costing your team the most time.
How to confirm what your Altru database supports
Altru changes with each release, and admin options sometimes show up where you don’t expect them. Rather than guessing, check it directly:
- Search Altru’s help for “payment method” and “default.” The help documentation covers configuration options more thoroughly than most training material does.
- Look at your batch setup if you use batches. Batch-based entry is the most likely place to find prefilled field values, because batches are built for repetitive data entry. Test whether your batch type or template lets you set a starting value for the payment method field. Try it in a test batch you can delete before you change anything staff use.
- Open a case with Blackbaud support. Name the exact screen and ask: “Can the payment method be preset on this form, and if not, is there a supported workaround?” A specific question like that gets you a definitive answer faster than a general one.
- Check the community forums. Other Altru admins have probably asked about the same screen, and their answers often show what’s possible in current versions.
If none of those turn up a setting, assume you have to work around it, not configure it.
Workarounds that reduce mistakes
Trim the payment method list
Every extra option on the dropdown is another chance to pick the wrong one. Check which “other” payment methods are set up in your code tables and deactivate the ones nobody has used in years. A short list is quicker to pick from and harder to get wrong. Run a quick query first to confirm a method really is unused before you retire it.
Separate work by payment type
If your team uses batches, keep checks, cash, and credit cards in separate batches instead of one mixed stack. Whoever is keying the batch knows every entry uses the same method, and a gift with the wrong method stands out when you compare batch totals to the deposit slip.
Write the rule down for each screen
A one-page reference that says “phone orders are credit card, mail gifts are check, anything else gets flagged” does more than you’d think, especially for seasonal and part-time staff. Keep it next to the workstations where back-office entry happens.
Keep card payments where they belong
Card payments have their own processing and reconciliation path. If staff sometimes record a card payment as “Other” or “Cash” to save time, your deposits and processor reports won’t match. Be explicit that card payments always go through the card payment method, even when it takes a few more clicks.
Catch wrong payment methods before they reach the bank
Defaults are partly about saving clicks. Mostly they’re about getting the method right. Even without a default setting, you can spot errors early:
- Build a revenue query showing transaction date, amount, payment method, and the user who entered it. Run it daily or weekly and sort by payment method. One “Cash” entry in a stack of mailed checks is easy to spot.
- Reconcile against the deposit before batches are committed or posted. Fixing a payment method is much easier before revenue has posted to your general ledger export.
- Watch for patterns by user. If one person accounts for most of the corrections, that’s a training issue, not a configuration one.
Quick answers
Is there a global “default payment method” option in Altru?
Not one that’s widely documented. Ask Blackbaud support about the specific form you use, because the answer may differ between sales, individual revenue entry, and batches.
Will changing payment method options affect past transactions?
Deactivating a payment method in a code table normally just hides it from new entries. Existing revenue keeps the method it was recorded with. To be safe, confirm that in a test environment or with support before you clean up the list.
What’s the fastest fix if staff keep choosing the wrong method?
A shorter dropdown, batches split by payment type, and a weekly audit query. Together they catch most errors without any new setting.
