Multi-Account Forensic Tracing

Multi-account tracing is the workflow forensic accountants and fraud examiners use when an investigation spans several bank or credit card accounts — often across different holders, entities, or institutions — and the question is "how did money move between these parties?" This article covers the Accounts tab and the related Flow of Funds filters and exports that make that question answerable in DocuClipper.

What "multi-account tracing" means in DocuClipper

One investigation lives in one project. Inside that project you upload every relevant statement — the subject's checking and savings, a related LLC's operating account, a custodial account, a counterparty's statements obtained via subpoena, etc. DocuClipper deduplicates the underlying accounts so that:

N statements for the same account collapse to one Account row.
The same masked account number at two different banks stays as two distinct accounts (the dedupe key is account number + routing number + institution, scoped to the project).

The result is an Accounts list — one row per real-world account — that you can tag, filter, and trace against.

Tagging accounts: the holder workflow

Open the Accounts tab inside your Bank/CC project. Each row is one account, with the institution, masked number, and statement count.

For a forensic investigation, the most useful pattern is to tag every account with a holder and a subject_role:

holder — the human-readable owner. Use canonical labels (Subject A, Subject B, Acme LLC, Custodian — Wells Fargo). Pick the labels once and use them consistently across every account; the filter chips key off the exact string.
subject_role — what the holder represents in your engagement (subject, related_entity, counterparty, custodian, nominee).

Other suggested keys (the value field autocompletes from prior entries):

account_type — checking, savings, operating, trust, escrow, credit_card
custodian — for accounts held by a fiduciary
currency — for cross-border work

Free-form keys also work. Anything you tag is available as a Flow of Funds filter chip and is included as a column in the XLSX export, so be deliberate — a tag taxonomy you'll reuse beats one-off scribbles.

You can also rename the display name inline. The display name is what shows up on the Sankey diagram and in the export, so rename to whatever your report will read best (Subject A — Chase ...4521).

Tracing flows: filtering by holder or role

Open Advanced Analysis → Flow of Funds. The new filter chips at the top of the chart let you scope by any account attribute or by a specific account.

A typical "Subject A → Subject B → next hop" trace:

Apply holder=Subject A. The Sankey now shows only flows where Subject A is on one side.
Click the link that runs to Subject B on the chart. DocuClipper appends holder=Subject B as a second filter and updates the table below the chart in sync.
The URL bar updates with every filter — copy it to share the exact view with a partner or attach to your work paper.

Filters combine. subject_role=subject plus account_type=operating is "the operating accounts of any of my subjects." holder=Subject A plus a specific counterparty account gives you the dyad view.

Clicking any node or link on the Sankey adds the corresponding filter rather than navigating away. The chart, the transaction table, and the URL stay in sync so the analysis is always one click away from a screenshot you can drop in a report.

The Flow of Funds export

Click Export flow of funds to download a multi-sheet XLSX scoped to whatever filters you currently have applied. Three sheets, each meant for a different part of a forensic deliverable:

Sheet 1 — Transactions

Every transaction that survives the current filter, one row each. In addition to the usual fields, each row carries:

account_holder and account_institution — copied from the tags on the source account, so the sheet is self-contained without a lookup.
transfer_match_id — non-empty when the transaction is part of a detected inter-account transfer. Two rows sharing the same transfer_match_id are the matched debit/credit pair.
transfer_counterparty_holder, transfer_counterparty_institution, transfer_counterparty_account — for transfer rows, who the money moved to or from.

This is the "show me every underlying transaction with full provenance" sheet. Drop it into evidence or pivot it however your case requires.

Sheet 2 — Between accounts

The aggregate view that backs the Sankey. One row per source/destination pair, with an edge_type column:

transfer — money moved between two accounts that are both in the project.
inflow — money came into an in-project account from a counterparty whose statements aren't in the project.
outflow — money left an in-project account to an external counterparty.

Use this sheet to reproduce the diagram in a written report and to highlight the largest dyads at a glance.

Sheet 3 — Account totals

One row per account with period_start, period_end, total_inflows, total_outflows, net, and transaction_count. The summary your reader wants on page 1 of the report: which accounts moved how much money over what window.

Edge case: the same real account showing up twice

If the same real-world account appears with slightly different account numbers across statements — common when a bank reformats statements mid-year, masks differently, or you have a mix of paper and electronic statements — DocuClipper may create two Account rows because the dedupe key sees them as different.

When this happens you have two options:

Rename and tag both rows with the same holder and subject_role. The Flow of Funds filters key off the tags, not the account row identity, so a holder=Subject A filter pulls both rows together for analysis and export. This is the recommended workaround today.
Wait for the manual-merge UI, which is on the roadmap but not yet shipped. When it lands you'll be able to collapse two Account rows into one canonical row from the Accounts tab directly.

For now, option 1 is the right move — it produces correct totals on Sheet 3 (each row is still its own account, which often matches reality more closely than the user assumes) and correct holder-level aggregates everywhere else.