Tally's XML import is the fastest way to post a full month of bank transactions in one go, but it only works if the XML file is built correctly. Unlike a plain Excel import, Tally XML is a structured data format with specific tags, and a small mismatch, such as a ledger name spelled slightly differently, a date in the wrong format, or a voucher where debits don't equal credits, will cause that voucher to fail. This guide explains how bank statement data becomes Tally XML, what the structure looks like, and how to validate it before you import.
If you're looking for the broader import process and ledger-mapping steps instead, see how to import a bank statement into Tally.
What Tally XML Import Actually Is
Tally accepts data through Gateway of Tally > Import Data, reading an XML file structured as an ENVELOPE containing a HEADER and a BODY, with the BODY holding one or more voucher records nested under IMPORTDATA, REQUESTDATA, and TALLYMESSAGE tags. Each transaction on your bank statement becomes one VOUCHER element inside that structure.
Anatomy of a Bank Voucher in Tally XML
| Tag | Purpose | Example value |
|---|---|---|
| VOUCHERTYPENAME | Whether the voucher is a Payment, Receipt, or Contra | Payment |
| DATE | Voucher date, typically in YYYYMMDD format | 20260815 |
| NARRATION | Transaction description carried over from the statement | NEFT to ABC Enterprises Inv 2201 |
| PARTYLEDGERNAME | The ledger the voucher is primarily drawn against | ABC Enterprises |
| LEDGERENTRIES.LIST | One block per ledger line in the voucher, each with its own amount and Dr/Cr flag | Bank ledger and party ledger, opposite signs |
| AMOUNT | Value of each ledger entry, with sign convention depending on debit or credit side | -15000.00 and 15000.00 |
Ledger Names Must Match Exactly
PARTYLEDGERNAME and every name inside LEDGERENTRIES.LIST must match an existing Tally ledger master character for character, including spacing and case. If it doesn't, Tally will either reject the voucher or silently create a new ledger, which fragments your books across near-duplicate names such as ABC Enterprises and ABC Enterprises Pvt Ltd. Before generating any XML, export your current Tally ledger list and match names against it rather than assuming they'll line up.
Vouchers With More Than Two Ledger Lines
Not every bank voucher is a clean two-line entry between the bank ledger and one party ledger. A bank charge that includes GST, for example, typically needs three ledger lines: the bank ledger on one side, and the expense ledger plus a GST ledger split out on the other, with all entries still netting to zero within that one voucher. Loan EMI debits are similar, split between a principal ledger and an interest ledger. When building XML from a bank statement, decide upfront which narration patterns need more than two ledger lines, since treating them as simple two-line vouchers will post the wrong amount to the wrong ledger even though the voucher still balances.
From Bank Statement to XML: the Mapping Pipeline
- Start from a clean statement with date, narration, debit, and credit columns already separated.
- Classify each row into a voucher type: Payment, Receipt, or Contra.
- Map the narration to a party ledger using a lookup table built from past transactions.
- Generate one VOUCHER block per row with matching debit and credit ledger entries whose amounts net to zero.
- Wrap all the voucher blocks in a single ENVELOPE for import.
Validation Checks Before You Import
- The XML is well-formed: every tag that's opened is closed, and characters like an ampersand inside narration text are written as & rather than a raw & symbol.
- Debits equal credits within every single voucher, not just across the file as a whole.
- Every ledger name referenced already exists in Tally, or its creation is intentional.
- Dates are in the format Tally expects and are internally consistent across the file.
- No transaction from a period that was already imported previously is present again.
- The voucher types used, Payment, Receipt, or Contra, actually exist under those names in the Tally company being imported into.
Common Import Errors and What They Mean
| Error | Likely cause |
|---|---|
| Ledger does not exist | A party or bank ledger name in the XML doesn't match the Tally master exactly |
| Voucher does not tally / amount mismatch | The debit and credit entries inside one voucher don't net to zero |
| Import completes but nothing changes | The wrong company was open in Tally, or the file wasn't a valid ENVELOPE |
| Duplicate entries appear | The same date range was imported twice without checking what was already posted |
Testing With a Small Batch First
Before importing a full month in one file, it's worth testing with a small batch of five to ten vouchers covering different narration patterns, including at least one bank charge and one contra transfer. This surfaces ledger name mismatches and mapping errors on a small, easy-to-check set of vouchers rather than discovering them scattered across two hundred transactions after a full import.
Importing the File
From Gateway of Tally > Import Data > Vouchers, point to the XML file and run the import. Tally shows a log of which vouchers succeeded and which were skipped or errored. Fix the ledger names or amounts causing the errors and re-import only the remainder rather than the whole file again, to avoid duplicating the vouchers that already succeeded.
Where OneBooks GST Fits
Building this XML by hand for every statement is exactly the kind of repetitive, detail-sensitive task that's easy to get wrong once and hard to catch quickly across hundreds of vouchers. OneBooks GST's bank statement parsing, under Admin > Bank Statements, reads the PDF or Excel statement, maps transactions to ledgers, and exports the result as Tally XML, alongside GSTR-1 exports to Tally XML. See bank statement parser and how to export GSTR-1 data to Tally for the related export path. For the ledger-mapping decisions that come before you reach XML, see how to import a bank statement into Tally, and for where this fits into OneBooks GST's roadmap for full double-entry books, see accounting software.
Frequently Asked Questions
What format does Tally XML import use?
An ENVELOPE containing a HEADER and BODY, with the BODY holding one or more VOUCHER records nested under IMPORTDATA, REQUESTDATA, and TALLYMESSAGE tags, one VOUCHER per transaction.
Why does Tally say a ledger does not exist during import?
Because the ledger name in the XML file doesn't match an existing Tally ledger master exactly, including case and spacing. Even a small difference is treated as a different ledger.
What happens if debits and credits don't match in a voucher?
Tally will flag or reject that voucher, since every voucher's ledger entries must net to zero between the debit and credit sides.
Can I import a bank statement into Tally as XML without manually writing tags?
Yes. Tools built for this, including OneBooks GST's bank statement parser, generate the XML structure automatically from the parsed statement rather than requiring you to write tags by hand.
How do I fix an XML import that partially fails?
Check Tally's import log for the specific vouchers that failed, correct the ledger names, dates, or amounts causing the error, and re-import only those corrected vouchers to avoid duplicating the ones that already succeeded.
Can one Tally XML voucher have more than two ledger entries?
Yes. A voucher can include as many ledger entry blocks as needed, provided the debit and credit amounts across all of them net to zero. This is common for bank charges that include GST or for EMI payments split between principal and interest.
