TallyPrime XML Import: The Complete Guide
XML import is the oldest and most dependable way to move transactions into TallyPrime. Every serious integration — a CA posting a month of marketplace sales, a middleware tool, or a one-off migration — ultimately produces the same thing: a well-formed XML envelope that TallyPrime accepts either as a file or through its local HTTP interface. This guide covers the format, the rules that reject vouchers, and a workflow that keeps bulk imports safe.
The three ways TallyPrime accepts data
TallyPrime is Windows desktop software from Tally Solutions, and the official documentation describes three integration routes:
- XML/JSON over HTTP — TallyPrime exposes a local HTTP interface (default port 9000). You enable it under F1 > Settings > Connectivity and set TallyPrime to act as Both. Our guide to enabling the HTTP interface walks through it screen by screen.
- File import — the same XML saved as a file and imported from within TallyPrime. Recent releases also accept Excel files for many transaction types.
- ODBC — read-only access for pulling data into Excel or BI tools. It cannot write vouchers.
For writing vouchers, XML is the common denominator: the file you import manually and the payload you post to port 9000 share one structure.
Anatomy of an import envelope
An import request is wrapped in an ENVELOPE. The header declares an Import Data request; the body carries one TALLYMESSAGE per voucher:
<ENVELOPE>
<HEADER><TALLYREQUEST>Import Data</TALLYREQUEST></HEADER>
<BODY><IMPORTDATA>
<REQUESTDESC><REPORTNAME>Vouchers</REPORTNAME></REQUESTDESC>
<REQUESTDATA>
<TALLYMESSAGE><VOUCHER>...</VOUCHER></TALLYMESSAGE>
</REQUESTDATA>
</IMPORTDATA></BODY>
</ENVELOPE>Inside each VOUCHER you set the date, voucher type name, party ledger, narration and reference, and then the accounting lines in ALLLEDGERENTRIES.LIST. Inventory vouchers add ALLINVENTORYENTRIES.LIST with stock item, quantity, rate and godown details. Every name is matched as plain text against your company data, so spelling and spacing must be exact.
A few header fields deserve special care. The voucher type element must name a type that exists in the company; DATE uses the compact YYYYMMDD form; PARTYLEDGERNAME sets the party the voucher is booked against; and REFERENCE plus NARRATION are where order IDs and settlement references belong, because they are what you will search for at month end. For GST-registered sellers, the state, place of supply and registration details on the voucher and the party masters determine how Tally treats the tax split, so a voucher can import cleanly and still be wrong for returns purposes if those are missing. Treat the first ten vouchers of any new pipeline as suspects: open each one in Tally and compare field by field against the source row before trusting the next thousand.
Debits, credits and ISDEEMEDPOSITIVE
The sign convention surprises everyone the first time. In import XML, debit amounts are written as negative numbers and flagged with ISDEEMEDPOSITIVE set to Yes; credits are positive with the flag set to No.
| Entry side | AMOUNT sign | ISDEEMEDPOSITIVE |
|---|---|---|
| Debit | Negative (for example -1180.00) | Yes |
| Credit | Positive (for example 1180.00) | No |
The AMOUNT values across all ledger lines of a voucher must sum to zero. If the flag and the sign disagree, or the voucher does not balance, TallyPrime rejects it during import. Getting hundreds of vouchers to balance to the paisa is exactly the kind of work that belongs in software, not in a spreadsheet at midnight.
Masters must exist first
TallyPrime never creates a ledger or stock item on the fly during a voucher import. If ALLLEDGERENTRIES.LIST references a ledger that does not exist in the open company — or an inventory line names an unknown stock item — the voucher is rejected with a LINEERROR while the rest of the file continues. That partial-import behaviour is dangerous: you end up with some vouchers posted and some silently missing. Before any bulk run, confirm every ledger and stock item exists, or import master XML first. Our companion piece on fixing LINEERROR rejections lists the usual culprits.
A safe bulk import workflow
- Take a full company backup and verify you can restore it.
- Run a small batch — five to ten vouchers — into a test company first.
- Check the Day Book: dates, amounts, party ledgers, GST ledgers.
- Import the full batch, then tie totals back to your source report.
- Record which files or batches were imported so nothing is posted twice.
This is the workflow TallySutra automates for marketplace sellers. It reads Amazon, Flipkart and Meesho reports, builds balanced vouchers with the correct sign conventions, holds them for CA approval, and exports standard TallyPrime import XML — no TDL required. The desktop Gateway then posts approved batches to Tally over the local HTTP interface, validating the open company first and skipping anything already imported. See the feature overview or grab the Gateway download to try it against a test company.
Frequently asked questions
Do I need TDL to import XML into TallyPrime?
No. The XML import format is built into TallyPrime itself. TDL is only needed if you want custom screens or reports. Tools like TallySutra generate standard import XML that TallyPrime accepts without any customisation.
Why are debit amounts negative in Tally import XML?
It is TallyPrime's internal convention: debits carry a negative AMOUNT with ISDEEMEDPOSITIVE set to Yes, credits are positive with the flag set to No. All lines in a voucher must net to zero or the import rejects the voucher.
What happens if I import the same XML file twice?
TallyPrime will happily create duplicate vouchers — it does not deduplicate on its own. Keep a log of imported batches, or use a tool with duplicate-safe re-imports that tracks what has already been posted.
TallySutra turns Amazon, Flipkart and Meesho reports into reconciled, reviewed TallyPrime vouchers — duplicate-safe, with every rupee traceable to its source row.
Book a 30-minute demo