Bank statement analysis for forensic accountants
A forensic engagement usually starts with a folder of PDF statements and a question someone will ask you to answer under oath: how do you know these numbers are right, and how do you know the file you analyzed is the file you were given? This page is about the two mechanisms that answer that, in plain terms, before you ever open the data: the statement never leaves your machine, and the same PDF produces the same rows and the same result every time you run it.
Chain of custody: the statement is read in the tab, never uploaded
Most bank statement converters work the same way underneath: your file goes up to their server, a parsing job runs there, and a result comes back. That means the vendor is now a subprocessor that touched the evidence, which is exactly the kind of link a chain of custody has to name and defend. Whoever produced the data has to be prepared to explain who else had it, on whose infrastructure, and under what agreement.
This converter reads the PDF with pdf.js running inside your browser tab, in a background worker so the page stays responsive. The statement is never uploaded: the bytes are handed to that worker in memory and never make a network request. You can confirm this yourself in about a minute: open the browser Network tab, convert a statement, and watch the request list stay empty. The verify page on this site walks through exactly how to check it, and discloses the only things that ever do leave the tab (a count-only usage beacon with no document content, and an optional license check). For a workpaper or a deposition, the practical result is that there is no third-party server, and no subprocessor, in the path from the client's bank PDF to your reconciled export, so there is nothing to disclose there.
Deterministic and reproducible: the same PDF gives the same rows, every time
A cloud AI tool that reads a statement with a language model can return a slightly different table on two separate runs, because the underlying model is not required to produce identical output for identical input. That is a real problem for testimony, where a result has to be repeatable by opposing counsel's own expert running the same input through the same tool.
This engine does not use a language model to read a statement. It parses the PDF's text layer with fixed rules: characters cluster into rows by position, rows cluster into columns by alignment, and each column is classified by what it contains. Given the same bytes, that pipeline runs the same steps in the same order and returns the same table and the same reconciliation stamp, every time, on any machine. That is what "deterministic" means here in a literal sense, not a marketing sense: no randomness anywhere in the extraction or the verification math. If your report cites a stamp of "verified row-by-row" on a specific PDF, another examiner who runs that same PDF through the same tool version will get the identical stamp back.
The verification report: what it contains and what it proves
Every export already carries a reconciliation stamp, one of five states from verified row-by-row down to a failed check with the exact disagreeing rows marked. The verification report packages that result into a document built for a workpaper file rather than a spreadsheet: the source file's name and a SHA-256 hash of its exact bytes, computed locally with the browser's WebCrypto API; the statement period; the opening and closing balances as printed; the computed totals for money in, money out, and net; the stamp earned; row counts (total, verified, flagged); the exact rows that did not tie out, with both the expected and the actual figures; the engine version; the time it was generated; and a plain-language paragraph on what the check proves and does not prove.
That last paragraph matters as much as the numbers. The report is a verification aid: it confirms that the extracted rows chain correctly to the balances the bank itself printed on the statement. It does not confirm that the underlying transactions are genuine, that the statement was not altered before it reached this tool, or that a client's books are otherwise correct. The tool surfaces the rows that do and do not tie out; drawing a conclusion from that, in a report or in testimony, is the examiner's job, not the software's.
Where this fits: divorce, fraud examination, and litigation support
In a divorce or asset-discovery matter, uncovering hidden income means working through months or years of statements from accounts a spouse may not have volunteered, looking for patterns a bank's own summary will never surface. In a fraud examination, the question is usually whether a set of transactions is consistent with an innocent explanation or with a scheme, and that judgment rests on trusting the extracted numbers completely before you start pattern-matching on top of them. In both cases the statements arrive as PDFs, often photocopied or exported years after the fact, and the first job is turning them into a table you can actually work with in a spreadsheet or a case-management tool without wondering whether a digit got misread along the way.
This converter does that first job with the same reconciliation gate every bookkeeper export uses: previous balance plus each transaction equals the next printed balance, and opening plus activity equals closing. On a statement that reconciles cleanly, you can move straight to analysis. On one that does not, the flagged rows are exactly where a misread amount, a merged line, or a genuinely suspicious gap might be hiding, and the report names them instead of leaving you to re-check every row by hand.
A workflow built around evidentiary integrity
Start by dropping the statement PDF into the converter above. It parses in your browser, checks every row against the balances printed on the statement, and shows an editable table with the reconciliation stamp. If a row needs a correction, for example a description that wrapped across two lines and merged wrong, you can fix it and watch the check rerun live, still inside the tab.
When the review is right, export the verification report alongside whichever CSV or Excel format the engagement needs. Keep the source PDF and the report together in the case file: the SHA-256 hash printed on the report lets anyone holding the original PDF confirm, independently, that the report describes that exact file and not a substitute or a later revision. Because the hash is computed locally by the browser and printed on a document you control, there is no vendor server log to subpoena and no cloud processing history to explain.
None of this replaces professional judgment. The reconciliation check is a mechanical test of internal consistency between the extracted rows and the statement's own printed numbers, run the same way on every file. What you do with a clean or a flagged result, and how you present it, stays entirely yours.
Casework pricing
Casework is a separate tier for forensic, litigation-support, and fraud-examination work: unlimited statement pages and the verification report export, billed monthly. Every other tier on this site keeps working exactly as documented on the homepage; this card exists only on this page.
Casework
For forensic, litigation-support, and fraud-examination engagements.
- Unlimited pages
- Verification report export (chain-of-custody + reconciliation, per statement)
- Priority email support
- Cancel in one click
Honest billing, same as every tier: no card required to try the free tier first, cancel in one click, and no auto-renew surprises.
Frequently asked questions
How is this different from a cloud-based forensic accounting tool?
The statement is parsed in your browser tab with a fixed, non-AI pipeline, so it is never uploaded to a server and there is no subprocessor in the chain of custody to disclose. Extraction is deterministic: the same PDF produces the same rows and the same reconciliation stamp on every run, which a cloud tool built on a language model cannot promise.
What exactly does the verification report prove?
That the extracted transactions chain correctly to the balances the bank printed on the statement: previous balance plus each transaction equals the next printed balance, and opening plus activity equals closing. It is a check of internal consistency: it does not confirm that the underlying transactions are genuine or that the client's books are correct. It surfaces discrepancies; the examiner draws the conclusion.
What is the SHA-256 hash for, and how do I use it?
It is a fingerprint of the source PDF's exact bytes, computed locally in your browser with the WebCrypto API the moment you drop the file. Keep it with the report in your case file. Anyone holding the original PDF, including opposing counsel, can recompute the same hash and confirm the report describes that exact file, unaltered.
Can this be used for hidden-asset or divorce discovery work?
Yes. Drop each statement PDF in, review the reconciliation stamp and the flagged rows, and export a clean table for whichever spreadsheet or case-management tool you build the asset trace in. The gate exists so a misread digit does not silently become a wrong figure in a discovery exhibit.
Does the tool detect fraud or flag suspicious transactions?
No. It checks that the extracted numbers tie out to the statement's own printed balances; it does not analyze transaction patterns for fraud indicators. That judgment is the examiner's, working from data the tool has already confirmed is faithful to the source document.
What does the Casework tier include?
Unlimited statement pages, the verification report export, and priority email support, for $99 per month. Cancel in one click, and there is no card required to keep using the free tier if Casework is not the right fit.