The short answer
TallyPrime imports a bank statement itself, under Alt+O (Import), Bank Statement: choose the bank ledger and a CSV or Excel statement downloaded from the bank portal. It does not take PDF, or CSV or Excel converted from PDF, and the bank must be one TallyPrime supports. From the imported lines, selected in its bank reconciliation reports, it creates Receipt and Payment vouchers, and Contra or Journal vouchers for interbank or cash lines where the bank ledger is set up for them.
The other two routes are to prepare the vouchers outside Tally, in Excel or XML, and import them as transactions, or to key them in one by one from the statement. The routes differ in how much is typed. In none of them does Tally choose the ledger a line belongs to. That call, with the voucher type, any split and the narration, is made by whoever prepares the entries, or by the settings they chose.
The routes into TallyPrime, side by side
What each route takes in, what TallyPrime does with it and what it leaves to the firm, as Tally's own help pages describe them; Excel, XML and JSON are one route, prepared vouchers imported.
| Route | What goes in | What TallyPrime does | What is left to the firm |
|---|---|---|---|
| Bank statement import, then voucher creation | CSV or Excel downloaded from the bank portal, for a bank TallyPrime supports; not PDF, and not CSV or Excel converted from PDF | Can find exact matches with the books on import and reconcile them; creates vouchers from selected lines, of the types set on the bank ledger | The ledger for every line, the bank ledger's settings, and reviewing what is created |
| Excel import of transactions, Release 4.0 on | Vouchers in a workbook, in Tally's sample format or mapped by a mapping template | Imports them under Alt+O (Import), Transactions, after a preview | Preparing every voucher, against masters already in the company |
| XML or JSON import | Vouchers written as XML, or JSON from Release 7.0, in a file or posted by another program | Imports a file under Alt+O (Import), Transactions, or XML posted to its HTTP server | Preparing every voucher, against masters that exist, and a unique voucher ID for each from a program |
| Keyed by hand | The statement, read line by line | Records each voucher as it is entered | Every line: date, amount, ledger, voucher type and narration, and checking it is not already in the books |
TallyPrime's own bank statement import
The import sits under Alt+O (Import), Bank Statement, where the bank ledger, the file and its type are chosen and a preview can be shown before the import. Tally's help takes CSV or Excel statements downloaded from the bank portal, and not PDF, or CSV or Excel converted from PDF. The bank and its statement format must be ones TallyPrime supports, and the statement must be dated after the Reconciliation Beginning Date.
Tally's help gives the import two uses: creating vouchers from the statement, and reconciling it with the books. Defaults for both are made on the bank ledger, in its Auto Reconciliation Configuration. There TallyPrime can be told to find the exact matches between statement and books as the statement is imported, and to reconcile them at once or leave them for later. There too the voucher types are set: Receipt for deposits, Payment for withdrawals and, if the user chooses, Contra or Journal for interbank or cash transactions.
Release 6.0 added voucher creation from an imported statement. In the bank reconciliation reports the user selects lines and presses F7 for a voucher for each, or Alt+F7 for one voucher at their combined amount. The ledger is the user's to fill, line by line in a Ledger Name column, or once for the selection as a Common Ledger, and a ledger that is missing can be created there. Vouchers made with F7 for several lines are saved as Optional, to be reviewed, then marked regular and reconciled; a consolidated voucher made with Alt+F7 is reconciled with its bank lines when it is saved.
So this route fills in the amount, the narration and the instrument details from the statement, and leaves the ledger on every line to the user.
Vouchers prepared in Excel or XML
This route builds the vouchers outside Tally and imports them under Alt+O (Import), Transactions. From Release 4.0, TallyPrime imports masters and transactions from Excel, in Tally's sample format or in the firm's own layout mapped through a mapping template, with a preview of what will be imported. Tally's help lists Date, Voucher Type and the Debit or Credit Amount among the mandatory fields for a voucher, and needs the masters the import depends on to exist in the company already. For payment vouchers to appear correctly in the Bank Reconciliation report, it has the sheet carry the bank date, the ledger amount and the bank name.
XML is the format TallyPrime imported before Release 4.0, and JSON joined it in Release 7.0. Other programs reach Tally in XML too: TallyPrime can run as an HTTP server, on port 9000 by default, and accepts XML posted to it while it is running with at least one company loaded.
Both put the work before the import. The ledger, the voucher type and the narration of every line are decided in the spreadsheet, or in the program that writes the XML, and data that names a master the company does not have is reported as an exception, to be resolved in Tally's Exceptions report. With the import setting Overwrite voucher when a voucher with same GUID exists set to No, a voucher exported and imported back into the same company comes in as a duplicate. Tally's Import Data FAQ asks a third party program to give every voucher a unique voucher ID, since vouchers that share one can overwrite or delete vouchers already in Tally.
The calls on every line
Whichever route is taken, these are settled for each line, by a person or by a setting a person chose, and Tally records what was decided.
- The ledger. A narration names a payee, a reference or the mode of payment, rarely a head of account. The same payee can be a supplier in one client's books and an expense in another's. An Excel or XML import needs the ledger to exist in the company already; TallyPrime's statement route lets it be created while the vouchers are made.
- The voucher type. Money in is a Receipt and money out a Payment, unless the other side is cash or another bank account of the same company; Tally's help has those transfers, a cash deposit or an ATM withdrawal among them, recorded with a Contra voucher.
- A split. One line can need two ledgers: an instalment on a loan is principal and interest, and the bank debits it as one amount.
- Duplicates. A line may already be in the books: keyed by the client's accountant, or created or imported before. TallyPrime's statement import can look for exact matches with the books; a voucher prepared outside Tally has to be checked against them before it goes in.
- The narration. The bank's text is what ties the voucher back to the statement line. A narration written afresh can explain the entry better, and loses that tie unless the bank's reference is kept.
Each call, and how OptiLedger takes it
The same calls in OptiLedger: what the module does on each, from its own source, and what it leaves to the CA.
| The call | What OptiLedger does | What stays with the CA |
|---|---|---|
| The ledger | Suggests one, trying a previous decision, then a rule, then AI. One choice approves every similar undecided line | Approving it, since nothing posts until you approve it; creating in Tally any ledger the company lacks |
| The voucher type | Receipt for money in, Payment for money out, Contra where the chosen ledger sits under Bank Accounts, Bank OD A/c, Bank OCC A/c or Cash-in-Hand | Choosing the ledger; the type follows from it |
| Duplicates | Skips a line whose date, narration and amount match a voucher Tally holds for those dates, and marks it Already in Tally | A voucher keyed earlier under another narration or amount, which that check does not match |
| The narration | The bank's narration carried into the voucher as it is | Any explanation beyond the bank's text |
| A split line | Does not split a line, or make Journal, Sales or Purchase vouchers | Splitting the line across ledgers, in Tally |
| Before posting | Checks that the date is not before the company's books begin, the voucher type exists, both ledgers exist under their exact names and the two legs balance. A failed line returns with its reason, ready to retry | Fixing what the failed line reports, then posting again |
| Reconciliation | Posts the bank leg with no bank date | The bank reconciliation in Tally |
A line counts as already in Tally only when its date, narration and amount match; the narration is compared with its spaces removed and its case ignored.
What OptiLedger does
OptiLedger takes a client's statement in PDF, Excel or CSV, up to 25 MB. OptiVida's own parser reads the file, with no AI, and checks the lines add up before you see them. It does not read scanned or photographed statements.
Each line tries your past decision, then a rule, then AI. AI picks only from the company's own ledger list, or declines. Decisions are remembered per client and bank account, and only what you approved. One choice approves every similar undecided line. Nothing posts until you approve it.
Posting sends one Receipt, Payment or Contra voucher per approved line, through Tally's HTTP server on port 9000, the XML route above. The connector reads what Tally already holds for the dates being posted and skips a line it finds there. Each line comes back Posted, Already in Tally or Failed, and a failed line returns with its reason, ready to retry.
It needs the Windows Tally connector, with the client's company open, and nothing is sent if another company is open in Tally. It does not create ledgers or any other Tally master, so a ledger the company lacks is created in Tally first. It does not delete or reverse a voucher it posted; do that in Tally. Which ledger, whether to split and whether the entry is right stay the CA's; OptiLedger carries the approved decision into Tally.
To take away
- TallyPrime's own import takes CSV or Excel from the bank portal, not PDF, for a bank it supports, and creates vouchers of the types set on the bank ledger; the user fills in the ledger.
- An Excel or XML import brings in what it is given: every voucher is prepared first, against masters the company already has.
- No route chooses the ledger for a line; the voucher type, any split and the narration are the firm's to settle, by hand or through Tally's settings.
- OptiLedger suggests a ledger from the company's own list, works out Receipt, Payment or Contra, skips a line whose date, narration and amount Tally already holds, and posts only approved lines; it needs the Windows Tally connector, with the client's company open.
Sources
- TallyHelp: How to Import Bank Statements in TallyPrime
- TallyHelp: How to Set Up TallyPrime for Bank Reconciliation
- TallyHelp: How to Auto-create Vouchers Using Bank Statements in TallyPrime
- TallyHelp: Release Notes for TallyPrime and TallyPrime Edit Log Release 6.0
- TallyHelp: Release Notes for TallyPrime and TallyPrime Edit Log Release 4.0
- TallyHelp: Import Data - FAQ
- TallyHelp: How to Import Data using Any Excel File into TallyPrime
- TallyHelp: Understanding Import Data from Excel
- TallyHelp: How to Import Data from JSON or XML into TallyPrime
- TallyHelp: XML Integration
- TallyHelp: Pre-requisites for Integrations
- TallyHelp: Sample XML
- TallyHelp: How to Record Accounting Entry in TallyPrime