Every accountant who’s closed a month-end knows the drill: open the bank statement in one window, open the Tally Day Book in another, and go line by line checking that every debit and credit on one side has a matching entry on the other. It’s not hard work, exactly — it’s just work that punishes a lapse in attention with a books-vs-bank gap that can sit undetected for weeks.
Why doing this by hand goes wrong
The failure modes aren’t exotic. They’re the same handful of things, every single month:
- A transaction simply never got entered. A bank charge, an auto-debit for a subscription, a small NEFT — something the bank processed that never made it into Tally because nobody told the person entering vouchers it happened.
- A transposed digit looks fine at a glance. ₹4,230 typed as ₹4,320 reads as “close enough” when you’re skimming two columns of numbers at 11pm — until it isn’t, and the books are off by ₹90 for a transaction that otherwise looks matched.
- Cheque deposits don’t clear the day they’re recorded. A cheque voucher dated the day it was handed to the bank can clear three or four days later on the statement. Eyeballing “same amount, different date” and deciding whether that’s the same transaction or a coincidence is exactly the kind of judgment call that’s easy to get wrong at row 140 of a statement.
- PDF statements don’t paste cleanly. Copy text out of a PDF bank statement and the columns interleave, the running balance jumps into the middle of a description, and a multi-line narration ends up as three separate rows. Manual reconciliation against a PDF is reconciliation against garbled data before you’ve even started comparing anything.
None of these are “someone was careless.” They’re what happens when a repetitive, detail-heavy comparison task runs entirely on human attention. Bank Statement to Tally XML — matching engine name “Fatafat Balance” internally — is built to do the actual matching mechanically, and only hand a human the small number of decisions that genuinely need one.
How the tool works, end to end
1. Upload both sides. The bank statement can be CSV, XLSX, or PDF. The books side is your bank ledger export as CSV or XLSX — a Tally Day Book, or a QuickBooks/Xero/Zoho Books bank register — with a small toggle above the upload box for which one it is (more on why that matters in a moment). If either file’s columns can’t be confidently detected (an unusual header, or a PDF with no clean header row at all), you get a manual column-mapping screen — pick which column is the date, description, debit/credit or signed amount, and balance — rather than the tool silently guessing wrong.
2. It checks the bank statement’s own math first. Every row with a running-balance column gets checked against the row before it — opening balance plus this transaction should equal the new balance. A break here almost always means a parsing slip (a merged row, a skipped line), not a real bank error, so it’s flagged before anything else runs. If you see this warning, it’s worth re-checking the parsed rows before trusting the reconciliation results.
3. It matches transactions by amount and date, in tiers, and never guesses on a tie. This is the part worth understanding properly — it’s covered below.
4. You review, correct, and export. The result screen is six tabs — Exact matches, Probable matches, Needs your input, Possible amount mismatches, Missing in Accounting Software, and Extra in Accounting Software — and only “Missing” produces a voucher. Each transaction shows as its own card: date and amount up top, the matched entry (or the ledger you’re assigning) underneath, so it’s a clean comparison rather than a wall of text. Confirm ledgers, tick which transactions to include, and download.
The sign convention, and why it matters
A bank statement and a Tally Day Book describe the same transaction with opposite signs, and it trips people up the first time they think about it. On your bank statement, a credit (money in) is positive. But a Tally Day Book is written from the ledger’s own point of view: your bank account is an asset ledger, so a receipt that increases it posts as a debit (“To …”), and a payment that decreases it posts as a credit (“By …”) — the reverse of what the statement calls the same transaction. QuickBooks, Xero, and Zoho Books don’t do this — their own bank-register exports already use the same convention as the statement itself (deposit positive, withdrawal negative).
This is exactly what the source toggle from step 1 is for: pick “Tally” and the tool flips the ledger-side sign so a ₹52,000 cheque deposit on your statement lines up against the matching ₹52,000 receipt in Tally instead of coming out looking like a −₹52,000 mismatch; pick “QuickBooks / Xero / Zoho Books / other” and it takes the amounts as-is, no flip. Getting this one toggle wrong is the one way to make an otherwise-correct ledger export look completely unmatched, so it’s worth double-checking before you run the match.
The five match tiers
The matcher works through the bank transactions and Tally entries and sorts every pair into one of five buckets, and the logic behind the split is worth knowing because it’s what makes the “missing” list trustworthy:
- Exact — same amount, same date. Nothing to review.
- Probable — same amount, but the Tally date is up to 5 days off. This exists specifically because cheque deposits clear days after they’re recorded — a same-amount pair 3-4 days apart is very likely the same transaction, not a coincidence, but it still gets a one-click Confirm match instead of being silently auto-committed.
- Needs your input (ambiguous) — the amount matches more than one Tally entry within the date window. If two ₹15,000 cheque deposits cleared close together and Tally has two ₹15,000 receipts recorded, the tool has no reliable way to know which is which — so it doesn’t guess. You get both candidates and pick, or mark it “None of these,” which correctly treats it as missing instead.
- Possible amount mismatch — same date, same side (debit/debit or credit/credit), but the amounts are close and not equal. This is the typo detector: it’s checking for exactly the digit-transposition and mistyped-decimal errors that happen when someone keys in a voucher by hand, and it’s deliberately narrow — same-day matches need only a small gap (default ₹100) to qualify, while a match on a different date needs an even tighter gap (default ₹15) before it’s flagged, specifically so two unrelated transactions that happen to be in the same rough range don’t get wrongly paired just because they’re a few days apart.
- Missing in Accounting Software — no plausible entry on the books side at all. This is the list that turns into vouchers.
That’s the classification for every bank transaction. The mirror case — a books entry with no bank transaction anywhere near it — lands in its own Extra in Accounting Software tab: a voucher entered under the wrong date, a duplicate entry, or something that never actually hit the bank at all. Nothing here gets exported; it’s a flag to go check and correct or delete it on the books side.
Two worked examples
Say your August bank statement and your Tally Day Book for the same bank ledger look like this (INR, dates as ISO for clarity):
| Bank statement | Amount | Tally Day Book | Amount |
|---|---|---|---|
| 03 Aug — UPI/CR/…/RAVI KIRANA STORES | +18,500.00 | 03 Aug — To Ravi Kirana Stores | +18,500.00 |
| 05 Aug — NEFT/MSEDCL ELECTRICITY BOARD | −4,320.00 | 05 Aug — By MSEDCL Electricity | −4,230.00 |
| 07 Aug — BB/CHQ DEP/000512 | +52,000.00 | 03 Aug — To Ravi Traders (cheque) | +52,000.00 |
| 10 Aug — UPI/DR/…/HPCL PETROL PUMP | −2,000.00 | 10 Aug — By HPCL Fuel | −2,000.00 |
| 12 Aug — NEFT SALARY PROCESSING | −85,000.00 | (nothing) | — |
| 14 Aug — Charge: SMS Alert · CGST · SGST | −59.00 | (nothing) | — |
Run this through and here’s how it sorts:
- Exact: the ₹18,500 receipt (3 Aug both sides) and the ₹2,000 HPCL fuel payment (10 Aug both sides).
- Probable: the ₹52,000 cheque — recorded in Tally on 3 Aug, cleared on the statement on 7 Aug. A 4-day gap, inside the default 5-day window, so it surfaces with a Confirm-match button rather than being auto-accepted.
- Possible amount mismatch: the electricity payment. Same date (5 Aug), same side (both debits), off by ₹90 — ₹4,320 on the bank statement versus ₹4,230 in Tally. That ₹90 gap is well inside the same-day tolerance, so instead of landing in “Missing” (which would create a second, duplicate voucher) it’s flagged as a likely data-entry typo, with the difference shown right in the review screen. The fix is to correct the existing Tally voucher, not import a new one.
- Missing in Tally: the ₹85,000 salary debit and the ₹59 bank charge (with its CGST/SGST split folded into the description). Neither has anything remotely close on the Tally side — these are the two that genuinely never got entered, and they’re what the exported XML will turn into vouchers for.
That ₹90 mismatch is the case manual reconciliation is worst at catching — it looks matched if you’re not reading every digit carefully, because both entries are “the electricity payment on the 5th.” The tool catches it precisely because it isn’t reading for plausibility, it’s checking the actual numbers.
Reviewing what’s missing, and getting the ledger right
For each transaction in “Missing in Tally,” the tool suggests a counter-ledger — “Electricity Expenses” for an MSEDCL debit, “Fuel Expenses” for an HPCL charge, “Bank Charges” for anything matching charge/fee/penalty, and so on, checked against a set of Indian-banking-specific patterns before falling back to a generic “Suspense” when nothing matches. You correct these inline, same screen — it’s a normal text field next to each transaction.
Two things make this get better over time instead of staying a one-off guess:
- Per-client learning. Create a named client profile, and every ledger you correct gets remembered — not as an exact-match rule on that one transaction’s description (which would never fire again, since every UPI/NEFT line embeds a unique reference number), but as a rule built from the one stable, human-identifying token in it, usually the payer or payee name. Assign “RAVI KIRANA STORES” to a ledger once, and it’s suggested automatically the next time that name shows up, on a completely different reference number. The mapping lives in the browser (IndexedDB) and has a one-click JSON backup/restore if you’re moving between machines.
- Optional ledger-master validation. Upload your actual Tally List of Accounts (as CSV/XLSX) on the client-profile card, and every suggested ledger gets checked against your real chart of accounts — ”✓ Found in your ledger list” or “Not found.” Only for names verified as genuinely new can you opt in, per-transaction, to have the export create that ledger (with a parent group you specify) alongside the vouchers. Nothing gets created on a guess, and an existing ledger is never touched.
The “never guess silently” design, and why it matters here specifically
The one rule the matching engine never bends: when more than one Tally entry could plausibly be a given bank transaction, nothing gets auto-matched. It’s tempting to think a bit more cleverness — nearest date wins, say — would resolve most of these automatically. But a silently wrong match here doesn’t just misfile one transaction; it can leave a real duplicate hiding in “exact matches” while the actual missing transaction quietly vanishes from the review screen entirely, because something else absorbed its slot. Reconciliation software that guesses wrong is worse than one that asks, because a wrong guess looks finished. That’s why ambiguous cases go to a dedicated tab with radio buttons instead of a confidence score and an auto-pick.
Practical tips
- Export CSV or XLSX from netbanking whenever you can. The PDF path is a genuinely useful fallback — it reads the text layer of the statement, works out which line is a transaction, and handles multi-line wrapped descriptions — but PDF table layouts vary enough between banks that it’s the more fragile route. If a PDF doesn’t parse cleanly, exporting CSV instead will almost always do better than fighting the column mapper.
- Don’t shrink the date-tolerance instinct — cheques really do take days. The 5-day probable-match window exists because that’s what a real Tally Day Book vs. bank statement pair actually looks like for cleared cheques. If you see a probable match that’s clearly wrong, don’t confirm it — leave it, and it’ll resolve as ambiguous or missing once you handle the real pairing.
- Test-import a small batch first. The exported Tally XML follows Tally’s standard, well-documented Payment/Receipt voucher schema, but every Tally environment is a little different. Import 2-3 vouchers into a scratch or test company before importing a full month’s batch, the same way you’d sanity-check any bulk import.
- Not on Tally? Both sides of the tool work without it. On upload, set the source toggle to “QuickBooks / Xero / Zoho Books / other” so your register’s amounts are read as-is, no sign flip. On export, alongside the Tally XML, the results screen offers a CSV in the plain Date/Description/Amount shape QuickBooks Online, Xero, and Zoho Books each document as their own bank-statement import format, and an OFX file — a genuinely open, decades-stable standard those three, Quicken, and most banks accept natively. Both carry just the missing transactions, ready to import as a bank feed. There’s also a full Excel workbook of every tab (exact, probable, needs-input, mismatches, missing) if you just want a paper trail or a file to hand to a client or auditor who isn’t touching Tally at all.
- Nothing leaves your browser. Parsing, matching, and file generation all run client-side — your bank statement and Day Book are never uploaded anywhere, which matters given what’s in them.
Try it
If you’re closing a month and staring down two files that should agree but might not, Bank Statement to Tally XML does the line-by-line comparison for you — exact matches out of the way immediately, cheque-clearing gaps confirmed with one click, genuine typos flagged instead of buried, and a ready-to-import voucher file for what’s actually missing. It’s free, runs in your browser, and nothing needs an account.