How TieOut proves a bank statement conversion is complete
Every row TieOut extracts is checked against the statement's own running balance: the balance on each line must equal the previous balance plus any credit minus any debit, and the last balance must equal the closing balance printed on the statement. If both hold for every row, nothing was dropped, duplicated or misread. That check is called running-balance validation, and it is where the name TieOut comes from.
Running-balance validation, defined
A bank statement is a self-checking document. It does not just list transactions — it carries a balance after each one, which means the arithmetic of the whole page has to reconcile. Written out:
balancen = balancen−1 + creditn − debitn, for every row n; and balancelast = the closing balance printed on the statement.
The chain is what makes it powerful. Any single extraction error breaks it: a dropped row leaves a jump the next line cannot explain, a duplicated row overshoots, a debit read as a credit inverts the difference, and a misread digit lands the balance somewhere the printed figure is not. There is no common failure mode that quietly satisfies the equation.
Worked example
| Date | Narration | Debit | Credit | Balance | Check |
|---|---|---|---|---|---|
| 04/07/26 | UPI/DR/451203/GROCERY | 1,240.00 | 48,760.00 | ✓ | |
| 05/07/26 | NEFT CR SALARY JUL | 85,000.00 | 1,33,760.00 | ✓ | |
| 07/07/26 | ACH DR LOAN EMI | 22,415.00 | 1,11,345.00 | ✓ |
Opening balance 50,000.00. Row one: 50,000.00 − 1,240.00 = 48,760.00 ✓. Row two: 48,760.00 + 85,000.00 = 1,33,760.00 ✓. Row three: 1,33,760.00 − 22,415.00 = 1,11,345.00 ✓. Three rows, three passes, and the closing figure matches what the bank printed — so this extract is provably complete.
Why this beats an accuracy percentage
"99% accurate" is unfalsifiable on your file. It is a claim about someone else's test set, and it gives you nothing to check. A balance chain is different: it runs on your statement, every time, and its verdict is visible before you export. You are not trusting a number in marketing copy — you are reading the result of a test on the document in front of you.
It also changes what a failure looks like. Most converters have no way to know they got it wrong, so a bad parse arrives looking exactly like a good one. That is the real risk in statement conversion: not obvious garbage, which you would catch, but a plausible table that is missing one transaction out of four hundred.
What the check does not prove
Worth being precise about, because the limits are real:
- Narration text is not validated. Descriptions carry no arithmetic, so a truncated or mis-attributed narration can sit inside a fully passing table. This is the main reason to spot-check descriptions —Axis statements in particular wrap their particulars upward, which is exactly the kind of error the balance chain cannot see.
- It cannot detect an error in the statement itself. If the bank printed a wrong balance, the chain breaks and TieOut will blame the row — correctly noting a disagreement, but not knowing which side is at fault.
- It says nothing about classification. Whether a payment belongs in one ledger or another is a judgement call, and the check has no opinion on it.
- Scanned statements are out of scope. Images need OCR before there is anything to validate. Native e-statements downloaded from netbanking work today.
What happens when a row fails
The row is flagged in the results table and the summary shows how many rows broke the chain. Nothing is dropped and nothing is auto-corrected — a converter that silently "repairs" a row it does not understand is worse than one that fails loudly, because it removes the one signal you had. You get the location of the disagreement and can open the PDF at that page.
In practice a break usually means one of three things: the statement layout differs from the profile for that bank, the file contains an appended table that is not part of the statement, or the PDF is a scan. All three are worth reporting —the per-bank pages list what has been verified so far and what is still wanted.
Verify the privacy claim in ten seconds
The other claim on this site is that the file is never uploaded, and that is testable too: turn off your Wi-Fi and convert a statement anyway. It still works, because there is no server in the path. Or open DevTools → Network while converting and watch that no request carries your PDF. Run that test on any converter you use, not just this one — it is the fastest way to find out what a given tool actually does with your statement.
FAQ
What is running-balance validation?
It is a completeness check on extracted bank statement data. Every parsed row must satisfy balance = previous balance + credit − debit, and the final balance must equal the closing balance printed on the statement. If both hold for every row, no transaction was dropped, duplicated or misread in a way that affects the numbers.
Does a passing balance check mean the conversion is perfect?
It means the numbers are complete and internally consistent, which is the part that matters for your books. It does not verify the text: a narration could still be truncated or attributed to the wrong row while every balance ties. Spot-check a few descriptions against the PDF before you allocate ledgers.
What happens if a row fails the check?
It is flagged in the results table rather than dropped or silently corrected. A broken chain tells you exactly where the parser and the statement disagree, so you can look at that row in the original PDF. Silence would be the dangerous behaviour — a missing transaction leaves no gap you could notice by eye.
Why do other converters not do this?
Because it constrains what they can claim. A converter that validates has to admit when a statement does not parse cleanly; one that does not can present any output as a success. The check is also only possible because a bank statement carries its own running balance — it is a property of the document, not a clever algorithm.
Can I verify TieOut does not upload my statement?
Yes, in about ten seconds. Turn off your Wi-Fi and convert a statement anyway — it still works, because there is no server involved. You can also open DevTools → Network while converting and confirm that no request carries your file.