A donor’s check for $250 gets keyed as $25. Or the amount is right but the check was meant to cover a membership and a gift, and it all landed on one line. Either way, someone has to change a check amount in Altru, and how hard that is depends almost entirely on one question: has the payment been posted to your general ledger yet?
Answer that first. Everything else follows from it.
Step one: find out where the payment lives
Open the constituent record, go to their revenue, and look at the payment in question. You are trying to learn three things:
- Is it still in a batch? If your team enters checks through revenue batches and the batch hasn’t been committed, the payment isn’t really “in” Altru yet.
- Is it committed but not posted? The revenue record exists, but finance hasn’t sent it to the GL.
- Is it posted? Finance has already exported or posted it, and the amount may already be in your accounting system and on a bank deposit.
If you can’t tell from the record, ask whoever runs your GL posting. Guessing here is how deposit totals stop matching.
Still in an uncommitted batch: just fix the row
This is the easy case. Open the batch, correct the amount on the row, and make sure the batch’s projected total still matches the deposit slip or the adding-machine tape. Then commit as usual. Nothing downstream has seen the wrong number, so there is nothing to unwind.
This is also the strongest argument for entering checks in batches rather than directly on the record: a second person can compare the batch total to the physical deposit before anything becomes permanent.
Committed but not posted: edit the payment
Once a payment is committed but not yet posted, you can generally edit it on the revenue record, including the amount and how it’s applied. A few things to watch:
- Application splits. If the check pays a membership plus a donation, changing the total means you also have to decide which piece absorbs the difference. Fix the splits deliberately; don’t let one line quietly balloon.
- Designations. A corrected gift amount may need to be re-split across designations or funds.
- Benefits and membership level. If the corrected amount drops a member below their level’s price, the membership itself may no longer be right. Sort that out with your membership lead before saving.
- Acknowledgments. If a receipt or tax letter already went out with the wrong amount, flag the record so a corrected acknowledgment is sent. A donor’s tax receipt should match what they actually gave.
Already posted: expect an adjustment, not a clean edit
Posted revenue is where people get stuck. Once a payment has gone to the GL, Altru is designed to protect that history rather than let you overwrite it. In practice, changing a posted amount typically produces an adjustment that then needs to be posted itself, so the GL sees both the original entry and the correction. Exactly how your database handles this depends on your GL setup and security rights, so test the change in a sandbox or a low-stakes record first, or confirm the expected behavior with Blackbaud support before touching a large gift.
Before you change anything on a posted payment, loop in finance. They’ll want to know:
- The original amount, the corrected amount, and the date of the original deposit.
- Whether the error is an entry mistake (the bank deposited $250, Altru says $25) or a real change (the check bounced, or the donor stopped payment).
- Which accounting period the correction should land in, especially if the original month is already closed.
That second point matters. An entry mistake means Altru disagrees with the bank and should be corrected to match. A bounced or stopped check means the money never arrived, which is a different transaction. Many organizations handle those by reversing or writing off the original payment and recording the replacement payment separately, rather than editing the amount down to zero. Whatever your finance team prefers, use the same method every time so reports stay consistent.
Leave a trail
Whatever path you take, add a note on the revenue record or constituent record saying what changed, why, who approved it, and when. Six months from now, an auditor or a new development director will look at a payment that doesn’t match the original batch, and that note is the only explanation they’ll have.
Catching these before they happen
Most check-amount corrections come from keying errors that a quick reconciliation would catch. A few habits help:
- Have one person enter the batch and another compare its total to the deposit before committing.
- Build a simple query of checks entered in the last week with amount, check number, and batch, and have finance spot-check it against the bank deposit.
- Restrict who can edit posted revenue in your security roles, so corrections go through someone who understands the GL side.
Quick answers
Can I delete the payment and re-enter it with the right amount?
Sometimes, on unposted revenue, but deleting loses history and can break links to memberships, pledges, or acknowledgments. Editing is usually safer. On posted revenue, check with finance before deleting anything.
Do I need to fix the check number too?
If it was keyed wrong, yes. Finance often matches deposits by check number, so a wrong number causes the same reconciliation headaches as a wrong amount.
