Entering gifts one record at a time is slow and hard to check. The Gift Entry grid takes a stack of checks, lets you key them as rows, and will not let you post until what you entered matches what you said was in the envelope. The balancing is the point.
Batch date, deposit reference, and what you expect to find
Key the gifts as rows, one line per check
Entered count and total against expected — variance must be zero
Engagements created, batch closed
Fix the rows, or fix the expected figures
The Gift Batch is a control record. Before entering anything you tell it what you expect — how many gifts and how much money. As you key rows, it keeps a running count and total, and the difference between the two pairs is the variance.
What you counted before you started keying — the number of checks in the pile and what they add up to. Fill these in honestly at the start. Adjusting them later to match what you typed defeats the entire control.
What is actually in the grid right now. These update as you work, so you can see the batch filling up and catch a wrong amount long before you get to the end.
The gap between expected and entered, and a flag that turns on when there is none. A batch that balances is one where the money in the system matches the money on the desk.
Open while you are working, In Review when it is ready for a second pair of eyes, Posted once it is committed. The deposit reference ties the batch to the actual bank deposit, which is what makes reconciliation possible later.
Work down this list. It is nearly always one of the first three.
| Symptom | Usual cause |
|---|---|
| Total is out, count is right | One amount keyed wrong — scan for an odd figure |
| Count is out by one | A row was missed, or one got entered twice |
| Both out by the same gift | A check in the pile was never keyed |
| Out by a round amount | Transposed digits, or a decimal in the wrong place |
| Nothing looks wrong | Recount the physical pile — the expected figure may be the error |
Changing the expected total so it matches what you keyed makes the variance disappear and the problem stay. The batch exists precisely to catch the case where the system and the deposit disagree. If they disagree, that is information — find out why before you post.
Up to the moment you post, the batch is a working area and rows can be changed freely. Post it and the gifts become real Engagements on real donor records. Get the batch right while it is still open — that is much easier than correcting posted records afterwards.
Batch entry is exactly where duplicate records get made, because you are moving fast and the name on the check is rarely exactly the name in the system. Match to the existing person wherever one plausibly exists. Ten seconds here saves somebody an afternoon of merging later.
Keep batches lined up with actual deposits rather than with days or with whoever happened to be at the desk. When finance asks why the bank shows one figure and Salesforce another, a batch that maps to a single deposit reference answers the question in seconds.