Bank Statement Validation ToolValidate transactions, balances and financial data automatically
Upload a bank statement and automatically verify transaction accuracy, running balances, debit and credit mapping, duplicate records and financial consistency — before the data reaches your books.
Free plan: 10 pages a month · Originals deleted automatically 30 days after upload
A real sample: bank statement (uk style) — to a working spreadsheet
A fictional sample document converted by the same engine you get — flip through the source PDF and every export format, or download the files themselves.
What is bank statement validation?
Bank statement validation is the process of verifying that extracted transaction data is accurate, complete and internally consistent. It is the step between pulling transactions off a PDF and trusting them for reconciliation, reporting or an audit.
A strong validation workflow checks:
The goal is simple: ensure the exported spreadsheet accurately reflects the original statement. A statement is a chain of transactions where each balance depends on the one before it — which makes it uniquely suited to automated validation. If a single row is missing or duplicated, the running balance stops adding up, and that break is something a rules engine can detect with certainty.
What the bank statement validator checks
Every uploaded statement runs through the same deterministic checks, so the review is identical whether it is a single page or two hundred transactions across ten pages.
Transaction Dates
Detects invalid or missing dates.
Transaction Descriptions
Verifies transaction rows were extracted correctly.
Debit Amounts
Checks outgoing payments.
Credit Amounts
Checks incoming funds.
Running Balances
Validates balance progression.
Missing Transactions
Identifies gaps in extracted data.
Duplicate Transactions
Detects repeated entries.
Account Consistency
Reviews statement integrity.
How bank statement validation works
Every step runs automatically on upload, and you stay in control of the final review — nothing a check flags is exported as if it had passed.
Upload Statement PDF
Drag & drop a digital or scanned statement.
OCR Reads Document
The statement is converted into machine-readable text.
AI Extracts Transactions
Rows, amounts and balances are structured.
Validation Rules Run
Balances, duplicates and gaps are checked.
Issues Detected
Inconsistencies are flagged.
Report Generated
A validation report is produced.
Export Clean Data
Validated transactions are exported.
Validate running balances automatically
The single most important check on a statement is the running balance. The system re-derives the balance for every row and confirms the chain holds:
If a balance does not match the expected value, the validator flags the row. Because each balance depends on the previous one, a single break pinpoints exactly where something went wrong — helping identify:
Running-balance validation: a worked example
The figures below are a made-up example, kept small so every line can be checked in your head. An account opens at 3,500.00 and records five transactions. The right-hand column is what the validator computes for each row: the balance above, plus or minus this row's amount, against the printed balance.
| # | Date | Description | Amount | Printed balance | Validator's check |
|---|---|---|---|---|---|
| — | 01 Mar | Opening balance | 3,500.00 | Start of chain | |
| 1 | 03 Mar | Client payment | +1,250.00 | 4,750.00 | 3,500.00 + 1,250.00 = 4,750.00 ✓ |
| 2 | 05 Mar | Office rent | −1,100.00 | 3,650.00 | 4,750.00 − 1,100.00 = 3,650.00 ✓ |
| 3 | 09 Mar | Card fee | −12.50 | 3,637.50 | 3,650.00 − 12.50 = 3,637.50 ✓ |
| 4 | 12 Mar | Software subscription | −49.00 | 3,588.50 | 3,637.50 − 49.00 = 3,588.50 ✓ |
| 5 | 15 Mar | Customer refund received | +75.00 | 3,663.50 | 3,588.50 + 75.00 = 3,663.50 ✓ |
Every row holds, and so does the whole statement: 3,500.00 + 1,250.00 − 1,100.00 − 12.50 − 49.00 + 75.00 = 3,663.50, the printed closing balance. Here is what four common extraction faults do to the same statement:
| What went wrong | Row-by-row check | Opening + transactions = closing |
|---|---|---|
| Digits swapped on row 3 (−21.50 read instead of −12.50) | 3,650.00 − 21.50 = 3,628.50, but the printed balance is 3,637.50 — row 3 is off by 9.00 and is named | 3,500.00 + Σ amounts = 3,654.50 ≠ 3,663.50 closing — off by 9.00 |
| Row 4 lost at a page break | Row 5: 3,637.50 + 75.00 = 3,712.50, but the printed balance is 3,663.50 — off by exactly 49.00, the missing amount | Σ amounts falls 49.00 short of the closing balance |
| Refund read as a debit (sign lost) | 3,588.50 − 75.00 = 3,513.50 ≠ 3,663.50 — off by 150.00, twice the amount | Off by 150.00 — a difference of twice one row's amount points to a sign error |
The size of the difference is a clue: one transaction's amount usually means a missing or repeated row; twice an amount means a flipped sign; a gap divisible by nine is the fingerprint of swapped digits. The row check tells you where the problem is; the totals check tells you whether the document is complete, and it still works on statements that print no running balance. FlowParse runs both.
That is the answer to how to extract transactions from bank statement PDFs and validate running balances automatically: extraction produces a plausible table, the running balance turns it into a checked one. Our guide on how to extract transactions from a PDF bank statement covers the extraction half.
Detect missing transactions
Missing rows are one of the biggest risks in bank statement extraction — and the hardest to spot, because what is gone leaves no visible trace on the page. Common causes include:
The Validation Engine automatically identifies suspicious gaps by watching the running balance: when it jumps by an amount the listed transactions cannot account for, a row is probably missing — and you are told where.
Duplicate transaction detection
Duplicate transactions — often introduced when overlapping pages are extracted twice — quietly corrupt your data. They can create incorrect balances, reconciliation issues and inaccurate reports. The validator checks:
Potential duplicates are highlighted automatically so you can confirm or remove them before export.
Three verdicts, honestly reported
The verdict travels with the document, and it only ever says one of three things. There is no score to interpret and no percentage dressed up as certainty — either the statement's own arithmetic holds, or it does not, or there was nothing printed to check it against:
Reconciled
Every row holds
Each balance follows from the previous one plus the amount, within 0.02.
Failed
Named rows
The arithmetic breaks — the verdict lists the exact rows, so you check two, not two hundred.
Not verifiable
Nothing to check against
No running-balance column printed — the verdict says so instead of pretending to pass.
The third verdict matters more than it looks. Plenty of documents — some card statements, simple transaction lists, exports with the balance column cut off — print no running balance at all. A tool that reports "validated" on those is reporting its own optimism. FlowParse reports not verifiable, extracts the data anyway, and leaves the judgement with you.
Validation report
Every processed statement receives a clear, actionable report — a summary of exactly what was checked and what needs attention.
Statement status
Issues found
- Missing transactions
- Duplicate rows
- Balance discrepancies
- OCR concerns
Rows checked, rows passed
The report counts the rows that carried a checkable balance and how many of them held, plus the opening balance, the closing balance and the computed closing — opening plus the sum of all amounts — side by side.
Exact failing rows
A failed verdict names the rows whose arithmetic breaks, linked in the preview, so the review starts at the problem.
Bank statement validation for accountants
Accountants use statement validation to turn slow, line-by-line reconciliation into a fast, exception-based review. Instead of checking every row, they focus only on what the validator flags:
- Improve bookkeeping accuracy
- Reduce reconciliation time
- Prepare audits
- Review client statements
- Identify missing transactions
Why the running balance is the only real proof
A bank statement is unusual among financial documents: it carries its own proof. Every row prints the balance after the booking, so the balance on row ten minus the balance on row nine must equal row ten's amount — and the opening balance plus the sum of every amount must land on the closing balance. Nothing else can tell you whether an extraction is right. The PDF has no answer key, no labels, no second copy to compare against. This arithmetic is the answer key, and it is printed on the statement itself.
That is why FlowParse runs the check on the verbatim grid — the table exactly as printed, the same grid your Excel file is built from. Among the faults it has caught on real statements: a VAT number landing in the balance column, credits silently losing their sign, and amounts read off the wrong column. Each produced a plausible spreadsheet; each broke the chain on the first row it touched.
One refinement matters on real documents: many PDFs print several accounts in sequence — a current account, then a savings account, each restarting its own running balance. The validator detects those blocks and checks each chain separately. Without that, every multi-account statement would fail at each boundary for no real reason; with it, a break inside any one account still surfaces precisely.
There is also one defect the arithmetic can not only detect but name: when every single row holds with the amounts' signs flipped, the extraction read debits as credits throughout. That is reported as exactly that — an inverted statement — and corrected with arithmetic rather than a re-read, because the evidence is unambiguous.
Overdrawn accounts: Dr, OD and parentheses
Statements rarely print a minus sign on a negative balance. They write 680,905.75 Dr, 29,157.09 OD or (1,234.56) — a trailing marker that is easy for software to miss, and when it is missed, an overdrawn account reads as comfortably in credit. On one real overdrawn statement, correcting the balance signs dropped the rate of rows whose balance movement disagreed with their amount from 81.9% to 18.1% — the difference between a file you can reconcile and one you cannot.
Each repair is guarded twice: a negation only triggers on a marker printed on that field's own text, and every repaired row is re-tested against the balance arithmetic and rolled back if the chain gets worse.
Duplicates: dropped, flagged or left alone
Not every repeated row is an error, so the pipeline treats repetition in three different ways rather than one blunt rule. A line the extraction read twice from the same page — same row, same position — is dropped outright. So are notice-block repeats: many European statements re-print upcoming direct debits in an announcement block (Avis de prélèvement, Lastschriftankündigung, Avisos de lançamento) with the same date and amount but no balance of their own; counting those twice would double every announced payment.
What remains — two rows sharing a date, an amount and a description — is flagged, not deleted. A real fleet-card ledger printed the identical toll charge twice in a row: a double-printed line, or the same toll gate crossed twice in one day? No algorithm can decide that from the PDF, so the validator lists the pair and lets someone who knows the account decide.
Dates that moved — and why you are told
Scanned statements misread years more than any other field — a 2023 that comes out as 2028 puts a transaction outside the statement's own period, and the pipeline re-anchors it to the year that puts it back inside. That repair is almost always right. Almost.
Some documents legitimately reference dates outside their own period: an expense ledger once listed a tyre replacement dated a month before the statement's stated start — a real purchase, correctly dated, that a silent "fix" would have moved. So the validator does not hide the repair. Every row whose year was re-anchored is listed, with the printed date and the adjusted date side by side, so a reader who knows their own dates can spot-check them in one pass instead of discovering a moved date at tax time.
Transaction validation: every check, in one table
"Transaction validation" can sound like a black box. It is not: every check below is a fixed rule that runs on every bank statement, compares numbers or text the statement already prints, and produces the same result every time it is run on the same file. Nothing here is a model's opinion. The same discipline sits behind our wider financial data validation for invoices, receipts and other financial documents.
| Check | What it compares | What happens when it fails |
|---|---|---|
| Running balance, row by row | Previous balance ± amount against the balance printed on the row, within 0.02 | Failing rows named; verdict Reconciled / Failed / Not verifiable |
| Opening + transactions = closing | The statement's own printed opening and closing balances against the sum of every amount | Document flagged incomplete or over-counted — works even without a balance column |
| Same line read twice on one page | Identical date, amount and description on the same page, with matching balance or position | Dropped before export |
| Notice-block repeats | Upcoming direct debits re-printed in an announcement block with no balance of their own | Dropped, so announced payments are not counted twice |
| Possible duplicates | Rows that still share date, amount and description after the drops above | Listed in the export for you to decide — never deleted |
| Date inside statement period | Each transaction date against the period the statement prints | Warning; re-anchored years disclosed with printed and adjusted date |
| Rows without date or amount | Share of rows missing a date, an amount, or both | Warning, or an error when the table is clearly not a ledger |
| Header fields | Account holder, currency, opening and closing balance present and read with confidence | Warning to verify before export |
| Balance sign markers | Dr, OD and parentheses printed on the balance itself | Sign repaired, then re-tested; rolled back if the chain gets worse |
One check is deliberately absent: a separate per-page subtotal comparison. Many statements print no page subtotals, and the running balance already carries across page breaks — a row lost between pages breaks the chain at exactly that point.
Bank statement verification: two different jobs
People search for "bank statement verification software" or a "bank statement checker" meaning two different things, and it is worth being plain about which one this is. One job checks the data: that what landed in your spreadsheet is complete and arithmetically consistent with what the statement printed. The other checks the document: that the PDF really came from the bank and has not been altered. FlowParse does the first. It does not do the second, and it does not certify that a statement is genuine.
| Data validation | Document authenticity verification | |
|---|---|---|
| Question it answers | Do the extracted numbers add up and match what the statement prints? | Did the bank really issue this document, unedited? |
| Evidence used | The statement's own arithmetic: balances, opening, closing, dates | The file itself, the issuing bank, open-banking data, the customer's identity |
| Catches | Missing, repeated and misread rows; lost signs; incomplete extraction | Altered amounts, template fakes, documents never issued by the bank |
| Cannot catch | A carefully forged statement whose arithmetic was kept consistent | A genuine statement that was then extracted into Excel with errors |
| FlowParse | Yes — built into every upload | No — we do not certify documents |
What authenticity checks generally involve
Document-fraud checking is its own discipline, usually run by lenders, letting agents and compliance teams. Generically, it combines three kinds of evidence. The file: PDF document properties record when it was created and last modified, and a March statement modified last week invites a question. The page: a figure in a slightly different font, characters off the baseline, text layered over an image. And the source: asking the bank to confirm the figures, or reading the account through open banking, where the account holder gives explicit consent for a regulated provider to access the data directly from the bank.
The two jobs overlap: a clumsy edit usually breaks the running-balance chain, so a failed verdict on a clean-looking PDF is a reason to look harder. But a careful forger can keep the arithmetic consistent, so a reconciled verdict is evidence of consistency, never of origin. For affordability work, our page on bank statement analysis for loans covers turning statements into underwriting data — pair it with source verification, not instead of it.
And a third meaning: real-time transaction validation
"Real-time data validation for financial transactions" usually means screening payments as they happen, inside a bank or payment system. That is transaction monitoring, not statement validation. FlowParse checks each statement, and the transactions printed on it, when you upload it.
"Is this a valid statement?" — a checklist
Split the question in two. The left column can be proven from the statement itself; the right column needs evidence from outside the document. A statement can pass one side and fail the other.
Is the data valid? (FlowParse checks this)
- Every row's balance equals the previous balance plus that row's amount
- Opening balance plus all transactions equals the closing balance printed on the statement
- The opening balance matches the closing balance of the previous statement
- Every transaction date falls inside the statement period
- No unexplained pairs of rows with the same date, description and amount
- Page breaks do not drop or repeat a row — the balance carries straight across
Is the document genuine? (outside FlowParse)
- The statement came to you directly from the bank or the account holder's online banking, not as a forwarded edit
- Fonts, spacing and alignment are consistent — a figure in a slightly different typeface is a classic edit sign
- The file's document properties: creation and modification dates that do not fit the statement date deserve a question
- Totals, interest and fees look like that bank's usual statements for the same account type
- When the decision matters, the figures are confirmed with the bank or through consented open-banking data
Statements also chain across months: February's closing balance must be March's opening balance. When you merge months with combine bank statements into one Excel, compare each closing balance with the next opening balance before reconciling.
How to validate a bank statement yourself in Excel
A spreadsheet and a few formulas run the core checks, and knowing them lets you re-check any row you doubt. Put the date in column A, description in B, a signed amount in C (credits positive) and the printed balance in D, with the opening balance in D2 and the first transaction in row 3. A bank statement to Excel conversion gives you these columns directly.
| Purpose | Cell | Formula | How to read it |
|---|---|---|---|
| Row check (signed amount column) | E3 | =ROUND(D2+C3-D3,2) | 0.00 on every row means the chain holds |
| Flag only the breaks | F3 | =IF(ABS(D2+C3-D3)>0.005,"BREAK","") | Filter the column for BREAK |
| Whole-statement identity | any | =ROUND(Opening+SUM(C3:C200)-Closing,2) | Name the opening and closing cells Opening and Closing; 0.00 means complete |
| Possible duplicates | G3 | =COUNTIFS(A:A,A3,B:B,B3,C:C,C3)>1 | TRUE marks rows sharing date, description and amount |
| Date inside the period | H3 | =AND(A3>=PeriodStart,A3<=PeriodEnd) | FALSE marks a date outside the statement period |
Fill the row check down: every cell should read 0.00, and the first non-zero cell is where the problem starts. ROUND matters because spreadsheets store money as binary fractions, so a correct chain can show 0.0000000001 without it.
COUNTIFS counts rows where every condition is met at once, so it finds rows sharing date, description and amount. Treat a TRUE as a question, not a verdict — two identical coffees on one day are real.
The manual route's weak points are retyping balances, which adds the errors you are checking for, and setup time on long statements. FlowParse runs the same checks on the extracted grid and lists failing rows in the workbook's QA Report sheet. To then match the statement against your ledger, see how to do a bank reconciliation.
Supported statements
The validator works with statements from the major neobanks and high-street banks, in both digital and scanned form.
Revolut Statements
Wise Statements
Monzo Statements
N26 Statements
Business Bank Statements
Personal Bank Statements
Multi-Page Statements
Scanned Statements
Frequently asked questions
Explore related tools & features
Bank Statement Converter
PDF statements to Excel & CSV — validation built in
Validation Engine
The full document validation technology
Invoice Validation
Validate invoice totals, VAT & fields
Invoice Quality Score
Get a 0–100 invoice quality score
Financial Data Validation
Validate any financial document
Bank Statement to Excel
Convert statements to Excel instantly
Revolut to Excel
Convert & validate Revolut statements
Wise to Excel
Convert & validate Wise statements
Monzo to Excel
Convert & validate Monzo statements
N26 to Excel
Convert & validate N26 statements
AI VAT Auditor
Full VAT compliance audit & score
Combine Statements
Merge statements into one validated Excel
Free Converter
Convert statements free — validation included