Skip to main content

Find transfers & manual linking

When money moves between two of your family's accounts, your imported statements show it twice — a debit in one account and a credit in the other. If both rows stayed as "expense" and "income", your reports would be inflated on both sides. Linking them as a transfer tells Sahidha it's internal movement: it disappears from Income & Expenditure and both account balances stay right.

How Find transfers works

Finance → Find transfers scans your live, unlinked entries and suggests pairs. A pair must always satisfy the basics — opposite directions, on two different accounts, same amount (±₹1), dates within the window you choose (default 1 day; widen it for cheque clearing). On top of that, each pair is scored by the strongest signal found:

SignalConfidenceExample
The same reference number on both narrations (UPI RRN, IMPS/NEFT/RTGS UTR)High…/512300011122/… on both legs
One narration names the other account's last 4 digitsHigh"TPT TO XX1234" ↔ the credit lands in account ····1234
The same UPI handle on both legsHighraj@okhdfc appears on both — a self transfer
A shared meaningful word (a name, not rail-noise like "NEFT"/"TRANSFER")Medium"RAMESH" on both legs
Amount + date onlyLowworth a look, verify before linking

Two things are filtered out for you:

  • UPI shop payments: an amount-and-date-only coincidence where either leg is a UPI payment to some third party (a UPI handle or merchant marker in the narration) is not shown — those are purchases, not transfers. Genuine UPI self-transfers still surface, because they share the reference number or handle.
  • Overlaps: each entry appears in at most one suggested pair. If several rows could match, the best one is shown and the others are available via the pair's "alternatives" picker.

High-confidence pairs come pre-ticked. Review the list, untick anything doubtful, and press Link selected. Nothing is ever linked without that click, and a wrong link is always reversible (see below).

When does a pair say "cross-member"?

Whenever the two accounts belong to different people — e.g. money from Raj's HDFC account landing in Pooja's ICICI account. It's still linked as a transfer (no income, no expense), but because value moved between two people, Sahidha also raises a cross-payment IOU: a record that Raj paid Pooja, visible on the Cross-payments screen, where it can be acknowledged or settled later. Transfers between your own accounts (or your own entity's, like your HUF) never raise an IOU.

Linking a transfer manually

For a one-off the scanner didn't catch (or that you spot while browsing):

  1. Open the entry from any list (Transactions, an account statement…).
  2. In the edit panel, find the Link / convert section and choose Transfer to account.
  3. Pick the account on the other side and press Convert.

Two cases:

  • The other leg is already imported — Sahidha finds the matching opposite row on that account (same amount, nearby date) and joins the two existing rows into one transfer. Nothing is double-counted.
  • The other side isn't imported (or the account has no statements — a loan given to an acquaintance, for example) — Sahidha creates the missing leg on the chosen account so its balance moves correctly.

Recording a brand-new transfer (both legs at once) is simpler still: New entry → Transfer, pick direction and both accounts.

Open either leg and press Unlink transfer — the two rows revert to independent entries (and any IOU raised by a cross-member link is withdrawn). Nothing about the original bank rows is lost, so you can re-link differently.

Better matches, automatically

Since narrations often carry the destination account's last digits, keeping each account's number recorded (only the last 4 are ever stored) directly improves match quality.