One statement in. A month you can sign off.
Upload the statement as your bank exports it. The agent checks the running balance on every row, suggests a ledger for each line from rules learned once per party, and shows you only the lines it cannot decide. On your approval it posts the vouchers into TallyPrime and matches the closing balance to the statement.
From the bank’s file to a matched month.
An import utility drops every line into suspense to be classified by hand, remembers nothing for next month and finds its mistakes at reconciliation. Here the lines are classified before you look, your answers are kept as rules, and the balance is proven before anything posts.
Upload
The Excel file from net banking, as it came. The layout is detected, every row is read and the running balance is checked before any line is classified.
Review the exceptions
You choose a ledger only where the agent was unable to decide, a handful of lines. Every choice is saved as a rule, so the second month asks less than the first.
Post
One approval for the batch. Vouchers reach Tally through the connector on that PC, or arrive as a file for you to import.
Match
The closing balance in Tally is compared with the statement’s last line, to the paisa, on every run. If they differ, the row that breaks the balance is named.
Twelve sample lines, classified in front of you.
Pick a bank and watch its narrations arrive. Beside every line appear its ledger, its confidence and why: a saved rule, a bank code or a name match. The lines it cannot decide wait on the right for your pick; then post the batch and compare the two closing balances.
Sample statements with sample figures. The demo runs in this page and sends nothing anywhere.
Eight things happen to every line of the statement.
Built on Tally’s official interface. The agent reads the bank’s file, proves the balance, decodes the narration and suggests a ledger that already exists in your books.
Reads the bank’s own file
In the layout your bank uses, as Excel or CSV. ICICI runs today; HDFC, SBI, Axis and Kotak follow in that order; any other bank is added from a sample file. Every layout has to pass the balance check.
Running-balance check on every row
The balance on each row is recomputed from the row before. A single broken row halts the run and names itself, before anything is classified.
Narration parsing
Card, cheque, UPI, NEFT, IMPS, charges, interest and remittance purpose codes on foreign receipts, with the party pulled from the string. Own-account transfers, bulk salary and fixed deposits are known by their codes.
Ledger matching, in order
Your approved rules first, then bank codes, then a name match on the ledger list your Tally holds. It never suggests a ledger that does not exist there.
Exceptions only
New parties, low-confidence matches and possible duplicates are the only lines put in front of you. The rest wait in the batch for your one approval.
Posts inside Tally
Receipt, payment and contra vouchers, with the narration and the bank reference filled in.
Duplicate guard
A line matching a posted voucher on date, amount and bank reference is skipped, so a statement uploaded twice never posts twice.
Posting log
File, row, voucher, who approved and when. From any voucher you can read back to the statement row it came from.
Four things that wait for you.
Nothing reaches your books without your approval, and anything the agent is unsure of is shown to you, never posted on its own.
Posting
Nothing posts without approval. Low-confidence lines are shown with their reason and never posted automatically.
New ledgers
Only ledgers that already exist in your Tally are used. A new one is created only when you say so.
The books
Your accounts never leave the office. The connector talks to Tally on the same PC and only calls outward.
A wrong rule
Reversed as one batch. Each voucher’s narration carries its source file and row, so the reversal is exact.
From the bank’s file to a matched closing balance.
The statement is checked row by row before the agent suggests a ledger for any line. Lines your rules cover go straight to the batch; exceptions wait for you. Nothing posts before your approval, and the posting log ties every voucher back to its line.
A small program on your Tally PC, and nothing opened to the internet.
It sits in the system tray on the PC that runs Tally, collects approved vouchers, posts them locally and reports back. Every connection it makes is outward, over HTTPS.
Outward connections only
No port is opened on your router, so no one outside can reach your Tally.
One key per company
Each company has its own key, and you can revoke it at any time.
Queues while Tally is closed
Approved vouchers wait and post in order when Tally next opens.
An import file instead
For firms that want no connector, the approved batch comes as a file you import into Tally yourself.
Twelve months of one current account, through the agent.
The same proof is shown on your first statement. Month one raises more questions than month three, since your approvals are where the rules come from; every line classifying itself in month one is not something we promise.
1 current account · 12 months · balance check passed on every row · posting errors 0 · closing balances equal
Many client companies, one screen.
Accounting firms run every client’s statements from one workspace, each posting into that client’s own Tally.
One workspace per firm
Every client company is handled from one screen, by the people you give access to.
One company per client Tally
Each client’s vouchers post into that client’s own Tally company. Statements are never mixed between clients.
A shared rule library
Once the agent learns a supplier in one client’s books, it knows that supplier in the other clients’ books too, so a new client starts with fewer questions.
Four things you always get.
Statements are encrypted, kept for a retention window you choose, thirty days unless you set another, and then deleted. Only the statement, your ledger names and balances travel; your full accounts stay in Tally.
A written brief
What we agreed to build, in one document.
A fixed price
Set in the proposal, before work starts.
Staging + approval
You see it and approve it before it goes live.
Documentation
How it works and how to change it, handed over.
Before you send a statement.
Send any other question in writing; a written answer follows within one business day.
Does our Tally need to be reachable from the internet?
No. The connector on your Tally PC makes outward HTTPS connections only: it collects approved vouchers, posts them locally and reports back. Nothing is opened on your router. If you would rather have no connector, the batch comes as an import file.
Which Tally versions work?
Any release of TallyPrime, rental or licensed, and Tally.ERP 9. One setting is switched on once, and we walk you through it in writing.
Can it post something wrong?
Nothing posts until you approve the batch, only ledgers that exist in your Tally are used, and low-confidence lines wait for you. If a rule turns out wrong, its batch is reversed as one, and every voucher’s narration carries its source file and row.
Where do our statements go?
Only the statement, your ledger names and balances travel; your full accounts stay in Tally. Statements are stored encrypted and deleted when your chosen retention window ends, 30 days unless you set another; they are never mixed between clients.
Not sure what you need? Ask in writing.
Send one statement. The reply carries it classified, the exceptions it would have asked about, and the balance proof.