TallyPrime will reconcile your bank accounts. One ledger at a time
TallyPrime's Auto Bank Reconciliation imports bank statements and auto-matches each line to a voucher — Exact Match, Potential Match or Partial Match — but it runs one bank ledger at a time, each with its own settings. Across multiple accounts, a matched line still doesn't identify which GST invoice or vendor it settles.
Auto Bank Reconciliation in TallyPrime will import a statement and line it up against your vouchers on its own, and it's genuinely good at the mechanical part — exact matches, near-misses, partial payments. What it was never built to do is give you one view across every bank account you hold, or tell you which GST invoice a settled line actually closes. This is the setup, what each match status means, and where the report stops.
What Auto BRS actually does
TallyPrime's Auto Bank Reconciliation ("Auto BRS") is a matching engine: you import a bank statement, and it compares each line against the vouchers already sitting in your bank ledger, then sorts the result into named buckets — Exact Match, Potential Matches, and unmatched lines Available Only in Books or Available Only in Bank. Where the two sides carry the same reference but a different amount, it will still let you link them as a Partial Match rather than force an all-or-nothing decision. According to Tally's own documentation, this requires TallyPrime Release 6.0 or later, and accepts bank statements in Excel, CSV or MT940 format; Tally's documentation cites bank-compatibility figures ranging from 145 to over 200 banks, without reconciling the two numbers itself. (Tally mechanics in this article verified against Tally's own documentation as of 7 August 2026.)
None of that is filing. Tally isn't submitting anything to a bank or a government portal here — it's comparing two records you already have (your books, and the statement you imported) and telling you where they agree. That's a genuinely useful reduction of a manual line-by-line tick-and-tie exercise, on the bulk of a statement that matches cleanly. It is also the entire scope of the report. It does not know why a line is unmatched, and it has no view of anything outside the ledger you're currently reconciling.
Setting it up, one bank ledger at a time
Every bank account in TallyPrime is its own ledger, and Auto BRS is configured — and run — per ledger. There is no single screen that reconciles every account at once; you open the Bank Reconciliation report against one bank, work through its buckets, then repeat for the next.
| Step | What you do | Why it matters across multiple accounts |
|---|---|---|
| 1. Set the Reconciliation Beginning Date | In the bank ledger itself, before you reconcile anything | This is set per ledger — add a new bank account and it defaults to unset; forget it on one account and that account's reconciliation silently starts from the wrong point |
| 2. Bring in older unreconciled entries, if any | Use the Opening BRS report to add transactions recorded before the Reconciliation Beginning Date that are still unreconciled | A one-off catch-up step per account, not a recurring one |
| 3. Import the statement | Import the bank statement file (Excel/CSV/MT940) into the bank ledger | One file, one account, one import — statements from different banks arrive in different formats and on different cycles |
| 4. Open the Bank Reconciliation report | Against that specific bank ledger | You are looking at one account's match state; nothing here rolls up across accounts |
| 5. Work the Exact Match bucket | Select one or more transactions, press F8 (Reconcile) | The fast majority, and identical across every account |
| 6. Work Potential Matches | Press Alt+S to view suggestions Tally has surfaced from instrument date and amount, then F8 to reconcile the ones you confirm | This is where a genuine match with a small formatting difference gets caught |
| 7. Handle Partial Matches | Alter the voucher, or add a supplementary transaction, to bring the two sides to agreement | Common where a payment nets off a deduction — see the worked case below |
| 8. Set status by hand where needed | Press F9 (Set Status) to mark a transaction reconciled manually | For anything Auto BRS can't classify with confidence |
| 9. Unlink a wrong match | Press Alt+F8 (Unlink) | Corrects an incorrect auto-link before it distorts your bank balance |
Repeat steps 3 through 9 for the next bank account. Tally's documentation describes this workflow ledger by ledger and does not describe a consolidated view across accounts. Hold five current accounts and you are running this sequence five times, on five different import cadences.
Reading the match statuses
The report's status buckets are consistent whichever bank ledger you're in — that consistency is one of the genuine advantages of running several accounts through the same tool rather than several different bank portals:
| Status | What it means |
|---|---|
| Exact Match | Books and bank line agree; linked automatically, no action needed. |
| Potential Matches | Tally has suggested a likely pair based on instrument date and amount, but wants your confirmation before linking. |
| Partial Match / Partially Reconciled | The two sides are linked despite an amount difference — you chose to reconcile anyway, and the gap needs a supplementary entry or a voucher correction to close. |
| Available Only in Books | A voucher exists; nothing on the imported statement matches it yet. |
| Available Only in Bank | A statement line exists; no voucher has been recorded for it. |
The first bucket clears itself. The rest are where a human decision belongs — and on a busy current account, "Available Only in Bank" is usually the one worth opening first, because it's the bucket most likely to hide a transaction nobody has booked at all.
Where running several accounts specifically strains the workflow
Auto BRS does not get worse at matching because you have more bank accounts — the per-ledger mechanics above are identical whether you hold one account or ten. What multiplies is the coordination work sitting around it:
- Import cadence. Each bank releases statements on its own schedule and in its own dialect of Excel/CSV/MT940. Nothing in Tally schedules or chases these; a missed import on one account just means that ledger's Bank Reconciliation report goes stale until someone notices.
- Setup drift on new accounts. Open a new current account mid-year and its Reconciliation Beginning Date starts unset — you have to set it explicitly. Whether Potential Match Configuration also resets to Tally's defaults on a new ledger isn't stated in Tally's documentation, but there's no "copy settings" step described in the workflow either way.
- Cross-account payments. Pay the same vendor from Account A one month and Account B the next, and each bank ledger reconciles that vendor's line independently. The bill on your books is the only object that survives which account you happened to pay from.
- No single "are we done" view. Confirming every account is reconciled for the month means opening the report on each one in turn — there's no combined dashboard across ledgers in the documented feature set.
None of this is a defect in the matching logic. It's the cost of a per-ledger design applied to a business that, by the time it runs several current accounts, usually also has more vendors and less spare attention per account than it had with one.
What a "Reconciled" bank line still doesn't tell you
Matching in the Bank Reconciliation report answers one question: does this bank statement line correspond to a voucher already in your books. That's a payment-tracking question, not a GST one — nothing in Tally's bank reconciliation documentation describes any link to your GST filings.
Two things a clean match doesn't establish:
| Question a reconciled line does not answer | Why it matters |
|---|---|
| Which GST invoice does this payment settle? | A bank line matched to a voucher confirms the voucher was paid — it doesn't identify which specific tax invoice, or which GSTIN of a multi-branch vendor, the payment was for. Where one bank transfer covers several invoices, or a vendor issues under more than one GSTIN, that mapping has to be done by a person, not the reconciliation report. |
| Is the underlying credit still safe? | Under the second proviso to Section 16(2) of the CGST Act, read with Rule 37 of the CGST Rules, if you haven't paid a supplier the invoice value plus tax within 180 days of the invoice date, you must reverse the input tax credit proportionate to the amount still unpaid, with interest — in the GSTR-3B for the tax period immediately following that 180-day period, not on day 180 itself. Reverse-charge supplies fall outside the rule entirely, and the credit can be re-availed once you pay, with no time limit on re-availment. Separately, under Section 16(2)(aa) read with Rule 36(4)(b), that credit was only ever valid if the supplier furnished the invoice in GSTR-1 and it is communicated to you in your GSTR-2B. A "Reconciled" status in the bank report confirms the payment happened; it says nothing about either condition. |
Put together across a purchase register with even a modest vendor count, working out which invoice each bank line closes, then checking that invoice against Rule 37's 180-day clock and against GSTR-2B, is painful to do manually — not because any one step is hard, but because it means holding three separate systems (bank, books, GST portal) open at once, invoice by invoice, every month.
A worked case: why "matched" and "settled" aren't the same thing
A vendor invoices you ₹2,36,000 (₹2,00,000 taxable value + 18% GST). You deduct ₹4,000 income-tax TDS under Section 194C — computed on the ₹2,00,000 taxable value, not the GST-inclusive total (CBDT Circular 23/2017) — and the bank line that lands is ₹2,32,000. This is income-tax TDS, not the GST TDS a government buyer deducts under Section 51 of the CGST Act — a different mechanism entirely. Tally's Potential Match view can still link that line to the voucher, and will surface it as a potential match where the amount tolerance is set wide enough to cover the deduction. Once you confirm it, the report shows the bill as paid, and Tally's job is done. What it hasn't done, and isn't designed to do, is confirm that this vendor's GSTR-1 filing put the invoice into your GSTR-2B, or, where an invoice genuinely goes unpaid, track it against Rule 37's 180-day clock. (Whether an income-tax TDS deduction counts as part-payment for Rule 37 is not settled by the Act or the Rules — the rule's only deeming provisos cover Schedule I supplies and Section 15(2)(b) additions — so treat the TDS leg as a question for your advisor, not a reversal trigger.) Those are separate checks, against a separate system, that a bank-versus-books match cannot see.
Three things that break, and the fix
Statement re-imports creating duplicate lines
Importing an overlapping date range creates duplicate bank entries that then show as Available Only in Bank with nothing genuine to match. Before importing, check the date of the last transaction already reconciled in that ledger and start the new file from the day after.
Potential-match sensitivity left too loose or too tight
A wide tolerance on a high-volume account surfaces so many "potential" pairs that reviewing them takes longer than matching by hand would have. A tight one, on an account with irregular TDS deductions or bank charges, misses genuine matches and leaves them sitting in Available Only in Bank indefinitely. Revisit sensitivity per ledger as the pattern of transactions on that account changes.
A new bank ledger reconciling from the wrong date
Open a new account and skip setting its Reconciliation Beginning Date deliberately, and Tally will still let you reconcile — from whatever default point it picked, which can silently exclude genuine older entries from ever being offered a match. Set the date explicitly as the first action on any new bank ledger, before the first statement import.
What Recoup does once Tally has matched the bank lines
Recoup takes the bank-matched vouchers Tally has already sorted — across as many accounts as you hold — and carries the exercise into the two questions the Bank Reconciliation report was never scoped to answer: which specific vendor and GST invoice each payment settles, and whether that invoice's credit is still safe. It reconciles the same purchase register against your GSTR-2B, tracks the Rule 37 180-day clock per invoice on the unpaid proportion and excluding reverse-charge supplies, and does it across every bank account and GSTIN in one place rather than one Tally ledger at a time. Tally tells you the payment cleared. Recoup is built to tell you what that payment means for the credit sitting behind it.
Tally matched the payment. Does it know which invoice it settled?
Recoup reconciles your Tally bank vouchers against GSTR-2B, names the vendor and invoice behind each payment, and tracks the Rule 37 180-day clock on the unpaid balance — across every bank account, in one view.
Book a demo →Related guides
GSTR-2B
What the statement is, what it draws from, and why Section 16(2)(aa) makes it the eligibility document.
Connecting Zoho Books to your Indian bank feed
The same "matched payment as tax evidence" problem, worked through for Zoho Books instead of Tally.
GST reconciliation: the 2026 guide for finance teams
Why the bank leg is one of four reconciliations that decide your ITC, and the one most filing tools skip.