Forensic Accounting with Bank Statements: A Practical Intro

TL;DR: Forensic analysis of bank statements starts with turning every statement into one clean, verified transaction database, with each row traceable back to its source page. From there, the work is tracing: following funds between accounts, summarizing who money went to and came from, and flagging patterns such as round-number transfers, cash activity and payments to unexpected parties. Document every step so someone else can reproduce your numbers. This is an introduction to the method, not legal or professional advice.

Forensic accounting covers a lot of ground: fraud investigations, disputes between business partners, insurance claims, divorce cases with complex finances, and internal reviews when money goes missing. Most of it rests on the same foundation: bank statements, lots of them, analyzed carefully enough that the results stand up to scrutiny.

We're not forensic accountants, and this isn't a substitute for one. But we work with the people who are, and the first stage of their work is exactly what SheetStatement does: turning stacks of PDFs into reliable data. This article explains the method in plain terms, for small firms taking on their first engagement of this type, bookkeepers asked to help, and anyone who wants to understand what the analysis involves.

The standard is different

Ordinary bookkeeping tolerates small shortcuts. If you miscategorize a coffee, nobody minds. Forensic work is different in three ways:

1. Completeness matters. A missing month or a dropped transaction can be the thing that matters most.
2. Traceability matters. Every number in your report should be traceable to a specific line on a specific page of a specific statement.
3. Reproducibility matters. Another professional, often working for the other side, may redo your work. They should get the same numbers.

Everything below follows from those three principles.

Step 1: Inventory the source documents

Start by listing every statement you have, for every account:

Doc ID	Bank	Account	Period	Pages	Source	Received
D001	Bank A	Checking ...4821	2025-01	4	Client	2026-09-12
D002	Bank A	Checking ...4821	2025-02	3	Client	2026-09-12
D003	Bank B	Savings ...1190	2025-01	2	Subpoena response	2026-09-20

Record where each document came from. Statements produced directly by a bank in response to a formal request carry more weight than copies provided by a party, and the distinction can matter later.

Then check continuity. For each account, every statement's closing balance should equal the next statement's opening balance. Gaps mean missing statements; list them and request them. Our guide to getting old bank statements covers what banks typically provide.

Keep the source files untouched, ideally in a read-only folder, and record a file hash if your work may end up in court. Work only on copies.

Step 2: Build the transaction database

Convert every statement to structured data. For a few statements, manual entry is possible; for hundreds, it isn't, and manual entry introduces errors. Tools like SheetStatement extract the transactions and check each statement's rows against its opening and closing balances, which gives you a completeness check on every document. For scanned or photocopied statements, see our notes on OCR accuracy.

Whatever tool you use, the database should have these columns:

• Row ID: unique, stable identifier.
• Doc ID and page: where the row came from.
• Account.
• Date (posting date, and transaction date if shown).
• Description, exactly as on the statement.
• Amount, signed: money in positive, money out negative.
• Running balance, where the statement shows one.

Add analysis columns later, never overwriting the source columns: counterparty, category, flags, notes.

Step 3: Verify the data

Before any analysis, prove the database is complete and accurate:

1. Per statement: opening balance + sum of amounts = closing balance. Any difference means an extraction error or a missing row.
2. Running balance: where the statement prints a balance on each line, recompute it and compare. This pinpoints errors to a single row.
3. Spot-check: compare a sample of rows against the PDFs by hand, and record that you did.

Document the verification in a sheet of its own. If someone challenges the data, this is your answer.

Step 4: Identify counterparties

Bank descriptions are messy: the same payee appears with different reference numbers, abbreviations and prefixes. Create a counterparty column that normalizes them:

Description	Counterparty
ONLINE TRANSFER TO SAV XXXX1190 REF 88213	Own: Savings ...1190
ZELLE TO J SMITH 0412	J Smith
ZELLE PAYMENT TO JOHN SMITH	J Smith
ACH DEBIT ACME SUPPLY CO	Acme Supply Co

A mapping table with lookup formulas does most of the work; our article on Excel formulas to categorize transactions shows the technique. Review the unmapped remainder by hand.

The most important category is own accounts. Transfers between the subject's own accounts aren't income or spending; they're money moving around. Identifying them correctly is the basis for tracing.

Step 5: Trace funds between accounts

For every transfer out of one account to another account in the data set, find the matching transfer in: same amount, same or nearby date. Give each matched pair a shared link ID.

