# Transposition Error in Bank Reconciliation: Find It - Author: PreciseBankFlow (https://www.precisebankflow.com) - Published: 2026-10-06 - Updated: 2026-10-06 - Category: Finding reconciliation errors - Canonical: https://www.precisebankflow.com/blog/transposition-error-in-bank-reconciliation > How to find a transposition error in a bank reconciliation: the divide-by-nine test, where swapped digits hide and how to confirm the line. A transposition error in a bank reconciliation happens when two digits of an amount are swapped while keying, so 4,562.00 becomes 4,526.00. The unexplained difference then divides evenly by nine. Divide the gap by nine, use the result to guess which digits traded places, and check the likely line against the bank statement or the deposit slip. ## What is a transposition error in a bank reconciliation? A transposition error is an amount entered with two of its digits in the wrong order. On a bank reconciliation it shows up as a difference that no outstanding check, deposit in transit or bank fee explains. The bank recorded one figure, the ledger holds its scrambled twin, and the gap between them is the only symptom. Swaps are almost always made by a person typing. Nobody misreads a whole number; they read it correctly and their fingers deliver the digits out of order. Adjacent digits are the usual pair: 62 becomes 26, 81 becomes 18. Swaps across a gap, such as 503 typed as 305, are rarer but follow the same arithmetic. The error can sit on either side. A bookkeeper can key a check amount wrong in the ledger, and a bank teller can key a deposit wrong at the counter. The second case is a bank error rather than a book error, and it needs a call to the bank instead of a journal entry. ## The divide-by-nine test for a transposed amount The divide-by-nine test checks whether the unexplained difference is a multiple of nine. Any swap of two digits changes an amount by a multiple of nine, so a difference that divides cleanly is a strong hint that you are looking for a transposition. The quotient also tells you how far apart the swapped digits are. Here is a worked example with invented figures. The ledger shows a customer deposit of 4,526.00. The reconciliation is out by 36.00, with the bank side higher. 1. Divide the difference by nine: 36.00 / 9 = 4. 2. The swapped digits differ by four. In the tens-and-units place, that means a pair such as 6 and 2, 7 and 3, or 9 and 5. 3. Scan the ledger for amounts containing 26, 37 or 59 in those places, or their reverses. 4. The 4,526.00 deposit fits. Swap its last two whole digits and you get 4,562.00, which is 36.00 higher. 5. Pull the bank statement line. It reads 4,562.00, so the ledger is wrong. If the quotient is a multiple of 10, the swap sits one place further left. A difference of 360.00 divides to 40, which points to the hundreds and tens digits. The full logic, including differences that divide by nine for other reasons, is in [what a reconciliation difference divisible by 9 tells you](/blog/reconciliation-difference-divisible-by-9). ## Where swapped digits hide in bank and ledger records Swapped digits hide in whatever was keyed by hand. Bank feeds and imported statements rarely transpose, because no one typed them. Start with manual journal entries, handwritten deposit slips, check amounts entered from a check stub, and the opening balance typed in when the books were set up. Some places deserve a look first: - **Deposit totals.** A deposit of many customer checks is often added on a calculator and keyed as one figure. - **Check amounts from stubs.** The person writing the check and the person entering it may be different people. - **Carried-forward balances.** A beginning balance retyped from last month's report can be transposed, and the error then repeats every month. - **Payment batches.** A vendor payment run summarised as one figure can carry a swap that the individual bills do not. The same habit causes trouble outside the bank account. Supplier statements keyed into payables pick up transpositions too, and [automating supplier statement reconciliation](/blog/automated-supplier-statement-reconciliation) removes much of that retyping. ## How do you confirm which transposed line is wrong? Confirm a suspected transposition by comparing the ledger line with its source document, not with your expectation. The bank statement settles what the bank recorded. The deposit slip, check image or invoice settles what the amount should have been. Only when both agree with each other and disagree with the ledger is the ledger line proven wrong. Do not stop at the first candidate. Two different lines can each fit a quotient of four. List every candidate, then check each against its source until one matches exactly. If none matches, the difference may be two errors combined. When the bank's figure is the odd one out, for example the deposit slip says 4,526.00 and the statement says 4,562.00, you have found a bank error. Keep the slip and the statement page, and ask the bank to correct the posting. The reconciliation carries the item as a bank-side adjustment until the correction appears. Once the ledger is proven wrong, correct the original entry if the period is open, or book a dated correcting entry if it is closed. Note the source document on the correction so a reviewer can retrace it. ## When the divide-by-nine test misleads on transposition errors The divide-by-nine test is a hint, not a proof. Plenty of differences divide by nine without any swapped digits, and some genuine transpositions are hidden because a second error changes the total. Treat a clean quotient as a reason to look at certain lines first, never as a reason to stop looking. Three cases trip people up: - **Slide errors.** A misplaced decimal also gives a multiple of nine: 450.00 keyed as 45.00 leaves 405.00, which is 9 x 45. The pattern is different, and [slide error accounting](/blog/slide-error-accounting) explains how to tell the two apart. - **Two errors at once.** A transposition plus an omitted fee produces a total that may not divide by nine at all. Clear the obvious items first, then retest what is left. - **Coincidence.** Any difference has a one-in-nine chance of dividing evenly. A missing 18.00 bank charge passes the test and has nothing to do with swapped digits. A statement that has been extracted line by line makes the search faster, because every bank figure is already in a list you can sort and compare. [PreciseBankFlow](/) foots each statement and lists the differences it finds, so the candidates for a swap are the lines left on that list.