A control total is the oldest trick in bookkeeping: before you key a stack of transactions, you write down what the stack should add up to. When you finish, the system’s total either matches your number or it doesn’t. If it doesn’t, you find the mistake before anything posts to the general ledger, not three weeks later when finance asks why the gift shop is off by $212.
Gift shop and merchandise teams want this check as much as anyone, and in Altru it’s not always obvious where it lives. Below is how control totals generally work in Altru batches, where merchandise fits, and how to build the same safety net when the field you want isn’t there.
How control totals work in Altru batches
Altru’s batch entry is built around the idea of entering a group of records, validating them, and then committing them as one unit. Depending on the batch type and how the batch template is set up, a batch can carry projected values: an expected number of records and an expected dollar total. As you enter rows, Altru shows the actual count and actual total alongside them, so you can see at a glance whether the two agree.
Used well, that turns a batch into a self-checking document:
- Before you start, count the items in your source (receipts, a vendor packing list, a deposit slip, a spreadsheet from an outside sales channel).
- Add up the dollar amount on an adding machine or in a spreadsheet, separately from Altru.
- Enter those two numbers as the projected count and projected total when you create the batch.
- Key the records.
- Before you commit, compare projected to actual. A mismatch in the count usually means a skipped or doubled row. A matching count with a mismatched total usually means a typo in one amount.
The key is that the projected numbers come from the paper or the source file, never from Altru itself. A control total you copied from the batch screen checks nothing.
Where merchandise is different
Most merchandise revenue in Altru doesn’t arrive through a manually keyed batch at all. Register sales at the shop flow through daily sales, and those transactions are already recorded one by one as they happen. There’s nothing to re-key, so there’s nothing for a projected total to compare against. The control point for register sales is reconciliation: closing out the drawer and matching what Altru recorded to the cash, card settlement, and any other tender.
Where a control total matters for merchandise is the work that is keyed or imported in bulk, such as:
- Receiving inventory from a vendor shipment
- Inventory counts and adjustments after a physical count
- Sales from an offsite event or pop-up that were tracked outside Altru and entered afterward
- Corrections and returns processed together at the end of a period
Whether each of these processes offers projected count and total fields in your version of Altru isn’t something we’d want to promise from the outside. Some batch types expose them and some don’t, and the answer can depend on the template your organization uses. The fastest way to confirm is to open a new batch of the type you use for merchandise work in a test or training environment and look for projected fields when you create it. If you don’t have a sandbox, Blackbaud support can tell you whether a given batch type supports them.
Building the check yourself when the field isn’t there
If the merchandise process you rely on doesn’t carry a projected total, you can still get the same protection with a little discipline. The control total just moves outside the screen.
Keep a batch header sheet
Before entering anything, write the expected item count, expected units, and expected dollar total on a simple header sheet or the top of the vendor packing slip. Initial and date it. This is the number you’ll check against later.
Total by units, not just dollars
For inventory receiving, dollars alone can hide errors. Keying 12 of an item at $4 and 4 at $12 gives the same dollar total as the reverse. Track total units received as a second control number. If both units and dollars match, the entry is very likely right.
Compare with a query before you trust the result
After entry, run a query or report on the merchandise records you just touched, filtered by date and the user who entered them. Sum the quantity and amount columns and compare them to your header sheet. Save the query so the shop manager can rerun it without rebuilding it each time.
Separate the person who counts from the person who keys
Where staffing allows, have one person produce the control total from the source documents and another enter the data. It’s a basic segregation of duties, and it catches far more than one person checking their own work.
Reconcile before the deposit or GL post
Make the comparison a required step before anything moves to finance. Once revenue has posted, corrections get more involved and finance has to be pulled in. A mismatch caught at the batch stage is a two-minute fix.
A simple routine for the shop
For a small gift shop team, this usually settles into a short checklist:
- Daily: close out registers and reconcile daily sales to tender. No batch control total needed; the drawer count is your control.
- Per shipment: header sheet with item lines, units, and cost total; enter receiving; compare to header before finalizing.
- Per offsite event: total the event’s sales sheet by payment type before entry; compare after entry.
- Monthly: run your saved merchandise query for the month and tie it to the finance report for the shop’s revenue accounts.
Quick answers
Does Altru require a control total before committing a batch?
Not that we’d rely on. Where projected totals exist, treat them as a check your staff completes, and make “projected equals actual” a written step before commit rather than assuming the system will stop a mismatched batch.
What if the totals don’t match and I can’t find the error?
Sort the batch rows by amount and compare line by line with the source in the same order. Transposed digits (for example, 54 entered as 45) leave a difference divisible by 9, which is a quick clue to look for.