In Excel, a helper column can suggest matches:

=XLOOKUP(-[@Amount], Data[Amount], Data[Row ID], "no match")

That finds a row with the opposite amount. Refine it by also requiring a different account and a date within a few days, using FILTER on newer Excel versions. Review suggested matches manually; equal amounts aren't proof of a link.

Transfers out with no matching transfer in are important: they go to accounts outside your data set. List them by destination. They may point to accounts you haven't been given.

Step 6: Summarize the flows

With counterparties and links in place, PivotTables answer the core questions:

• Sources of funds: total money in by counterparty, by period.
• Uses of funds: total money out by counterparty, by period.
• Net flows between the subject and each counterparty.
• Balances over time, per account and combined.

A sources-and-uses summary is often the centrepiece of a report: where the money came from, and where it went, for the period in question.

Step 7: Look for patterns

Patterns aren't proof of anything; they're leads that deserve explanation. Common things analysts look at:

• Round-number transfers, particularly repeated ones. =MOD(ABS([@Amount]),100)=0 flags multiples of 100.
• Cash activity: deposits and withdrawals, their frequency and size, and any clustering just under reporting thresholds that apply in the jurisdiction.
• New counterparties appearing around key dates.
• Changes in behaviour: spending or transfers that shift sharply at a particular point.
• Payments to related parties: family members, connected businesses.
• Rapid in-and-out movements, where money arrives and leaves within days.
• Gaps: periods with no activity on an account that's otherwise busy.

Every flagged item should come with its row IDs, so a reader can go straight to the statement page.

Handling credit cards and loans

Credit card statements often matter as much as bank statements. They show what money was spent on, which a bank statement doesn't: the bank shows only "Payment to card ...7734". Bring card statements into the same database, with the card as its own account, and link the payments from the bank account to the payments received on the card, exactly as you would link transfers between bank accounts. Then the uses-of-funds summary can go one level deeper, from "paid to card" to the merchants behind it. Our credit card statement converter handles card layouts.

Loan statements work the same way: drawdowns appear as money in on the bank account, repayments as money out. Linking them keeps a loan from looking like income.

Cash: what you can and can't see

Cash is where bank statement analysis runs out. You can see cash going into an account and cash coming out, but not what happens to it in between. Analysts usually:

1. Total cash withdrawals and deposits by month.
2. Compare withdrawals with known cash needs, such as a cash-based business's float.
3. Look for deposits that roughly mirror earlier withdrawals, which may indicate cash moving between accounts or people.
4. Note clearly in the report that cash use beyond the account isn't visible.

Being explicit about this limitation is part of doing the work properly. Overstating what statements show is a common criticism of amateur analysis.

Presenting the findings

Reports built on bank statement analysis tend to work best when they're layered:

• Summary: the answer to the question you were asked, in a few sentences.
• Key schedules: sources and uses, traced transfers, flagged transactions, each with row IDs.
• Method: how the data was obtained, converted and verified.
• Limitations: missing documents, illegible items, assumptions.
• Appendices: the full transaction database, or a reference to it.

Charts help readers who aren't accountants. A monthly balance chart for each account, or a simple diagram of flows between accounts and major counterparties, often communicates more than pages of tables. Keep the underlying numbers alongside so every chart can be checked.

Common mistakes

• Analyzing before verifying. An extraction error discovered late undermines everything built on it.
• Overwriting source data while cleaning descriptions. Keep the original description column intact.
• Treating equal amounts as proof of a link. Coincidences happen, especially with round numbers.
• Ignoring own-account transfers, which inflates both income and spending.
• Not recording judgments. If you can't explain why a row was classified a certain way, someone else will question it.

Step 8: Document everything

A forensic analysis should be reproducible. Keep:

• The document inventory with sources and dates received.
• The verification sheet.
• The counterparty mapping table.
• Notes on every judgment: why two rows were treated as a linked pair, why a payee was classified as a related party.
• A list of limitations: missing statements, illegible pages, assumptions.

Many practitioners keep the database in a format that preserves history, or at least save dated versions, so changes can be explained.

A worked example

A small firm is asked to analyze a business owner's accounts in a partnership dispute. The question: did the owner divert business receipts to personal accounts?

