How to trace transfers between accounts across several statements

You have six months of statements for four accounts and a 12,500.00 debit on 14 March that has to have landed somewhere. The statement that shows the money leaving says ONLINE TRANSFER TO XXXXXX8842 and nothing more. The account you suspect received it is at another bank, and it shows a credit the following day, for a slightly smaller figure, described only as DEPOSIT. Neither document references the other, and neither will, because two banks are describing the same movement from opposite sides, each of them for its own records rather than for yours.

Tracing transfers between accounts is therefore not a text search. It is an amount and date problem, run over rows from every account at once, with the descriptions demoted to a confirming check rather than the thing you start from.

Why description matching fails

Narration is the least reliable field on a bank statement, and it fails in specific ways rather than randomly.

• Only one side names the transfer. Outgoing entries often carry a destination reference; incoming entries frequently carry nothing beyond a generic credit label and the sender's name as the bank recorded it.
• The counterparty is masked. Account numbers appear partially redacted, and the visible digits differ between institutions. A trailing 8842 on one statement and a leading 4419 on another can describe the same account without sharing a single character.
• The field is truncated. Description columns are fixed width. A reference that carries the whole meaning is often cut off at the column boundary, or wrapped onto a second line that a careless extraction drops entirely.
• The same movement gets different verbs. Transfer, payment, debit memo, internal funds movement and withdrawal all cover the same event depending on the bank and the channel used.

Search the text and you find only the transfers that happened to be labelled helpfully. Those are not a random subset of the transfers in the account. The rows described as nothing more than DEPOSIT are exactly the ones a trace has to account for.

Build one table before you match anything

Matching across accounts requires the accounts to be in one place, in one shape, with the source of every row preserved. That means a single workbook where each row carries the account it came from, a date in one consistent format, a signed amount, the description as printed, and the running balance.

The account identifier column is the one people leave out and regret. Once rows from four accounts are merged without it, a 4,000.00 credit is untraceable to the account that received it, and the merge is not reversible. Carrying it from the start is the whole basis for combining multiple accounts into one workbook without destroying what makes the rows useful.

Sign convention has to be settled once, too. Some statements use separate debit and credit columns; some use a single signed column; UK statements often mark amounts DR and CR instead. Pick one representation, apply it to every account, and record which one you chose. A transfer is a pair of rows with opposite signs, so a mixed sign convention silently hides half of the pairs you are looking for.

The matching method

1. 1

   Normalise every account into the canonical columns

   Convert each statement so date, description, signed amount, running balance and account identifier are present and consistent across banks.
2. 2

   Verify each account before you compare accounts

   Confirm each converted statement reconciles to the closing balance printed on its own source document. A trace built on rows that do not tie to their statement inherits every error in them, so verifying a converted statement belongs before the analysis rather than after it.
3. 3

   Sort by absolute amount

   Order every row in the combined table by the unsigned amount, so rows of similar value sit together regardless of which account they came from.
4. 4

   Filter each amount group to opposite signs in different accounts

   A candidate pair is one debit and one credit in two different accounts, at the same amount or with the credit slightly smaller.
5. 5

   Widen from an exact amount to an amount band

   Where fees are taken in transit the receiving figure is short. Test the exact amount first, then a band running from the sending amount down by the largest charge your banks levy. Record the band you used.
6. 6

   Apply a date window of one to three business days

   Same day for internal transfers between accounts at one bank. One to three business days for interbank movements, longer across a weekend or a public holiday.
7. 7

   Confirm against the running balance on both sides

   Check that the debit reduces the sending balance by the sending amount and the credit raises the receiving balance by the receiving amount. Two independently reconciling balances are harder to explain as coincidence than a matching pair of figures.

A worked pair

Four rows out of the combined workbook. Two come from a current account ending 4471, and two from a savings account ending 8842 held at a different institution. That second fact carries the whole example: the movement is interbank, so it settles the following business day rather than the same day, and a charge can be taken out of it in transit. The narration does not tell you any of that. A sending bank prints the last four digits of the destination account whether or not it holds that account, so ONLINE TRANSFER TO XXXXXX8842 is equally consistent with a movement inside one bank and with the interbank movement this actually is, which is the reason the method above leans on amounts, dates and balances instead.

Each row names the account it belongs to, and each balance belongs to that account alone. There is no single chain running down the table, because there are two accounts in it.

