We have the same problem. I have run proof in the past and have made these errors. Even though you are repeating the amount in your head, your fingers do exactly what they did for the first item. Our encoding errors are usually putting too many or too little zeros on items. We had one the other day where a customer's check and deposit were encoded as $1,000 and they were actually $10,000.
We too segregate some single debit/credit transactions but these are mostly daily Fed Funds, correspondent bank transfers, etc. and we run all debits then balance to all credits. While this has helped lessen G/L errors it has not with customer transactions. Not much you can do about those. The best solution to this was the proof method - now discarded - where you balance proof debits and credits totals to each teller's individual batch totals. Now you just proof each transaction instead of batch totals. A lot less time consuming but this leaves open a larger window for encoding errors.
Previous Thread
Index