1. They inventory 72 statements across three accounts (business checking, personal checking, personal savings) for two years. Two months of the savings account are missing; they request them.
2. They convert all statements and verify each against its balances. Every statement reconciles.
3. They map counterparties. Transfers between the three accounts are tagged as own-account movements.
4. They trace business-to-personal transfers. Most are regular, similar amounts on the same day each month, consistent with the owner's agreed drawings.
5. A sources-and-uses summary of the business account shows customer receipts by month. In four months, several large customer receipts are missing compared with the invoicing records the firm was given.
6. They check the personal account in those months and find deposits from the same customers.
7. They document the specific rows, statements and pages, and note the limitation that they haven't seen the customers' own records.

The report doesn't conclude that anything improper happened; that's for the people deciding the dispute. It sets out the facts the statements show, precisely and traceably.

When to bring in a specialist

If the matter involves potential fraud, litigation, criminal allegations or large sums, involve a qualified forensic accountant and the relevant lawyers early. The method above is the core of the work, but specialists bring experience in evidence handling, expert reports and testimony that a general practice usually doesn't have.

Keeping scope under control

Bank statement analysis can expand endlessly: one more account, one more year, one more counterparty to research. Agree the questions and the scope in writing at the start: which accounts, which period, and what you're being asked to determine. When new leads appear, such as transfers to an account outside the data set, note them and raise them with whoever instructed you, rather than quietly widening the work. It keeps costs predictable and the report focused.

Tools: spreadsheets and beyond

Excel handles tens of thousands of rows comfortably and is what most small engagements use. For larger data sets, practitioners use databases, Power Query, or analysis tools like Python. Whatever you use, the principles stay the same: complete source data, verified extraction, traceable rows, documented judgments.

Troubleshooting the analysis

Transfers won't match. International transfers and some card payments arrive for a different amount than they left with, because of fees or exchange rates. Allow a tolerance in your matching (for example within 1% or a fixed fee amount) and record the difference as a fee or exchange item.

Counterparty names are inconsistent. One person may appear under a full name, initials, a nickname in a payment reference, or a business name. Build the mapping table from the most distinctive part of each description, and keep a note of the evidence for each mapping.

Statements from different banks use different dates. Some show transaction dates, some posting dates, some both. Choose one for analysis (usually posting date, because it matches balances) and keep the other in a separate column.

The volume is overwhelming. Start with the question. If the question is about one counterparty or one period, filter to that first and expand only when the facts require it.

Your totals don't match the statements. Stop. Go back to the verification sheet and find the statement that doesn't reconcile before doing anything else.

A mini checklist for each engagement

1. Questions and scope agreed in writing.
2. Document inventory with sources and continuity checked.
3. Every statement verified against its balances.
4. Counterparty mapping documented.
5. Transfers traced and linked, unmatched transfers listed.
6. Findings tied to row IDs and statement pages.
7. Limitations stated.

A second worked example: an employee expense review

A small company suspected an employee had been using a company card for personal purchases. The bookkeeper converted 18 months of card statements, mapped merchants into categories, and compared them with submitted expense claims. Most charges matched receipts. A cluster of 34 charges at two online retailers, all on weekends, had no claims or receipts. The schedule of those charges, with dates and statement pages, went to the company's lawyer. The analysis didn't decide what happened; it made the facts clear.

FAQ

What do forensic accountants look for in bank statements?

Typically, the sources and uses of funds, transfers between accounts, payments to related parties, cash activity, round-number or repeated transfers, and changes in behaviour around key dates. Each finding is tied back to specific statement lines.

How do you trace money between bank accounts?

Match transfers out of one account to transfers into another by amount and date, give each pair a link ID, and list transfers with no match. Unmatched transfers often point to accounts outside the data set.

Can I use Excel for forensic analysis of bank statements?

Yes, for most small and medium engagements. Keep source columns untouched, add analysis columns alongside, verify every statement against its balances, and document your steps.

How do I make sure no transactions are missing?

Check that statements chain (each closing balance equals the next opening balance) and that each statement's transactions sum to the difference between its opening and closing balances.

Is a pattern in bank statements evidence of fraud?

No. Patterns are leads that need explanation and context. Conclusions are for qualified professionals and, where relevant, courts.

How long does a bank statement analysis take?

It depends on the volume of statements and the questions asked. Conversion and verification are much faster with automated extraction; counterparty mapping, tracing and documentation take most of the time.