For forensic accountants and investigators
Bank statement converter for forensic accounting
An investigation is only as sound as the transaction data under it. Get years of statements into one dataset, know where it is incomplete, and trace every row to the printed line.
- Years of statements into one dataset
- Errors located to the row, not the total
- Provenance for every transaction
- Nothing silently corrected
The short answer
How forensic accountants build a dataset from bank statements
A forensic accounting bank statement converter turns statements across accounts, entities and years into consistent transaction data, checks each statement against its own printed balances, and keeps a link from every row to the line on the page it came from. The output is a dataset you can combine and interrogate in Excel or your analysis tool, with a record of what was verified.
Data entry has long been the slow part of a forensic engagement, and it is also where errors are introduced that cost the most later. A dropped row breaks a chain of transfers; a misread amount creates a discrepancy that takes days to chase before it turns out to be an artefact of the transcription. Generic extraction tools speed the work up without telling you where they went wrong.
VouchRow narrows that risk: the checks localise errors to the row, the source link makes each one quick to resolve, and the export records the scope of what was checked. The investigation itself stays with you.
The job
Statements across accounts, entities and periods have to become one dataset you can interrogate — matching transfers between accounts, finding patterns, establishing what moved where and when. The conversion is the foundation, and everything downstream inherits its errors.
Why extraction errors are corrosive here
An investigation reasons about relationships between transactions — a payment out of one account matching a receipt into another, a pattern of amounts, a sequence of dates. A single dropped or misread row does not just make one figure wrong; it can break a chain you were relying on, or manufacture a discrepancy that costs days to chase before it turns out to have been a conversion artefact all along. Both directions waste the same time.
Step by step
Building an engagement dataset
- 1Inventory the statementsList every account, entity and period in scope, and note where statements are missing before conversion begins. Statements with a text layer upload in batches; scans and password-protected PDFs are converted one at a time.
- 2Convert each statement and review the checksRunning balance, page subtotals, opening plus movement against closing, printed totals and transaction count run on every statement. Clear or document each failure against its source line.
- 3Confirm continuity across periodsCompare each statement’s opening balance with the previous closing balance using the Reconciliation sheets. Breaks identify missing periods or pages in what you were given.
- 4Label and exportBulk-label selected rows as your hypotheses develop, such as related-party payments or inter-account transfers, and export to Excel or CSV.
- 5Combine and analyseAppend the exports into one dataset with account and period columns, then run your matching and pattern work in the tools you already use. Keep the Reconciliation sheets with the working papers.
What helps
What this does about it
Errors are localised, not aggregate
Where the running balance breaks, it breaks at the row responsible. That converts "these accounts do not tie out" into "row 47 of the March statement", which is the difference between a day and a minute when a discrepancy turns out to be an artefact.
Exact arithmetic, not floating point
Every amount is an integer number of minor units throughout, so totals across thousands of transactions do not accumulate rounding drift. The tolerance for a reconciliation mismatch is zero rather than a cent, which means a genuine one-cent discrepancy is still visible.
Provenance for every row
Page and line are recorded per transaction and shown on click. A figure in your working papers can be traced to the printed line it came from without going back through the PDFs by hand.
Nothing is silently corrected
Rows that do not reconcile are flagged and left as they were read. No balancing entry is invented, no amount adjusted to make totals agree, and the export carries a note stating what was and was not verified.
Why it works
What a forensic engagement needs from conversion
Errors localised to a row
A broken running balance points to the row responsible, so an extraction error is found in minutes rather than mistaken for a finding.
Provenance for every row
Page and printed line are recorded per transaction and shown highlighted on click, on digital and scanned statements.
Scope of verification recorded
The Reconciliation sheet shows which checks ran, which passed and which the statement lacked data for.
No silent corrections
Rows that fail stay as read and flagged. No balancing entry is invented and no amount adjusted.
Consistent structure across banks
Dates normalised, amounts signed consistently, wrapped descriptions merged, brought-forward balances excluded, whichever bank produced the statement.
Controlled retention
Keep statements for 24 hours, 7 days or 30 days, or store nothing. Nothing is used to train models.
Checked before export
A misread digit is caught on its own row
Every conversion is tested against the statement: the running balance on every row, page subtotals, opening plus movement against closing, the printed credit and debit totals, and the transaction count. When a number does not add up, VouchRow names the row and highlights the line it came from on the PDF.
Arithmetic only: it verifies amounts, balances and totals, not descriptions or dates, and two errors that cancel out would pass. The source-line link covers the rest.
How the checks workRunning balance check
- POS AMAZON MKTPLACE−86.4316,604.12
- CHECK #1042−1,250.0015,354.12
- ZELLE FROM J MORALES+640.0015,994.12
Every row agrees with the balance printed beside it.
One dataset
Years of statements into one dataset
Forensic work rarely concerns one statement. It is several accounts, sometimes several entities, over several years, from banks with different layouts. The first deliverable is a single, consistent dataset, and its quality bounds everything after it.
VouchRow converts each statement into the same structure: date, description with wrapped lines joined, signed amount, and running balance where the bank printed one, with transactions kept in the statement’s date order. Brought-forward balance lines are recognised and excluded rather than appearing as transactions. Export each to Excel or CSV and append them with account and period columns to form the combined dataset.
There is no built-in cross-account matching, anomaly detection or pattern analysis. That is deliberate: the dataset is a foundation for your analysis, not a substitute for it.
- Add account, entity and statement period columns when combining exports
- Keep each statement’s Reconciliation sheet alongside the combined data
- Record any statement that did not reconcile and how it was resolved
- Use bulk labels to mark rows for the lines of enquiry you are testing
Gaps
Finding gaps in the record
An incomplete record is a finding in its own right, and it needs to be identified early. Within a statement, a page of transactions that is missing means opening balance plus movement no longer equals the closing balance, and the statement fails to reconcile. Where a running balance is printed, the break appears at the exact row.
Across statements, balance continuity does the same job: each period’s opening balance should equal the previous closing balance. Laying out the Reconciliation sheets in order gives a quick map of where periods are missing from what was provided.
| Result | Likely cause | Next step |
|---|---|---|
| Running balance breaks at one row | Misread amount or sign, often on a scan | Compare with the source line and correct |
| Opening plus movement does not equal closing | Missing page or rows | Check page sequence; request the full statement |
| Closing does not match next opening | Missing period or statement | Record the gap; request the missing period |
| Only totals checked | Statement prints no running balance | Note the reduced precision of the check |
| All checks pass | Arithmetic consistent | Descriptions and dates still need your review |
Transfers
Transfers, round trips and related accounts
Much of the analytical value is in relationships between transactions: a payment out of one account and its receipt in another, funds cycled through several accounts, payments to related parties. These analyses are sensitive to completeness. A single missing row can break a chain that looked solid, and a single misread amount can make two matching transactions look unrelated.
Because every statement has been checked before it enters the dataset, the matching you do in Excel or your analysis tool starts from data whose arithmetic agrees with the bank’s. Where a statement could not be fully verified, you know which one and why, and can weigh it accordingly.
Evidence trail
An evidence trail from schedule to page
A forensic schedule may be examined by the other side, a court or a regulator. Every figure in it should be traceable to the document it came from without a manual search through the bundle.
In VouchRow each transaction records the page and printed line it was read from, and selecting it opens the statement with that line highlighted. On scanned statements the line is located on the page image. That makes it practical to verify each figure that matters at its source before it goes into a report, and to show the source when asked.
The export carries the scope of the verification: which checks ran and whether they passed. The checks are arithmetic only. They cannot verify descriptions or dates, two errors that cancel would pass, and a statement altered with its balances adjusted would reconcile. Arithmetic consistency is evidence about the extraction, not about the authenticity of the document.
There is no fraud detection here
Side by side
Getting statements into an analysable form
| Manual keying | Generic PDF extraction | VouchRow | |
|---|---|---|---|
| Speed on large volumes | Slow | Fast | Fast; scans one at a time |
| Error location | Found later, by tracing | Not reported | Flagged at the row |
| Record of what was verified | Your notes | None | Reconciliation sheet per statement |
| Trace a row to the page | Manual | No | Highlighted source line |
| Silent adjustments | Possible | Possible | None; failures stay flagged |
| Analysis and conclusions | Yours | Yours | Yours |
Who uses it
Engagements where it fits
Commercial dispute
Five years of operating and savings account statements for two entities, converted and combined, with continuity breaks recorded before analysis starts.
Matrimonial instruction
Statements from both parties combined into one dataset for tracing transfers, with source pages cited in the expert report schedules.
Internal investigation
Payments to a supplier reviewed against the company’s bank statements, with suspect rows labelled and each opened at its source line.
FAQ
For forensic accountants: questions
What is the best software for forensic accounting bank statement analysis?
It depends on whether you want the software to analyse or to give you data to analyse. VouchRow is the second kind: checked conversion with provenance. For automated pattern detection you would pair your dataset with an analysis tool.
Can I combine several accounts into one dataset?
Yes, by exporting each statement and appending them, with account and period columns. There is no built-in cross-account matching.
Does it detect fraud or anomalies?
No. There is no fraud detection, anomaly scoring or duplicate-payment detection. The checks verify arithmetic only.
Can it detect a doctored statement?
No. An altered statement whose balances were altered to match reconciles. Authenticity needs the institution’s own records.
How are errors in scanned statements handled?
Scans are read by OCR, one at a time, and put through the same checks. Rows that break the balance chain are flagged for comparison with the highlighted source line.
What is recorded about the checks?
The Excel export’s Reconciliation sheet shows which checks ran and their results, and paid-plan exports include a reconciliation note. The scope is arithmetic: descriptions and dates are not verified, and cancelling errors would pass.
Are amounts adjusted to make a statement balance?
Never. Failing rows are left as read and flagged, and no balancing entry is created.
How much volume can it handle?
Plans are metered by pages with transactions: 300, 900 or 2,500 pages a month, each with a slider for more, and page packs from $0.06 a page that never expire. Digital statements upload in batches; scans are one at a time.
Keep going
Related guides and converters
Also relevant
Start the engagement from verified data
Create an account and convert your first statements into a checked dataset with a source line for every row. Plans start at $15 a month.