Transfer Matching: Pair Internal Transfers

Turn on the Transfer Matcher so money moving between your own accounts is detected as a pair and tagged on both legs, instead of looking like unrelated income and spending.

4 min read

On this page

Money moved between your own accounts shows up twice: minus $500 in checking, plus $500 in savings. To a budget or P&L that reads as $500 of spending and $500 of income, both wrong. The Transfer Matcher detects these pairs while your data syncs and tags both legs, so downstream reports can recognize (or exclude) them.

There is exactly one Transfer Matcher per workspace — it is a single pairing layer across all the transaction feeds you attach it to, which is what lets it match a leg from one bank feed against a leg from another.

How pairing works#

Two records are paired when all of these hold:

  • Opposite signs — one outgoing, one incoming.
  • Exactly equal amounts — to the cent.
  • Different accounts — a transfer has to leave one account and land in another. (Same-account pairs are matched separately, as reversals.)
  • Dates within the window — 4 days apart by default (banks post the two legs on different days more often than you would hope); configurable up to 14.

Matching happens in two passes. First, records syncing in the same batch are paired against each other, nearest dates first. Then any legs still unmatched are checked against candidates remembered from earlier syncs and other feeds — so a checking feed that syncs Monday and a savings feed that syncs Tuesday still pair up. Unmatched legs are remembered for the window plus a few days of grace, then expire.

When two or more legs could pair equally well (say two $500 moves on the same day), the matcher resolves ties deterministically, so re-syncing the same data always produces the same pairs.

What a match does#

By default the action is Tag (recommended):

  • Both legs get their Type set to transfer.
  • Both legs get the same id written into the Transfer Pair field, so you can line the two rows up in your destination.

Map the Transfer Pair column to see it

Transfer Pair is a regular enrichable field. Add it in your feed field mappings if you want the shared pair id to appear as a column in your sheet, database, or table — two rows with the same value are the two legs of one transfer.

Reversals: the same shape on one account#

A charge and its refund sit on the same account — a reversal, not a transfer. The matcher pairs those too, and labels them differently:

  • Both legs get their Type set to reversal (never transfer), so a report or rule that looks for transfers is not thrown off by refunds.
  • Both legs still share a Transfer Pair id, so you can line them up the same way.
  • Reversals are never suppressed, whatever action you picked. Both legs belong to one account and net to zero there; dropping one side would leave that account's own balance wrong.
  • They use a tighter window — 1 day, or your matching window if you set it lower. Same-account matching gives up the "different accounts" guard, so it does not inherit a 14-day window: without it, an unrelated $50 purchase and $50 refund a fortnight apart would pair.

Turn this off with the Also label reversals checkbox if you would rather refunds stay untouched.

Suppression is opt-in#

Instead of tagging, you can choose to suppress both legs or suppress the outgoing leg only, keeping matched transfers out of the destination entirely.

Suppression removes rows from your synced data

Tagging keeps every record and lets your reports decide what to do with transfers. Suppression means matched rows never reach the destination at all — a false pair would silently hide two real transactions. BankSync never suppresses automatically; choose this only if you are sure your reporting cannot exclude tagged transfers instead. Note that when a leg matches a record synced in an earlier run, the new leg is tagged rather than suppressed — removing one visible half of an already-written pair would read as data loss.

Setting it up#

  1. Create it

    On the Enrichments tab, click "Add an enrichment" and choose Transfer Matcher in the Guard data group. If the option is disabled, your workspace already has one — open it instead.

  2. Set the window

    Keep the 4-day default unless your banks are slow to post; you can widen it to 14 days. Wider windows catch slower transfers but raise the odds of a coincidental match.

  3. Pick the action

    Keep Tag unless you have a specific reason to suppress (see the warning above).

  4. Attach and enable

    In the Dependencies tab, tick the transaction feeds it should watch — attach all the accounts you move money between, since pairing needs to see both sides. Then flip the switch to Enabled.

The Transfer Matcher configuration form: a Matching window (days) field set to 4 with the note maximum days between the two legs of a transfer, 1 to 14 days, and a When a pair is found section with Tag (recommended) selected and Suppress both legs and Suppress one leg options, each carrying the warning that suppression permanently excludes records from your destination.
The Transfer Matcher: the 4-day window and the Tag action selected over the suppression options.

Expectations and edge cases#

Credit card payments

A card payment is a transfer to most people, but v1 matches exact amounts only — a partial payment (paying $400 against a $512 statement) will not pair. Exact-amount payments pair fine when both accounts are connected.

False-pair guards

The rules are deliberately strict — exact amounts, opposite signs, different accounts, dates in the window — because a wrong pair is worse than a missed one. Coincidences of the same amount in the window can still pair; the shared Transfer Pair id makes any such pair easy to spot and fix in your destination.

Records with no amount, a zero amount, or no account identity are skipped. Both accounts must be connected to BankSync — the matcher cannot pair against an account it never sees.

Use this page with your AI assistant

Every BankSync doc is available as plain Markdown for agents and LLMs.