Account 4471 opens at 18,420.00 and the debit of 12,500.00 takes it to 5,920.00. Account 8842 opens at 2,110.00 and the credit of 12,475.00 takes it to 14,585.00. The two figures differ by 25.00 because the wire fee came out of the principal while the payment was in transit: 12,500.00 less 25.00 is 12,475.00. Neither statement prints that fee as a row. The sending account shows the gross debit, the receiving account shows the net credit, and the 25.00 exists only as the difference between them.

An exact amount match would have missed this pair. What identifies it is a date window of one business day, which is what an interbank movement takes, opposite signs in two different accounts, and a receiving figure inside a band running from 12,475.00 to 12,500.00, wide enough to absorb the wire charges these two banks apply and narrow enough that nothing else in either account falls inside it. Both running balances then move by their own amounts, and each one reconciles against the closing figure its own bank printed.

None of that is checkable without the account column. Strip it out and the 12,475.00 credit becomes a number in a merged list with no account behind it, and the 25.00 has nothing left to be a difference between.

Where the method needs adjusting

Fees taken in transit. International wires and some same-day payments arrive net of a charge levied by an intermediary, so the receiving amount is short by a figure that appears on neither statement as its own line. Test candidate pairs at the exact amount, then across a band running from the sending amount down by the largest charge your banks apply. Some banks do instead debit the fee separately, leaving the principal intact on both sides, so check which pattern each account follows before you set the band.

Split and aggregated movements. A single 9,000.00 debit can arrive as 5,000.00 and 4,000.00 two days apart. Several small debits can arrive as one credit. Match on subtotals within the date window when the one-to-one pass leaves an unexplained debit.

Currency conversion. A transfer between accounts in different currencies matches on neither amount. What you have instead is a date window, a direction, and a rate that should be consistent with other conversions in the same period. Treat these as candidates requiring the bank's own advice or confirmation, not as arithmetic matches.

Round-number collisions. In an account with regular 500.00 and 1,000.00 movements, an amount and date match means very little on its own. Require the balance confirmation on both sides before reporting the pair, and say plainly in any summary how many pairs rest on a round figure.

Pending and posting dates. A statement shows the posting date. The movement may have been initiated days earlier. Widening the window helps, but it also raises the false-pair rate, so widen it deliberately and record the window you used.

Reporting the result honestly

A traced pair establishes that a debit of a given amount left one account and a credit consistent with it arrived in another within a plausible window. It does not establish the purpose of the movement, who instructed it, or whether the money belonged to the person who moved it. Those are questions for other evidence.

The rows underneath the trace need their own statement of limits, because every pair inherits whatever is wrong with them. Two checks are worth naming separately, because a report that calls them both reconciliation overstates one of them. Comparing an account's opening figure plus the sum of its movements against the closing balance the bank printed tests a whole period against a single number, so any two errors that cancel pass it: a dropped row and a duplicated row of the same value leave the period tying exactly, and the dropped row may be the 12,475.00 credit the trace is looking for.

The stronger check runs row by row, each printed balance plus the next row's amount against the next printed balance. It is what gives step seven its force. A 12,475.00 read as 12,745.00 fails on the row it sits on, and a rebuild from the opening figure stays 270.00 adrift until something cancels it, so the figure that put a pair inside the amount band cannot be a misreading that nothing objected to. The same check catches the dropped row, because the row after the loss fails its own equation. Where a statement prints no running balance the row by row check does not exist and neither does step seven, which is a limit worth stating plainly rather than leaving the reader to assume every pair was balance-confirmed.

What no arithmetic check reaches is the date column, the narration and the counterparty, which is a large part of what a trace turns on. A debit posted on 4 March but read as 14 March reconciles perfectly and puts a genuine pair outside whatever window you set. A row for 0.00 moves no balance and is tested by nothing. A balance column misread in a way that agrees with the amount printed beside it reconciles against itself. So a reconciling account is not an account proved right, and it is not an account proved complete: say in the report which checks were run and which errors they cannot reach.

Keep the trace reproducible. Record the date window, the amount band, the sign convention, and which pairs were confirmed against running balances rather than matched on amount alone. Anyone who wants to test your work should be able to run the same rules over the same converted rows and land on the same pairs, and the underlying statement documents have to remain available beside the workbook so they can. The same reproducibility standard applies to any financial record produced in litigation discovery, where the party on the other side is entitled to run your method and see whether it lands where you said it did.

Where a trace is going to be relied on in a dispute, the method you used is as much a part of the work product as the pairs it found. Recording it as you go is the practical half of keeping converted records defensible.